Practice Test #1

Increasing the Lambda timeout does not address the root cause. The function already has a 120-second timeout, while processing completes in 45–55 seconds. The duplicates occur because SQS makes messages visible again after 30 seconds, not because Lambda is timing out. A longer Lambda timeout could help only if the function were actually timing out before deleting messages, which is not the case here. Trap: It can sound plausible because it mentions Increase the timeout of the Lambda function., but it misses the visibility timeout being shorter than batch processing.

Increasing memory can reduce runtime because Lambda CPU scales with memory, but it is not the direct fix. Even if performance improves, the system is currently configured so that messages reappear after 30 seconds. Unless memory tuning reliably brings processing below 30 seconds in all cases (including spikes), duplicates will still occur. The correct control for redelivery timing is the SQS visibility timeout. Trap: It can sound plausible because it mentions Increase the memory allocation of the Lambda function., but it misses the visibility timeout being shorter than batch processing.

Increasing batch size generally increases the amount of work per invocation and can increase processing duration, making the visibility timeout mismatch worse. It can also increase the blast radius of failures (more messages retried together) and complicate partial batch failure handling. Batch size tuning is for throughput/cost optimization, not for preventing messages from reappearing before processing completes. Trap: It can sound plausible because it mentions Increase the batch size in the event source mapping., but it misses the visibility timeout being shorter than batch processing.

Credentials packaged in code or an image are frozen into the published artifact and require rebuilds when rotated. Trap: Rebuilding feels controlled, but it violates the no-republish requirement.

Environment variables are part of Lambda version configuration, so old published versions keep old values. Trap: Updating environment variables works for $LATEST or new versions, not existing immutable versions.

Parameter Store SecureString stores encrypted values, but it is not the managed Aurora credential rotation workflow described here. Trap: SecureString sounds similar to Secrets Manager, but rotation is the differentiator.

NoEcho helps prevent the password from being displayed in the CloudFormation console output, but the password is still provided directly to Lambda via an environment variable. Environment variables can be exposed through configuration access, debugging, or accidental logging, and they are not a best-practice secret store. This approach also lacks rotation and centralized secret governance. Trap: It may look tempting because it uses Use a CloudFormation parameter to pass the admin, but the decisive requirement is managed secret storage with CloudFormation dynamic references and runtime retrieval.

This is better than A because Lambda retrieves the value at runtime and only stores a parameter name in the environment. However, the option does not specify using SSM Parameter Store SecureString with KMS, which is critical for secure storage. Even if SecureString were used, Secrets Manager is typically the preferred service for database credentials due to native rotation and purpose-built secret lifecycle management. Trap: It may look tempting because it uses AWS Systems Manager Parameter Store, but the decisive requirement is managed secret storage with CloudFormation dynamic references and runtime retrieval.

Encrypting the parameter value with the KMS encrypt command does not solve the core problem: Lambda still needs the plaintext to connect, so you would need to manage decryption, key permissions, and ciphertext handling. This becomes a custom secret-management scheme and often results in secrets being stored or passed around in less controlled ways (e.g., environment variables), increasing operational and security risk. Trap: It may look tempting because it uses AWS KMS, but the decisive requirement is managed secret storage with CloudFormation dynamic references and runtime retrieval.

A scheduled Lambda would work but requires scan/query, pagination, retry, and delete logic that TTL avoids. Trap: Lambda is a common automation tool, but this expiration pattern is built into DynamoDB.

A scheduled Fargate task is heavier than needed and still needs custom deletion code. Trap: Containers can run batch jobs, but the requirement is least development effort.

AWS Glue is for ETL workflows and is excessive for simple item expiration. Trap: Glue can process data at scale, but it is not the native TTL mechanism for DynamoDB items.

Incorrect. Git tags are intended to mark specific points in history (e.g., v1.3.7 release) and are typically immutable references. You don’t develop “on a tag” as an ongoing stream; you would still need branches for continuous commits and merges. Tags are useful in addition to branches (to label releases), but they do not replace branching for parallel development. Trap: It can sound plausible because it mentions Create a Git tag for the code currently in production and a second Git tag for v2.0 development, then push., but it misses the need for active branches for both v1.x fixes and v2.0 work.

