Practice Test #4

Incorrect. AWS Lambda does not support mounting arbitrary “snapshots” of dependencies as a filesystem in the way EC2 can use EBS snapshots. Lambda provides /tmp ephemeral storage and optional EFS mounting, but not snapshot mounting. This option describes a non-existent Lambda feature and would not be a valid deployment approach for oversized dependencies.

Incorrect. Although arm64 can sometimes provide better price/performance and may change dependency footprint, the question explicitly states the function uses x86_64 and that it must remain unchanged. Therefore, switching architectures violates a hard requirement. Additionally, changing architecture can introduce compatibility issues for native libraries like OpenCV/SciPy.

Incorrect. Lambda cannot attach an Amazon EBS volume. EBS is an EC2 block storage service and requires an EC2 instance to attach. For Lambda, the supported network filesystem option is Amazon EFS (and only within a VPC), but even EFS is not the best fit here compared to container images for packaging large dependencies.

Creating a new Lambda alias does not update the function’s code package. Aliases are pointers to published versions and are used for traffic shifting, stable ARNs, and deployment strategies (e.g., blue/green with CodeDeploy). If the underlying function code is not updated (or a new version is not published), a new alias won’t cause CloudFormation to pull a new ZIP from S3.

Uploading to a different bucket is unnecessary and does not inherently solve the problem unless the template is also updated to reference that new bucket/key/version. The core issue is CloudFormation not seeing a change in the Lambda Code definition. Changing buckets adds operational complexity and is not the recommended mechanism for deterministic deployments.

A code-signing configuration enforces that Lambda only deploys code signed by trusted publishers, improving supply-chain security. It does not force CloudFormation to redeploy code when the S3 key remains the same. Even with code signing, CloudFormation still requires a change in S3Key or S3ObjectVersion (or equivalent) to trigger an update.

Incorrect. AuthType=NONE allows anonymous invocation, directly violating the requirement to block anonymous access. Also, it suggests creating a resource-based policy and attaching it to an IAM group, which is not how resource policies work. Resource-based policies are attached to the resource (the Lambda function) and specify principals; they are not attached to IAM groups.

Incorrect. While AWS_IAM is the right auth type, creating 340 separate identity-based policies is unnecessary operational overhead and not a best-practice scalable approach. Additionally, identity-based policies do not grant access “from a group ARN” as a condition in the way implied; you attach the policy to the group (or users/roles), not reference the group as a principal.

Incorrect. AuthType=NONE permits anonymous access, failing the core security requirement. It also proposes adding a resource-based policy per function with the QA-Reviewers group ARN as principal. IAM groups are not valid principals in resource-based policies; you would need to specify roles/users/accounts. This option is both insecure and technically flawed.

Incorrect. sam init is a project scaffolding command that generates a starter SAM application structure and sample templates. It does not deploy resources, update Lambda code, or perform incremental synchronization to an existing stack. While SAM is the right framework, the command required for rapid incremental updates is sam sync (or sam deploy for full deployments), not sam init.

Incorrect. cdk synth only synthesizes (generates) a CloudFormation template from CDK code; it does not deploy anything to AWS. Even though CDK ultimately uses CloudFormation, synth is a local build step and cannot push incremental Lambda code changes to a dev stack. The deployment command in CDK would be cdk deploy (not provided as an option).

Incorrect. cdk bootstrap provisions prerequisite resources (the CDK toolkit stack, such as an S3 bucket and roles) needed for CDK deployments in an account/region. It is a one-time or infrequent environment setup step, not an incremental deployment mechanism. It will not sync updated Lambda code or apply template tweaks to an existing application stack.

A scheduled Lambda can delete items, but it requires writing and maintaining code to query/scan for expired items, handle pagination, retries, and throttling. It also consumes DynamoDB read/write capacity and can become costly at scale. This is more development and operational effort than necessary when DynamoDB TTL can handle expiration natively.

Running a scheduled ECS Fargate task is even heavier operationally than Lambda: you must build and maintain a container image, task definition, IAM roles, networking, and scheduling. It still needs logic to find and delete expired items and can drive significant DynamoDB capacity usage. This does not meet the “least development effort” requirement compared to TTL.

