Practice Test #2

Amazon SQS is a message queue optimized for decoupling producers and consumers with at-least-once delivery, but it uses a competing-consumer model: once a message is consumed and deleted, other consumers cannot read it. You could duplicate messages to multiple queues or use SNS-to-SQS fanout, but that explicitly duplicates the pipeline per consumer and complicates replay/checkpointing semantics compared to a true stream.

Amazon Kinesis Data Firehose is a fully managed delivery service that buffers and delivers streaming data to destinations like S3, Redshift, and OpenSearch. It is not designed for multiple EC2-based applications to concurrently consume the same stream with sub-second latency and independent checkpoint/replay. Firehose focuses on delivery with buffering (seconds to minutes) and transformation, not multi-consumer real-time processing.

Amazon EventBridge is an event bus for routing events to targets with filtering and SaaS integration. While it supports multiple targets, it is not a streaming service with shard-based throughput, ordered records, and consumer-controlled checkpoints. EventBridge also does not provide the same stream replay model (per-consumer resume from sequence checkpoints) required for crash recovery and near-real-time stream processing at scale.

Incorrect. Embedding credentials in the deployment package/container image couples secrets to a specific Lambda version. Rotation would require rebuilding and redeploying the function and potentially updating the prod alias, which violates the requirement that previously published versions must use the latest credentials without republishing code. This is also a security anti-pattern (secrets in artifacts).

Incorrect. Lambda environment variables are part of the function configuration captured in a published version. Because versions are immutable, updating environment variables updates only the unpublished $LATEST configuration; older published versions that an alias might reference will still have the old environment variable values and therefore old credentials, breaking the requirement.

Incorrect. Systems Manager Parameter Store SecureString can store encrypted values, but it does not provide the same built-in, managed database credential rotation workflow as Secrets Manager for Aurora/RDS. You would need to implement custom rotation logic (including updating the DB password) and handle coordination/rollback. The option’s claim to “enable rotation there” is not the standard managed approach expected for this requirement.

Incorrect. Maximum event age is a configuration for asynchronous Lambda invocations that controls how long Lambda will keep retrying an event before discarding it (and optionally sending it to a DLQ/on-failure destination). It does not change an API Gateway synchronous invocation into an asynchronous one, so it does not solve the API Gateway 29-second timeout problem.

Incorrect. You cannot increase the API Gateway REST API integration timeout beyond 29 seconds. Lambda can run up to 15 minutes, but API Gateway will still time out waiting for a response. This option reflects a common misconception that API Gateway timeout is adjustable like Lambda’s timeout; it is not, so long-running work must be decoupled.

Incorrect. X-Amz-Target is used for certain AWS service APIs (notably some JSON/Query protocols) to specify an operation target, and it is not the correct mechanism to control Lambda invocation type from API Gateway. The correct header for Lambda async invocation is X-Amz-Invocation-Type with value Event. Using X-Amz-Target here would not reliably invoke Lambda asynchronously.

Incorrect. A scheduled EventBridge-triggered Lambda is designed for unattended execution; prompting an operator on first run is not feasible and would break automation. It also does not define a secure, durable, encrypted-at-rest storage mechanism for the key. Certification questions typically reject any approach requiring manual intervention for recurring serverless jobs.

Incorrect. Hardcoding the API key in source code or packaging it in the deployment artifact is a security anti-pattern. It increases the risk of exposure through repositories, CI/CD logs, artifact stores, or reverse engineering. It also makes rotation difficult and violates least privilege and secure secret management best practices expected on AWS exams.

Incorrect. HTTPS ensures encryption in transit, not encryption at rest. Running Lambda in a VPC does not automatically protect or encrypt a secret; it mainly controls network egress/ingress and can introduce operational overhead (NAT gateway for internet access, VPC endpoints). This option does not meet the explicit requirement to keep the key encrypted at rest.

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.