Practice Test #3

Storing secrets in S3 (even encrypted with a CMK) is not a best-practice secrets solution. You must build secure retrieval, parsing, and rotation semantics yourself. “S3 Object Lambda to rotate” is not a rotation mechanism; it transforms objects on retrieval and does not manage secret lifecycle, versioning, or coordinated updates with external systems. This increases development/ops effort and risk compared to Secrets Manager.

Systems Manager Parameter Store SecureString provides encryption at rest (including with KMS), and user data can fetch parameters at boot. However, rotation is not a native managed capability; you must implement scheduled Lambda rotation, update external systems (DB password/API key), handle versioning, and ensure safe cutover/rollback. Using the default KMS key also does not meet a CMK requirement if one is implied by policy.

Base64 encoding is not encryption and does not satisfy “encrypted at rest.” Embedding secrets in configuration files (or AMIs) is insecure, hard to rotate across an Auto Scaling fleet, and increases blast radius if an instance or artifact is compromised. A custom monthly script for rotation is high development and operational effort and is error-prone compared to managed secret rotation services.

Incorrect. You do not connect to a “global AWS X-Ray daemon” over TCP 2000. Port 2000 is used locally (typically UDP) between your application and the daemon you run. While interface VPC endpoints can be used for private connectivity to the X-Ray service APIs, that connectivity is over HTTPS (443) to regional endpoints, not TCP 2000 to a managed daemon.

Incorrect. CloudWatch Logs cannot be configured to push raw application logs directly into X-Ray to create distributed traces. X-Ray traces are generated by the SDK/agent capturing request context and timing data. You can correlate logs with trace IDs (e.g., by logging the X-Ray trace ID and using CloudWatch Logs Insights), but logs ingestion is not a substitute for X-Ray instrumentation.

Incorrect. CloudWatch metric streams export metrics (typically to Kinesis Data Firehose destinations) for near-real-time analytics, not per-request tracing. Metrics are aggregated and cannot correlate individual customer checkouts across microservices. For intermittent 502 debugging and message flow analysis, distributed tracing (X-Ray) and structured logging with trace IDs are the appropriate tools, not metric streaming.

Step Functions can implement a 900-second Wait, but starting an execution per message at 2,000 messages/min creates very high execution churn and cost/limits considerations. Using EventBridge to invoke every 5 minutes also does not guarantee “exactly 15 minutes after each message arrives,” because messages could sit up to ~5 minutes before being picked up for orchestration. This is more complex than necessary compared to native SQS delivery delay.

Custom polling plus republishing messages with a future timestamp is operationally heavy and error-prone. You must manage polling fleets/concurrency, handle clock/time comparisons, and deal with duplicates and message attribute logic. It also increases SQS traffic (receive + send again) and complicates failure handling. This violates the “most operationally efficient” goal when SQS already supports delivery delay natively.

Visibility Timeout does not delay initial processing; it only hides a message after it has been received. With a Lambda event source mapping, Lambda would receive messages immediately and invoke the function immediately, violating the requirement to wait exactly 15 minutes after arrival. A 900-second visibility timeout is useful to allow long processing without duplicates, but it is not a scheduling/delay mechanism.

Incorrect. Although a Lambda@Edge function can invoke AWS services such as KMS, building custom per-field encryption at the edge is not the best solution for this requirement. It adds unnecessary complexity for parsing JSON, selecting fields, handling encryption logic, and managing performance on every request. CloudFront Field-Level Encryption is the native feature designed specifically to encrypt selected request fields and is therefore the better architectural choice for this scenario.

Incorrect. AWS WAF helps protect against common web exploits and can inspect/allow/block requests, but it does not encrypt request fields. Using a Lambda function with self-managed keys for encryption/decryption adds key management overhead, rotation challenges, and higher risk compared to managed services. It also doesn’t inherently ensure only one microservice can decrypt unless you build a full custom key distribution system.

Incorrect. Requiring HTTPS and using signed URLs/cookies improves transport security and access control to CloudFront content, but it does not encrypt specific JSON fields within the request payload. Other services behind the ALB would still see the sensitive fields in plaintext once the request is decrypted at the edge/ALB. This fails the “only billing can decrypt” requirement.

IAM database authentication can reduce password usage for some engines (notably Amazon RDS for MySQL and Amazon Redshift), but it is not a universal solution across all listed databases. Amazon DocumentDB does not use IAM database authentication for native MongoDB-style users/passwords in the same way, so this would not centrally manage/rotate those credentials. Also, token generation shifts operational burden to clients and does not meet the “rotate every 30 days” requirement for stored DB users.

Systems Manager Parameter Store SecureString supports KMS encryption at rest, but it does not provide a built-in, end-to-end automatic rotation mechanism for database credentials comparable to Secrets Manager. You would need to build and operate custom automation (e.g., Lambda/Step Functions) to rotate the actual database users/passwords and update parameters. That violates “no manual steps” and “minimizing custom code,” and it is less purpose-built for DB credential rotation.

Storing credentials in S3 (even with SSE-KMS and blocked public access) is not a secure or operationally appropriate secrets management pattern. S3 does not provide native secret rotation, version staging for rotation workflows, or tight integration with database credential updates. KMS key rotation only rotates the encryption key material, not the database password itself. This option fails the automatic 30-day credential rotation requirement and increases risk of accidental exposure.