SAA-C03 Design Resilient Architectures Practice Question
A payments API uses Amazon SQS. Poison messages are repeatedly failing and blocking useful retries. What should the architect configure? The architecture review board prefers a managed AWS-native control.
⚠ Common exam trap
Candidates often confuse poison message handling with ordering or polling optimizations, and incorrectly choose FIFO queues or short polling, not realizing that only a DLQ with a redrive policy isolates repeatedly failing messages.
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
✓
A dead-letter queue with an appropriate maxReceiveCount
A dead-letter queue (DLQ) with an appropriate maxReceiveCount is the correct AWS-native solution for handling poison messages. When a message is repeatedly received from an SQS queue but fails processing, it is considered a poison message. By configuring a DLQ and setting a maxReceiveCount (e.g., 3 or 5), the message is automatically moved to the DLQ after exceeding that threshold, preventing it from blocking further retries and allowing the main queue to process valid messages.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A FIFO queue without a redrive policy
Why it's wrong here
A FIFO queue preserves ordering but provides no redrive policy, so repeatedly failing poison messages are never moved aside and continue blocking the queue. It tempts architects needing strict ordering for payment events, where FIFO with a dead-letter queue would be correct.
- ✓
A dead-letter queue with an appropriate maxReceiveCount
Why this is correct
A dead-letter queue with maxReceiveCount moves messages aside after a set number of failed receives, so poison messages stop blocking the main queue and useful retries continue. This is the managed, AWS-native control the review board requires, needing no custom code.
- ✗
A larger message retention period only
Why it's wrong here
Extending retention merely keeps failing messages available longer, so they still cycle through receive attempts and block useful retries. It tempts when messages are being lost before processing, where a longer retention period would genuinely help.
- ✗
Short polling instead of long polling
Why it's wrong here
Short polling returns immediately even when the queue is empty, so it changes retrieval latency, not the fate of poison messages that keep failing. It tempts when reducing cost or latency matters, but a redrive policy with a dead-letter queue is what isolates the failures.
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.