AWS DVA-C02: Monitoring and Troubleshooting Practice Questions

Correct — Option B: Lambda CPU allocation scales linearly with memory. Increasing memory from 512 MB to 3,008 MB provides ~6× more CPU, which dramatically speeds up model loading and inference computation, directly reducing duration. Correct — Option A: Initializing the model outside the handler (in the global/module scope) causes it to be loaded once per execution environment. Subsequent warm invocations reuse the cached model object, skipping the S3 download entirely and cutting duration significantly. Wrong — Option C: S3 Glacier Instant Retrieval has the same retrieval speed for standard GET requests as S3 Standard for objects already restored, but Glacier is designed for archival data and would actually add complexity. The bottleneck here is the 150 MB download size, not the storage tier. Wrong — Option E: Lambda SnapStart is currently only supported for Java runtimes; it would not apply to most ML workloads and does not address the S3 download cost per invocation. Wrong — Option F: Changing the trigger from API Gateway to an ALB does not affect the duration of the Lambda function itself. Wrong — Option D: Loading from EFS instead of S3 may reduce latency for small files, but a 150 MB model still needs to be read on every invocation unless the model is also cached outside the handler — the caching strategy (Option A) is the key fix regardless of storage backend.

Increasing memory allocation (E) also proportionally increases CPU allocation, which shortens initialization time and reduces the duration of each cold start. Enabling Provisioned Concurrency (C) pre-initializes a specified number of execution environments, eliminating cold starts entirely for those instances. — Switching runtimes (F) can help in some cases but is not a reliable general solution and carries significant refactoring cost; Java without native compilation actually tends to have worse cold starts. Increasing the API Gateway timeout (D) only masks the latency problem rather than solving it. X-Ray tracing (B) adds observability but does not reduce cold starts — it can even add marginal overhead. Setting reserved concurrency to 0 (A) would disable the function entirely, which is incorrect.

Correct A (option 0): Setting ReceiveMessageWaitTimeSeconds on the queue to 20 enables long polling at the queue level, causing all ReceiveMessage calls to wait up to 20 seconds for a message before returning an empty response, dramatically reducing empty responses and API costs. Correct C (option 2): Even without queue-level long polling, consumers can enable long polling per-request by passing WaitTimeSeconds=20 in each ReceiveMessage API call, achieving the same effect. Both approaches implement long polling, and either or both should be used. Wrong B: Message retention period controls how long messages stay in the queue; it does not affect polling behavior or empty responses. Wrong D: FIFO queues guarantee ordering and exactly-once processing but do not reduce empty responses; they actually have lower throughput limits. Wrong E: Increasing visibility timeout prevents duplicate processing during processing, but does not reduce empty poll responses. Wrong F: Reducing consumer count might lower API call frequency marginally but does not solve the root cause of empty responses; it would also reduce processing throughput.

Correct — Option A: The account-level API Gateway throttle limit (default 10,000 RPS) is a hard ceiling that applies across all APIs and stages in the account. To allow any single stage to handle 12,000 RPS, the account-level limit must first be raised via an AWS Support request. Without this, stage-level limits cannot exceed the account limit. Correct — Option C: Stage-level throttling in API Gateway allows you to set a maximum RPS for a specific stage. Setting it to 12,000 RPS on the marketing campaign stage (after raising the account limit) ensures that stage can handle the traffic. Wrong — Option B: Usage Plans with rate limits are designed for API key-based client throttling, not for setting overall stage capacity limits. A Usage Plan rate limit applies per API key, not as an aggregate stage limit. Wrong — Option D: API Gateway caching reduces backend calls by serving cached responses, but it does not prevent the 429 throttle responses that are enforced before the cache layer is consulted; also, campaign requests are likely unique (personalized), making caching ineffective. Wrong — Option E: Method-level throttle overrides apply per method, not as an aggregate; setting 12,000 RPS per method does not cap the stage aggregate at 12,000 RPS and is unnecessarily granular. Wrong — Option F: Limiting other stages via Usage Plans (per API key) rather than stage-level throttling provides inconsistent enforcement and is not the correct mechanism for aggregate stage-level rate limiting.

Correct: Lambda Destinations allow you to route asynchronous invocation results (success or failure) to a destination such as SQS, SNS, EventBridge, or another Lambda function — with no code changes required inside the function. Configuring ON_FAILURE automatically sends the failed event payload and execution metadata to the specified SQS queue. Wrong — Option A: A DLQ can be configured on the Lambda function itself (not the SQS event source mapping) for asynchronous invocations, but Lambda Destinations are the preferred modern approach and include richer metadata. More importantly, a DLQ on an SQS event source mapping applies to SQS-triggered (synchronous poll-based) invocations, not asynchronous invocations — so this option conflates two different concepts. Wrong — Option B: Writing explicit SDK calls inside the function code works but requires development effort and introduces more code complexity, violating the 'least development effort' requirement. Wrong — Option D: Provisioned Concurrency is a performance feature for reducing cold starts; it has no built-in error routing capability, and Lambda does not read destination ARNs from environment variables.