Practice Test #2

KMS can encrypt/decrypt data and supports automatic KMS key rotation, but rotating a KMS key does not rotate the payment gateway client_id/client_secret. You would still be using the same credentials unless you build a separate rotation mechanism. Also, storing secrets in an encrypted file and decrypting in Lambda adds operational complexity and increases the risk of mishandling plaintext in the runtime environment.

STS provides temporary AWS credentials (AccessKeyId/SecretAccessKey/SessionToken) to call AWS services, not to authenticate to a third-party payment gateway. Retrieving STS credentials every 15 minutes does not address rotating the external API’s client_id/client_secret. This option confuses AWS identity federation/assume-role patterns with third-party secret management requirements.

AWS Systems Manager Parameter Store SecureString can store encrypted values and allow IAM-based runtime retrieval, but it is not the purpose-built service for managing rotating application secrets. Parameter Store does not offer the same native, managed automatic rotation workflow for third-party credentials that AWS Secrets Manager provides. To meet a strict 90-day rotation requirement, you would need to build and maintain custom automation to update both the stored value and the third-party payment gateway credentials. Because the question asks for the most secure approach with automatic rotation and no redeployments, Secrets Manager is the better and more direct choice.

Incorrect. Although Lambda can process events quickly, this option relies on an EventBridge schedule every 15 minutes, which violates the “within 60 seconds” requirement. Additionally, polling CloudTrail (especially log files delivered to S3) can introduce extra latency and complexity. The better pattern is to have EventBridge react to CloudTrail events in near real time rather than periodic scans.

Incorrect. Running an ECS Fargate task on a 15-minute schedule is also polling-based and cannot meet the 60-second notification requirement. It adds unnecessary operational overhead (task definitions, networking, IAM, cost) for a problem that EventBridge can solve natively with an event pattern and an SNS target.

Incorrect. An EC2 instance with a cron job is the most operationally heavy approach (patching, scaling, availability, credentials management) and still only runs every 15 minutes, failing the 60-second requirement. Like the other polling options, it depends on CloudTrail log availability and parsing, which is not designed for immediate detection.

Incorrect. It places the HTML in the integration response template (good), but it sets the integration response Content-Type to application/json, which violates the requirement to return text/html. Also, setting “Content-Type of text/html” in the integration request is not what controls the client response; response headers must be configured in the method/integration response.

Incorrect. It puts the HTML in the integration request template, but the request mapping template is used to create the payload sent to (or generated for) the integration, not the body returned to the client. While it mentions text/html in the integration response, it does not correctly provide the mock statusCode selection pattern and misplaces the HTML content.

Incorrect. It puts the HTML in the integration request template and sets the integration response Content-Type to application/json, which conflicts with the requirement. Additionally, the request template Content-Type does not determine the outgoing response Content-Type; the response must be configured in the method/integration response settings.

ELB health checks are irrelevant because this is an event-driven serverless workflow (no load balancer target health to check). Publishing logs as custom metrics via PutMetricData is not a log search solution and adds significant custom work and cost. Athena can query logs in S3, but this option does not provide a clear, minimal-overhead path to centralize EventBridge/Step Functions/Lambda logs into S3 in the first place.

Route 53 health checks monitor endpoints, which does not help isolate failures inside EventBridge/Step Functions/Lambda. CloudTrail captures control-plane API calls (e.g., StartExecution) but not the detailed application/runtime logs needed to pinpoint intermittent 5xx errors in Lambda code or state transitions. Querying CloudTrail with Athena can help audit who called what, but it is not the right tool for correlating execution failures across components.

Streaming logs through Kinesis Data Firehose to S3 and indexing in Amazon OpenSearch Service can enable powerful search, but it introduces substantial setup and ongoing operations: delivery streams, buffering, index management, scaling, retention, and cost tuning. This violates the “least operational overhead” requirement. It is appropriate for long-term centralized logging/search at large scale, not for quick troubleshooting with minimal maintenance.

Adding /shipments-v2 in the existing API and deploying to the production stage introduces change into the prod stage. Even if users don’t call the new path, it still modifies production configuration and can create operational risk (deployment errors, shared stage settings like throttling/usage plans, logging changes). It also doesn’t cleanly separate test traffic from prod stage metrics and governance.

A separate REST API would isolate testing, but it has higher operational overhead: duplicating resources/methods, authorizers, usage plans, throttling, logging, deployments, and potentially custom domain/base path mappings. It also risks configuration drift between the test API and the real production API, reducing the fidelity of integration tests compared to using a separate stage of the same API.

Pointing the existing POST method integration to version 5 and deploying to the production stage directly affects production traffic. Even if the test is short, all prod requests would invoke the new version during the test window, violating the requirement that tests must not affect the production stage. This is the highest-risk approach and not aligned with safe deployment best practices.