AWS Glue is intended for ETL and data processing, not routine operational deletion of DynamoDB items. A Glue job would be complex, slower to start, and requires additional setup (job scripts, connections, scheduling). It would likely rely on scans and batch deletes, increasing cost and effort. This is not an appropriate fit for simple item expiration.

Standard CloudFront access logs delivered to S3 are not near-real-time; delivery is typically delayed (often minutes). Running scheduled Athena queries further increases latency and is batch-oriented. This approach can produce dashboards, but it will not meet the ≤2 seconds requirement for per-edge-location 4xx/5xx visualization and anomaly detection.

The statement “stream CloudFront logs directly to Kinesis Data Firehose” is not the best fit as written. CloudFront real-time logs natively integrate with Kinesis Data Streams, and while Firehose can deliver to OpenSearch/S3, it typically buffers data (size/time), which can add latency and may exceed a strict ≤2 seconds requirement unless carefully tuned and supported by the source integration.

CloudTrail records AWS API activity for governance and auditing, not CloudFront viewer request/response logs. Sending CDN access logs to CloudTrail is not a valid pattern, and CloudTrail-based alarms/dashboards would not provide per-edge-location 4xx/5xx request error analytics with near-real-time updates.

AssumeRoleWithWebIdentity is used when the caller presents a web identity token from an OIDC provider (for example, Amazon Cognito, Google, or EKS IRSA). It does not match this scenario because the developer is not using an OIDC token; they are explicitly assuming a cross-account IAM role ARN and providing MFA device ARN and a 6-digit token code. For classic IAM role assumption with MFA, AssumeRole is the correct API.

GetFederationToken is used to obtain temporary credentials for a federated user, typically to access AWS resources without assuming a specific role in another account. It is not the standard mechanism for cross-account role assumption to a named role ARN in a partner account. Additionally, cross-account access patterns for a partner role like arn:aws:iam::444455556666:role/SQSWriter are designed around sts:AssumeRole, not GetFederationToken.

AssumeRoleWithSAML is used when authentication is performed via a SAML 2.0 identity provider and the caller presents a SAML assertion to obtain role credentials. The question does not mention SAML, an IdP, or a SAML assertion—only MFA with a virtual device and a token code. Therefore, this option is a mismatch for the required inputs and the described access pattern.

Not necessarily. Ref returns a value for a resource or parameter in the same template (e.g., for AWS::EC2::VPCEndpoint, Ref returns the endpoint ID). However, cross-stack sharing is not achieved by Ref alone; you must import an exported value. The application stack could correctly use ImportValue and not directly use Ref at all, so this is not a required cause of failure.

Incorrect. The Mappings section is for static key/value lookups (e.g., region-to-AMI mappings) and cannot dynamically contain a VPC endpoint ID created by another stack at runtime. Including the endpoint ID in Mappings would require hardcoding it, which defeats the purpose and is brittle. Cross-stack resource sharing should use Outputs/Export and ImportValue instead.

Incorrect. CloudFormation does not support exporting values from the Mappings section. Only Outputs can be exported for cross-stack references. Mappings are evaluated within a single template and are not addressable by other stacks. Therefore, the absence of an export in Mappings is not a meaningful concept and would not be the root cause.

Incorrect. DynamoDB Streams can trigger Lambda, but Step Functions does not provide a “redrive execution” mechanism to resume a currently running (waiting) execution. Redrive is used to restart failed executions (and only for certain workflows/configurations). To resume from an external event you would need a callback task token and SendTaskSuccess/SendTaskFailure, which is not described here.

Incorrect. Stopping the current execution and starting a new one from the beginning breaks workflow correctness and idempotency unless the entire state machine is designed for safe replays. It also risks duplicate side effects (e.g., re-sending activation steps) and adds operational complexity. This does not meet the requirement to simply “resume” the paused workflow at the correct point.

Incorrect. A Lambda function that continuously polls DynamoDB is exactly the “long-running function” anti-pattern the question warns against. It consumes compute while waiting, can hit Lambda timeout limits, and is less reliable than a durable Step Functions Wait state. Step Functions should handle waiting; Lambda should not be used as a busy-wait loop.