SAA-C03 Design Resilient Architectures Practice Question
An internal worker consumes messages from an Amazon SQS queue. Occasionally, a message fails validation in the worker (for example, missing required fields). Reprocessing the same bad message repeatedly wastes processing time and delays healthy messages. What is the best AWS approach to handle these poison messages without blocking the rest of the queue?
⚠ Common exam trap
It's easy for candidates to think increasing timeouts or relying on application retries alone can solve the problem, but they fail to recognize that only a DLQ with a redrive policy provides automatic, queue-level isolation of poison messages without blocking healthy message processing.
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 an SQS dead-letter queue (DLQ) using a redrive policy with a maxReceiveCount.
An SQS dead-letter queue (DLQ) with a redrive policy that sets a maxReceiveCount allows the worker to process a message up to a specified number of times. After that threshold is exceeded, the message is automatically moved to the DLQ, isolating the poison message and preventing it from blocking or delaying the processing of healthy messages in the main queue.
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 an SQS dead-letter queue (DLQ) using a redrive policy with a maxReceiveCount.
Why this is correct
With a redrive policy, SQS continues delivering the message to consumers until it has been received unsuccessfully maxReceiveCount times. After that threshold, SQS moves the poison message to a DLQ, isolating it from the main processing flow so healthy messages can continue being processed.
- ✗
Delete the SQS queue and recreate it daily to clear invalid messages.
Why it's wrong here
Recreating the queue is not a targeted remediation strategy. It can cause downtime, disrupt consumers, and provides no controlled way to isolate only the invalid payloads. It also risks losing visibility into the problematic messages.
- ✗
Increase the consumer timeout/processing time so validation failures take longer to occur.
Why it's wrong here
Timeout changes how long the worker runs, but it does not prevent SQS from redelivering the same invalid message when it is not successfully processed and deleted. The same poison message will still be retried and continue to consume worker capacity.
- ✗
Use SNS fan-out without any DLQ and rely only on application retries.
Why it's wrong here
SNS fan-out only broadcasts each event to multiple subscribed endpoints; it introduces no redrive policy or built-in poison-pill isolation. If the SQS queue consumed by the worker sits behind that SNS subscription, the same malformed event is still redelivered by SQS until the worker deletes it, so the worker keeps tying up capacity on a message that will never parse. Application-level retries with exponential backoff can slow the cycle but do not quarantine the poison message, leaving a recurring processing bottleneck and potentially stalling downstream consumers.
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.