Troubleshooting and Optimization: free practice questions

Correct: When an SDK client is instantiated inside the handler, it is recreated on every invocation, including DNS resolution and TLS handshake setup, adding hundreds of milliseconds of overhead. Moving the DynamoDB client initialization to the global scope (outside the handler) means it is created once per execution environment and reused across all warm invocations, eliminating the per-invocation initialization cost. Wrong — Option A: Memory pressure and GC pauses would typically manifest as spiky duration increases correlated with memory usage metrics. The trace explicitly shows the time is spent on SDK client initialization and TLS, not computation. Wrong — Option C: Insufficient IAM permissions would cause AccessDeniedException errors, not silent latency. CloudWatch would show Lambda errors, not merely high duration. Wrong — Option D: API Gateway caching would reduce the total number of Lambda invocations, but when Lambda is invoked, the 850 ms initialization overhead inside the function would remain unchanged. Caching doesn't fix per-invocation inefficiency.

Correct — Option B: API Gateway stage-level caching stores backend responses keyed by request parameters. Cache hits are served directly by API Gateway without invoking Lambda or querying DynamoDB, directly reducing read costs and improving latency. Correct — Option D: API Gateway supports client-driven cache invalidation via the `Cache-Control: max-age=0` header. However, to prevent unauthorized cache invalidation (which could force expensive cache misses), AWS recommends enabling the 'Require authorization' setting on the cache invalidation policy so only authorized callers can flush entries. Correct — Option E: API Gateway caching is a dedicated cache infrastructure that charges an hourly rate based on the chosen cache capacity (0.5 GB to 237 GB), billed regardless of utilization. This is an important cost consideration. Wrong — Option A: API Gateway cache does NOT integrate with DynamoDB change events. The cache is time-based (TTL); it has no mechanism to detect when a DynamoDB item changes. Cache entries expire after the configured TTL. Wrong — Option C: The maximum TTL for API Gateway caching is 3,600 seconds (1 hour), not 4 hours. A 3,600-second TTL approximates the update cycle only partially — the catalog could be stale for up to 1 hour after an update, not 4 hours. The statement is misleading because the developer cannot set a 4-hour TTL. Wrong — Option F: API Gateway caching and AWS WAF operate independently. WAF evaluates requests before caching serves them; WAF rules are not disabled when caching is enabled.

Correct: When a DLQ uses SSE with a customer-managed KMS key, SQS must encrypt messages before writing them to the DLQ. If the source queue (or the SQS service principal acting on its behalf) does not have the `kms:GenerateDataKey` and `kms:Decrypt` permissions on the KMS key, SQS will fail to write messages to the DLQ silently, and messages may be deleted instead of forwarded. This is a common, subtle misconfiguration. Wrong — Option A: SQS does support cross-account DLQs when the DLQ resource policy grants the source account access. This alone does not prevent DLQ routing; it would just require additional resource policy setup, and the question implies the redrive policy itself is configured. Wrong — Option B: A `maxReceiveCount` of 1 means messages ARE moved to the DLQ after the very first failure — this would actually cause messages to flow to the DLQ faster, not prevent them from appearing there. This is a misconception about how `maxReceiveCount` works. Wrong — Option D: If the DLQ's retention period is shorter than the source queue's, messages that arrive in the DLQ may expire and be deleted — but they would briefly appear in the DLQ first. The question says messages are not appearing at all, which points to a write-time failure, not an expiration issue.

API Gateway usage plans allow you to define rate limits (steady-state RPS) and burst limits per API key. If a customer's usage plan has a lower rate or burst limit than their actual traffic, API Gateway throttles only that customer with a 429 response while other customers on higher-limit plans are unaffected. This matches the scenario exactly — some customers are throttled, others are not. — Option A (stage-level throttle) would affect all customers uniformly, not selectively, and the scenario says only some customers are impacted. Option C (per-IP throttling) is not a native API Gateway feature; API Gateway throttling is based on API keys and stage settings, not IP addresses. Option D (Lambda reserved concurrency) would cause 502 or 429 errors from Lambda, but this would affect all customers proportionally based on traffic share, not specific enterprise customers.

Correct: The X-Ray service map shows Service B with high latency but Service C with normal latency and 0% faults on Service B. This means Service B is not experiencing errors and is not being slowed by its downstream dependency (Service C). The bottleneck must therefore be within Service B itself — its own processing logic, memory contention, database queries internal to Service B, or CPU throttling. The developer should examine Service B's subsegments to pinpoint the internal bottleneck. Wrong — Option A: If Service C were throttling and Service B were swallowing those errors, Service C would likely show high latency or the traces would show retries adding to Service B's total time. Service C showing normal latency makes this explanation unlikely. Wrong — Option C: X-Ray sampling affects whether traces are recorded, not whether recorded traces correctly reflect latency vs. faults. Low sampling wouldn't cause latency to appear on B while faults disappear from C in the traces that are captured. Wrong — Option D: If Service A were retrying calls to Service B, X-Ray would typically show multiple trace segments or increased request counts to Service B. Also, retries on Service A's side would appear as multiple calls in Service A's trace, not inflate a single Service B segment's latency.