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.

• ✗

  Configure a delay queue so that messages are not immediately visible after failure.

  Why it's wrong here

  Configuring a delay queue, or setting a message delay, makes messages invisible for a specified duration *when they are first sent to the queue*. This mechanism is designed to postpone initial processing, not to facilitate immediate reprocessing after a failure. Applying a delay would prevent immediate retries, as the message would remain invisible for the configured delay period, directly contradicting the requirement for immediate availability after a processing failure.

• ✓

  After a failure, call ChangeMessageVisibility with a timeout of 0 to make the message immediately available for reprocessing.

  Why this is correct

  When a consumer receives a message from an SQS queue, the message becomes invisible to other consumers for the duration of the queue's visibility timeout. If processing fails, calling `ChangeMessageVisibility` with a `VisibilityTimeout` of 0 seconds explicitly overrides the current visibility timeout. This action immediately makes the message visible again in the queue, allowing another consumer (or the same consumer on a subsequent poll) to receive and attempt to process it without delay, thus enabling immediate reprocessing.

• ✗

  Delete the message from the queue and re-send it after processing failure.

  Why it's wrong here

  Deleting a message and then re-sending it as a new message is an inefficient and problematic approach for handling processing failures. This method results in the loss of the original `MessageId` and `ReceiveCount`, which are crucial for tracking message history and properly handling poison pill messages via a Dead-Letter Queue. Furthermore, if the consumer crashes *after* deleting the original message but *before* successfully re-sending it, the message is permanently lost, violating message durability guarantees.

• ✗

  Increase the visibility timeout to allow more time for processing.

  Why it's wrong here

  Increasing the visibility timeout is appropriate when a message's processing logic genuinely requires more time to complete successfully, preventing the message from becoming visible to other consumers prematurely. However, in a scenario where immediate reprocessing after a *failure* is desired, increasing the visibility timeout would have the opposite effect. It would prolong the period during which the message remains invisible, thereby delaying any potential retry attempts and hindering the goal of immediate availability.

Go deeper

Related to this question