Troubleshooting and Optimization practice questions

Logs Insights queries chain commands with pipes: filter narrows events, sort orders them, and limit caps how many return. The system fields @timestamp and @message are always available, and sort @timestamp desc is how "most recent first" is expressed.

Option b is the canonical shape for "the latest N events matching a pattern": filter to the timeout text, sort descending by timestamp, limit to 20. Option a sorts ascending and therefore returns the oldest matches. Option c produces bucketed counts, not events, and applies its filter in the wrong position. Option d uses parse, which extracts fields rather than filtering, so non-matching events still flow through.

1. Choose the function's log group and a time range covering the incident.
2. filter @message like /Task timed out/ to keep only the relevant events.
3. sort @timestamp desc so the newest occurrences come first.
4. limit 20 to cap the result set at the number you need.

Exam tip: filter + sort desc + limit is the Logs Insights pattern for "the most recent N matching events".

With Lambda proxy integration, API Gateway performs no transformation: the function must return an envelope with a numeric statusCode, optional headers, a body that is a string (typically JSON.stringify output), and isBase64Encoded for binary. Any response that breaks this contract produces a 502.

The tell is 502 with a healthy function: the function completed (Errors is zero, Duration normal), yet the gateway could not translate its response — the signature of a malformed proxy envelope on some code path. A timeout would show as 504 and abnormal duration, quota exhaustion returns 429, and a WAF block returns 403 before the integration ever runs.

1. Confirm from metrics that the function itself reports no errors and normal duration.
2. Query the function's logs for the failing request IDs and inspect what each code path returned.
3. Find the branch returning a raw object, omitting statusCode, or passing an unserialized body.
4. Fix that path to return the full envelope with a stringified body, and add a test for it.

Exam tip: 502 from API Gateway with a healthy Lambda function almost always means a malformed proxy response.

A 504 Gateway Timeout from API Gateway means the integration did not respond within the gateway's integration timeout — 29 seconds by default — which is independent of, and can be far shorter than, the backend's own timeout setting.

The function completes in its logs because its own 60-second timeout allows the work, but API Gateway stopped waiting at the 29-second default and returned 504 to the client. Option a misstates Lambda limits (up to 15 minutes). Option c describes the 502 failure mode. Option d confuses duration with rate — throttling is 429 and unrelated to how long one request runs.

1. Match the 504 responses against the function's logs and confirm those invocations ran longer than 29 seconds.
2. Recognize that the gateway's integration timeout, not the function timeout, is the binding limit.
3. Shorten the synchronous work, or move long processing to an asynchronous pattern that responds immediately and completes in the background.
4. Reserve raising timeouts as a last resort — a client waiting tens of seconds is usually a design smell.

Exam tip: 504 means the integration blew through API Gateway's 29-second default timeout — the function's own timeout is irrelevant to the client.

HTTP 429 Too Many Requests from API Gateway always means throttling: a rate or burst limit was hit, or a usage plan quota was exhausted. It is never an authentication or validation failure.

The daily rhythm — failures beginning each afternoon and clearing overnight — is the signature of a per-day usage plan quota being consumed and then reset. An authorizer problem would return 403 and show no daily cycle, validation failures return 400 and depend on the payload, and a timing-out backend returns 504.

1. Read the status code first: 429 narrows the cause to throttling or quota before any log diving.
2. Check the usage plan attached to the affected API keys and compare its daily quota against actual request volume.
3. Confirm in the stage's metrics when throttled requests begin each day.
4. Raise the quota, spread traffic, or move heavy clients to a plan that matches their volume.

Exam tip: 429 is always throttling or quota — a failure pattern that resets daily points at a usage plan quota.

403 Forbidden from API Gateway is always an authorization problem — an IAM or Lambda authorizer denial, a resource policy, a missing or invalid API key, or an AWS WAF block. It is never throttling, which returns 429.

Two clues triangulate the answer: the 403 code itself points at auth, and the absence of backend invocations proves the request was rejected before the integration — where authorizers, resource policies, API key checks, and WAF sit. The timing after a security review makes a new WAF rule or tightened policy the natural suspect. Throttling is ruled out by both the code and the metrics, and 502/504 causes require the backend to be involved.

1. Confirm the status code is 403 and note that throttling metrics are clean.
2. List what changed recently — here, a security review likely added WAF rules or tightened policies.
3. Check the WAF web ACL's blocked-request metrics and sampled requests for the affected clients.
4. Review the API's resource policy, authorizer behavior, and the clients' API keys until the denying control is found.

Exam tip: 403 means an authorization control said no — check WAF, policies, authorizers, and API keys, never traffic volume.

HTTP 400 Bad Request means the client sent something the API refuses to accept — with API Gateway request validation enabled, payloads that fail the JSON schema model are rejected at the gateway before any integration runs.

The combination of 400s, no backend invocations, and onset at the moment a new client shipped identifies validation rejecting the new payload shape. A backend response problem (b) would be a 502 and requires invocations that never happen; throttling (c) is 429; and a stage cache (d) replays cached successes rather than minting client errors.

1. Correlate the 400 spike's start time with the client release.
2. Check the gateway's execution logs for the validation error messages on rejected requests.
3. Diff the new app's request payloads against the JSON schema model.
4. Fix the client payload, or version the model if the API contract legitimately changed.

Exam tip: 400 with no backend invocation means the request died at validation — diff the payload against the schema.