SAA-C03 Design Resilient Architectures Practice Question
Exhibit
Worker log excerpt: 2026-04-28T09:02:11Z messageId=7f31 receiveCount=1 status=ValidationError 2026-04-28T09:03:14Z messageId=7f31 receiveCount=2 status=ValidationError 2026-04-28T09:04:17Z messageId=7f31 receiveCount=3 status=ValidationError Queue metric: ApproximateNumberOfMessagesNotVisible keeps increasing
Based on the exhibit, some SQS messages fail validation repeatedly and continue consuming worker time. What change best prevents the bad messages from being retried forever?
⚠ Common exam trap
A common mix-up: candidates think increasing the visibility timeout or adding more workers will solve the retry problem, but neither addresses the root cause of a message that will always fail validation.
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 and a redrive policy for messages that exceed the retry limit.
A dead-letter queue (DLQ) with a redrive policy allows messages that have been received a maximum number of times (e.g., after the configured retry limit) to be moved to a separate queue for analysis or manual handling. This prevents the same invalid message from being repeatedly processed by workers, freeing up compute resources and avoiding infinite retry loops.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the visibility timeout so each message has more time to finish processing.
Why it's wrong here
Increasing the visibility timeout delays when a failed message reappears, because SQS returns the message to the queue after the timeout expires unless the consumer deletes it. For a malformed message that always fails validation, the same failure will recur on every subsequent delivery, and a longer timeout merely extends the interval between retries. It does not change the receive count or the fact that the message is poison; it only ties up the message and can slow down processing of valid messages behind it.
- ✓
Configure a dead-letter queue and a redrive policy for messages that exceed the retry limit.
Why this is correct
Configuring a dead-letter queue (DLQ) with a redrive policy is the canonical AWS pattern for catching poison messages. The redrive policy specifies a maxReceiveCount (e.g., 5); after a message is received that many times without being deleted, SQS automatically moves it to the DLQ. This isolates the repeatedly failing message from the main queue so downstream workers can continue processing healthy messages without hitting the same bad payload repeatedly. Once in the DLQ, you can inspect, correct, or manually reprocess the message after fixing the underlying data issue.
- ✗
Replace the queue with an Amazon SNS topic so failed messages will not be retried.
Why it's wrong here
Amazon SNS is a pub/sub push service, not a message queue; it does not hold messages for consumers to pull and does not natively track per-message processing results. Replacing SQS with SNS would change the delivery model entirely, but the consumer application still processes payloads and still encounters the same validation failure. SNS lacks a dead-letter mechanism based on consumer retry counts (unless you subscribe an SQS queue and add a DLQ), so it does not solve the repeated-retry problem for a malformed message.
- ✗
Increase the number of workers so the queue drains faster during peak load.
Why it's wrong here
Adding more workers increases the rate at which messages are consumed and can improve throughput, but it has no effect on a message that always fails validation. Each of the additional workers will pick up the same poison message again and again, causing repeated exceptions, wasted compute, and inflated receive counts. The problem is data quality, not processing capacity, so scaling out only amplifies the churn of failed attempts rather than eliminating the root cause.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.