Practice Test #4

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.