DVA-C02 Troubleshooting and Optimization Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the API Gateway integration timeout to 30 seconds.

  Why it's wrong here

  Increasing the API Gateway integration timeout to 30 seconds is not a viable solution because API Gateway imposes a strict maximum integration timeout of 29 seconds for all backend integrations, including Lambda functions. This is a hard limit that cannot be configured beyond 29,000 milliseconds. Any backend process exceeding this duration will inevitably result in a 504 Gateway Timeout error, regardless of the configured value attempting to surpass this ceiling.

• ✓

  Refactor the Lambda function to use asynchronous invocation, return a 202 immediately, and have the client poll for results.

  Why this is correct

  Refactoring the Lambda function to use asynchronous invocation, returning a 202 immediately, and having the client poll for results is the correct approach for long-running operations. This pattern decouples the synchronous API Gateway request from the extended backend processing, allowing API Gateway to respond promptly with a 202 Accepted status. The Lambda function can then trigger an asynchronous workflow (e.g., via SQS, SNS, or directly invoking another Lambda asynchronously) and store results for the client to retrieve later through a separate polling mechanism, effectively bypassing the 29-second timeout.

• ✗

  Enable API Gateway caching to avoid repeated calls.

  Why it's wrong here

  Enabling API Gateway caching primarily serves to reduce latency and backend load for repeated, identical requests by storing responses and serving them directly from the cache. While beneficial for performance optimization, caching does not address the root cause of a 504 Gateway Timeout, which indicates that the initial or unique backend processing for a request exceeded the integration timeout. Caching would only prevent the timeout if the exact same request had previously completed successfully and was cached, which is not the scenario described by a persistent 504 error.

• ✗

  Use multiple Lambda functions to parallelize processing.

  Why it's wrong here

  Using multiple Lambda functions to parallelize processing, while potentially speeding up the overall completion of a complex task, does not inherently resolve a 504 timeout originating from the API Gateway's synchronous integration. The primary Lambda function invoked by API Gateway still operates under the 29-second timeout limit for its initial response. If the orchestration or the first critical step of the parallelized workflow still takes longer than 29 seconds to return a response to API Gateway, the 504 error will persist, as the parallelization occurs after the initial synchronous call.