SAA-C03 Design Resilient Architectures Practice Question

A worker service consumes messages from an Amazon SQS queue. Some messages are malformed and always fail validation. The worker retries, but it keeps reprocessing the same bad messages and consumes processing capacity that should be used for valid work. What is the best solution to prevent “poison messages” from blocking progress?

⚠ Common exam trap

Many candidates think increasing the visibility timeout or deleting messages on error is a valid solution, but AWS specifically designed the DLQ pattern to isolate poison messages without losing data or impacting throughput.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure a Dead-Letter Queue (DLQ) and set a redrive policy so messages move to the DLQ after a maximum number of receives.

A Dead-Letter Queue (DLQ) with a redrive policy is the standard AWS mechanism for handling poison messages. By setting a maximum receive count (e.g., 5), the SQS queue automatically moves messages that fail processing repeatedly to the DLQ, isolating them from the main queue. This prevents the worker from wasting capacity on invalid messages and allows the main queue to continue processing valid work without interruption.

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 Dead-Letter Queue (DLQ) and set a redrive policy so messages move to the DLQ after a maximum number of receives.
Why this is correct
Configuring a Dead-Letter Queue (DLQ) with a redrive policy is the most effective solution. This mechanism automatically moves messages that fail processing a specified number of times (maxReceiveCount) from the source queue to the DLQ. This prevents 'poison pill' messages from continuously consuming worker resources and allows for their isolation, analysis, and eventual reprocessing or discarding without impacting the main message flow.
✗
Increase the visibility timeout so the worker gets fewer retries per hour.
Why it's wrong here
Increasing the visibility timeout only delays the inevitable re-delivery of the problematic message to the worker. While it reduces the frequency of retries within a given hour, it does not address the fundamental issue of the message being malformed or unprocessable. The message will still eventually become visible again and continue to fail, tying up worker capacity and generating unnecessary processing attempts.
✗
Disable SQS retries by deleting messages immediately on any processing error.
Why it's wrong here
Disabling SQS retries by immediately deleting messages upon any processing error is a detrimental approach. This action results in irreversible data loss for any message that fails, preventing crucial troubleshooting efforts to diagnose the root cause of the error. Furthermore, it eliminates any possibility of reprocessing messages after the underlying validation logic or worker code has been corrected, leading to lost business data.
✗
Create a second worker that polls the queue less frequently until the malformed message is processed successfully.
Why it's wrong here
Creating a second worker that polls the queue less frequently does not resolve the core problem of a malformed message. The issue lies with the message content itself or the worker's inability to process it, not the polling rate. Regardless of how often a worker attempts to process it, the message will consistently fail validation, leading to continued resource consumption without successful completion.

Go deeper

SAA-C03 Design Resilient Architectures Practice Question

Why each option matters

Option-by-option breakdown

Related to this question