DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Reduce the Lambda timeout to 5 seconds to fail fast and retry quickly.

  Why it's wrong here

  Lowering the Lambda timeout to 5 seconds forces the function to terminate after a hard deadline, so any legitimate operation that genuinely needs more time—such as a downstream API call or database query—will be killed mid-execution. In an SQS-triggered architecture, that timeout is treated as a failure, which triggers immediate retries; failing fast under an artificially tight limit neither fixes the root cause nor reduces workload, and it increases the chance of duplicate attempt cycles without meaningful progress.

• ✗

  Set the SQS queue visibility timeout to less than the Lambda timeout.

  Why it's wrong here

  Configuring the SQS visibility timeout to be shorter than the Lambda timeout is a classic misconfiguration: while your Lambda function is still processing a batch, the message would already become visible again in the queue and be picked up by another poller or Lambda invocation. That results in the same message being processed concurrently, leading to duplicate side effects, possible out-of-order processing, and inflated cost. The visibility timeout must be at least as long as the function timeout—and ideally longer to cover Lambda retries and the event source mapping's internal handling—so that an in-flight message stays hidden until you either succeed, fail, or time out.

• ✗

  Increase the batch size and remove the DLQ to speed up processing.

  Why it's wrong here

  Increasing the batch size can help higher-throughput workloads by reducing the number of invocations, but it does not address a timeout failure—a larger batch simply means the same per-message work plus more overhead, making timeouts more likely if you are already hitting execution limits. Removing the dead-letter queue is the opposite of a resilience improvement: if messages exhaust the maximum receive count or Lambda retries fail, they would be silently lost or simply remain in the queue without a mechanism for redrive, costing you the ability to inspect, replay, or alert on them later. Under a timeout condition, you need more execution time and a DLQ, not a larger batch and no safety net.

• ✓

  Increase the Lambda timeout to 30 seconds and configure a dead-letter queue (DLQ) for the SQS queue.

  Why this is correct

  Increasing the Lambda function timeout to 30 seconds gives the SQS-triggered processor enough wall-clock time to complete network calls, database writes, or third-party integrations that were failing under a shorter timeout, while still remaining within a reasonable operational bound. Configuring a dead-letter queue (DLQ) on the SQS queue ensures that messages that still repeatedly fail after retries are moved to a separate queue for later inspection and redrive, preventing poison messages from consuming the main queue indefinitely. Together, these changes address the immediate failure mode and give you a durable, observable mechanism for handling the few messages that cannot be processed successfully.

Go deeper

Related to this question