Practice Test #3

Incorrect. The CloudWatch agent is used for publishing OS/application metrics and logs to Amazon CloudWatch. CodeDeploy does not require the CloudWatch agent to perform deployments or evaluate deployment success. While CloudWatch can help with troubleshooting (e.g., viewing logs/metrics during a rollout), its absence would not directly cause CodeDeploy to fail with HEALTH_CONSTRAINTS.

Incorrect. If the developer’s IAM user lacked codedeploy:CreateDeployment, the deployment would fail to start and would be denied immediately by IAM. The scenario describes a rollout that began and then aborted at 6 minutes due to health constraints, which indicates instance-level deployment execution/health issues rather than a caller authorization problem.

Incorrect. There is no universal requirement to enable a special “CodeDeploy health checks” feature for every deployment group. CodeDeploy health behavior is driven by deployment configurations (minimum healthy hosts, batch size) and optional integrations like load balancers and alarms. HEALTH_CONSTRAINTS is typically caused by real instance failures or insufficient healthy capacity, not by a missing mandatory feature toggle.

Incorrect. Lambda can certainly return mocked JSON and varied HTTP status codes, but it introduces compute cost (Lambda invocations), operational overhead (code packaging, IAM, logging), and potentially VPC configuration later. The requirement explicitly states “no backend integration and no compute/VPC costs,” which MOCK integration satisfies more directly than Lambda proxy integration.

Incorrect. EC2 behind an ALB adds unnecessary infrastructure, cost, patching/maintenance, scaling considerations, and longer setup time. It violates the requirement for no compute costs and is not aligned with the goal of quickly publishing static responses with minimal operational burden. API Gateway can do this natively without standing up servers.

Incorrect. HTTP_PROXY requires a real upstream endpoint; pointing to an external mock still creates a backend dependency and potential latency/availability/security issues. Also, “attach an AWS Lambda layer to the API” is not a valid API Gateway construct—Lambda layers attach to Lambda functions, not directly to API Gateway. This option mixes incompatible concepts and doesn’t meet the no-backend requirement.

Incorrect. Lambda authorizers control authentication/authorization decisions, not which backend Lambda alias the API method integration invokes. Creating separate authorizers per alias does not route the main integration traffic to different Lambda versions. Stage variables can be used with authorizers, but that would only affect auth, not the core requirement of routing each stage’s requests to its matching Lambda alias.

Incorrect. Gateway responses in API Gateway customize responses for errors (e.g., 4XX/5XX) and can add headers or templates. They do not influence integration target selection or Lambda alias routing. Creating gateway responses for different aliases is not a valid concept; gateway responses are not tied to Lambda aliases and won’t make PROD and DEV versions separately reachable.

Incorrect. API Gateway does not provide “environment variables” in the way Lambda does. The per-stage configuration mechanism is stage variables. While you can use Lambda environment variables inside the function, that would not help API Gateway choose between aliases; the requirement is to route to distinct Lambda versions/aliases per stage, not to change behavior within one alias.

Incorrect. Storing the plaintext data key on disk is a security anti-pattern and violates the intent of using KMS to protect key material. Also, the encrypted data key (CiphertextBlob) is not used directly for data encryption; it must be decrypted by KMS first to obtain the plaintext data key. This option reverses the correct roles of the two outputs.

Incorrect. While it correctly stores the encrypted data key, it incorrectly uses KMS Encrypt to encrypt the file. KMS Encrypt is designed for small payloads and is not appropriate for encrypting multi-megabyte files (2–25 MB). The correct approach is to encrypt the file locally using the plaintext data key and only use KMS to wrap/unwrap the data key.

Incorrect. It stores the plaintext data key (insecure) and also attempts to use the encrypted data key with KMS Encrypt to encrypt the file, which is conceptually wrong. The encrypted data key is meant to be stored and later decrypted with KMS Decrypt; it is not an encryption key for KMS Encrypt, nor should plaintext keys be persisted.

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.