DOP-C02 Incident and Event Response 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.

• ✗

  Decrease the SQS visibility timeout to retry faster.

  Why it's wrong here

  Reducing the SQS visibility timeout while the Lambda function is already timing out means messages become visible again in the queue before the function finishes, causing the event source mapping to redeliver them and trigger extra invocations. This not only risks duplicate processing but also increases the message receive count, potentially sending records to the dead-letter queue prematurely. It does nothing to address the root cause—the function running out of time—and should instead be increased to exceed the function's timeout.

• ✗

  Split the batch into smaller batches using partial batch response.

  Why it's wrong here

  Using partial batch response is a mechanism to report which individual records in an SQS batch failed, allowing Lambda to delete only the successes and retain the failures for later retry. However, a full function timeout means the entire batch is considered failed or lost, and splitting the batch into smaller batches simply reduces the number of records per invocation. The total processing workload remains the same, and if the function times out on a particular record, a smaller batch does not prevent that record from consuming the same amount of time.

• ✓

  Increase the Lambda timeout and increase the SQS visibility timeout, and add a dead-letter queue.

  Why this is correct

  The correct remediation is to first raise the Lambda timeout to a value that comfortably covers the actual processing duration for a batch, then set the SQS visibility timeout to at least that same timeout so the queue does not redeliver a message while the function is still processing it. Adding a dead-letter queue to the source SQS provides a safety net: after the configured retries (maxReceiveCount), messages that still fail are diverted to the DLQ, preserving them for analysis instead of silently expiring. This combination directly resolves the timeout issue and handles residual failures cleanly.

• ✗

  Reduce the Lambda reserved concurrency to limit invocations.

  Why it's wrong here

  Reducing reserved concurrency on the Lambda function throttles invocations from the SQS event source mapping, causing it to stop polling or to reject new events with throttling errors. As a result, messages remain invisible until the visibility timeout expires, then reappear, and the same messages may repeatedly timeout, inflating their receive count and potentially triggering a DLQ even though the function never got a full attempt. Concurrency limits do not reduce per-invocation execution time; they only reduce parallel throughput, so they would worsen the backlog and delay recovery rather than fix the timeout.

Go deeper

Related to this question