Incorrect. Creating a production branch can be useful, but attaching an IAM policy that prevents all other users from pushing/merging blocks the team’s stated need to deliver patches for 10 weeks unless only a single privileged user does all work. Access control is not the primary branching strategy; you still need a separate v2.0 branch and a process to merge hotfixes forward. Trap: It can sound plausible because it mentions From main, create a production branch for the currently deployed code and attach an IAM policy that prevents., but it misses the need for active branches for both v1.x fixes and v2.0 work.

Incorrect. A separate repository for v2.0 increases operational overhead and makes it harder to propagate v1.x hotfixes into v2.0 (you’d need cross-repo cherry-picks or patches). This also complicates CI/CD, permissions, and traceability. A tag to “track v2.0 work” still doesn’t provide an active development line; branches are the right mechanism. Trap: It can sound plausible because it mentions Create a new CodeCommit repository exclusively for v2.0 development and create a Git tag to track the v2.0., but it misses the need for active branches for both v1.x fixes and v2.0 work.

CloudTrail API logs do not contain the application playback fields such as viewerId and playbackDurationSeconds. Trap: Athena is useful for SQL over data in S3, but the stated source is API activity logs, not the Lambda application logs.

EventBridge does not aggregate distinct viewer IDs into daily periods, and CloudWatch dashboards are not EventBridge targets. Trap: EventBridge can route events, but it is not a dashboard analytics engine.

CloudWatch metrics and alarms do not natively compute distinct counts from raw high-cardinality event fields. Trap: Metrics are good for numeric time series, but the question asks for distinct viewerId analytics from logs.

A Lambda function on a 15-minute schedule cannot notify within 60 seconds. Polling CloudTrail logs also adds unnecessary delay and operational code. Trap: Lambda can filter events, but the scheduled polling cadence fails the requirement.

An ECS Fargate task running every 15 minutes has the same latency problem and adds containers, networking, and task configuration for a native event-matching task. Trap: Fargate is managed compute, but it is still scheduled polling here.

An EC2 cron job is operationally heavy and runs every 15 minutes, so it cannot satisfy the within-60-seconds notification requirement. Trap: Cron-based parsing may seem simple, but it misses the latency target.

CodeBuild can build or test code but does not own Lambda weighted traffic shifting. Trap: It sounds like a deployment service, but CodeDeploy or Lambda aliases handle traffic weights.

Function URLs would create separate endpoints or require an external splitter, violating the unchanged endpoint requirement. Trap: Two URLs can look like two versions, but they do not provide built-in weighted alias routing.

Lambda does not provide an alias for function URLs that weights traffic between URLs. Trap: It borrows the word alias from Lambda, but applies it to the wrong feature.

AWS CloudTrail records AWS API calls (e.g., ModifySecurityGroupRules, ReplaceNetworkAclEntry, ModifyDBInstance) and is useful to determine who changed a configuration and when. However, it does not provide packet-level or flow-level visibility and cannot show where packets are being dropped in the data plane. It can complement troubleshooting after you suspect a change, but it is not the quickest tool to pinpoint packet drops. Trap: It is tempting because it mentions AWS CloudTrail, but the scenario points to flow-level evidence plus stateless NACL rule inspection.

AWS Trusted Advisor provides account-level recommendations (cost optimization, security, fault tolerance, performance, service limits). It does not inspect live VPC traffic or identify where packets are being dropped between subnets/ENIs. While it might flag some general issues (e.g., security group openness) or limits in other contexts, it is not designed for rapid, path-specific network drop diagnosis. Trap: It is tempting because it mentions AWS Trusted Advisor, but the scenario points to flow-level evidence plus stateless NACL rule inspection.

AWS Config rules evaluate resource configurations against desired policies and track configuration history. They are useful for compliance and drift detection (e.g., a NACL rule changed from allow to deny), but they do not provide real-time traffic evidence or indicate where packets are being dropped. Config can help after you identify the likely component, but it is not the quickest tool for packet-drop localization. Trap: It is tempting because it mentions AWS Config rules, but the scenario points to flow-level evidence plus stateless NACL rule inspection.