SAA-C03 Design Resilient Architectures Practice Question
An order-processing service consumes messages from an Amazon SQS Standard queue using a custom worker. During traffic spikes, the worker occasionally times out after performing some work but before acknowledging the message, so SQS redelivers it and it may be processed again.
You also observe that a small set of “poison” messages always fail validation.
What change most directly improves resilience by (1) preventing poison messages from retrying indefinitely and (2) avoiding duplicate side effects caused by legitimate retries?
⚠ Common exam trap
Test-takers frequently confuse FIFO queues as a universal solution for both deduplication and poison message handling, but FIFO only provides exactly-once processing within a deduplication window and does not automatically handle poison messages without a DLQ, nor does it address idempotency for retries outside that window.
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) with a redrive policy that moves messages after maxReceiveCount, and implement idempotent processing in the consumer using an idempotency key.
A dead-letter queue (DLQ) with a maxReceiveCount redrive policy directly addresses the poison message problem by moving messages that repeatedly fail validation out of the main queue after a set number of retries, preventing indefinite retries. Implementing idempotent processing using an idempotency key ensures that even if a legitimate message is redelivered due to a visibility timeout, the consumer can detect and skip duplicate side effects, thus solving both requirements most directly.
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 SQS visibility timeout and, when validation fails, call DeleteMessage in the consumer to remove the message immediately.
Why it's wrong here
Increasing the visibility timeout only gives the consumer more time to process, temporarily reducing the chance of redelivery while a message is in flight, but it does not prevent the retry loop for a message that consistently fails to validate or process. If the consumer calls DeleteMessage after validation failure, you are permanently discarding the poison message without any opportunity to inspect, log, or route it for remediation, which undermines operational debugging and can silently drop legitimate business events. SQS's actual poison-message solution is a dead-letter queue with a redrive policy that moves a message to a DLQ after the configured maxReceiveCount, allowing for isolation and recovery. Since this option lacks that DLQ-based quarantine and also does not implement idempotency to handle at-least-once redelivery of valid messages, it is insufficient.
When this WOULD be correct
This option would be correct if the question asked: 'How to ensure a message is not processed by another consumer while a worker is still handling it, and how to remove invalid messages immediately?' In that scenario, increasing visibility timeout prevents premature redelivery, and deleting on validation failure removes poison messages without further retries.
- ✗
Move to SNS topics with subscriptions and rely on SNS to provide exactly-once delivery to eliminate duplicates automatically.
Why it's wrong here
SNS is a pub/sub messaging service that does not offer exactly-once delivery semantics; its standard topic type delivers messages at least once and can produce duplicates during retries or due to network issues. Subscribers (e.g., SQS queues) still need their own idempotency handling because SNS does not deduplicate messages for you. Moreover, switching to SNS does not address the core problem of poison messages: SNS lacks a built-in dead-letter queue with redrive policies like SQS, so you'd still need to design a quarantine mechanism separately. Therefore, this option fails to provide the required duplicate protection and poison-message handling.
When this WOULD be correct
This option would be correct if the question required decoupling message publication from processing, fanning out messages to multiple subscribers, and did not require poison message handling or duplicate prevention.
- ✓
Configure a dead-letter queue (DLQ) with a redrive policy that moves messages after maxReceiveCount, and implement idempotent processing in the consumer using an idempotency key.
Why this is correct
SQS Standard is at-least-once delivery, so timeouts can cause redelivery and duplicates. A DLQ with a redrive policy prevents poison messages from retrying forever by moving them after repeated failures. Idempotent processing (for example, storing a processed marker in a database with conditional logic keyed by an idempotency key) prevents duplicate side effects when retries occur for valid messages.
- ✗
Change the queue to FIFO and enable content-based deduplication, leaving the consumer logic unchanged.
Why it's wrong here
FIFO with content-based deduplication may reduce some duplicates, but it does not guarantee protection against duplicate side effects when the consumer times out or fails after partially processing. Poison-message retry loops still need a DLQ/redrive approach, and idempotency is still required to make processing safe under retries.
When this WOULD be correct
A question where the requirement is to eliminate duplicate messages entirely and poison messages are not a concern, or where the consumer is idempotent and the main issue is message ordering and deduplication at the queue level.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓Configure a dead-letter queue (DLQ) with a redrive policy that moves messages after maxReceiveCount, and implement idempotent processing in the consumer using an idempotency key.Correct answer▾
Why this is correct
SQS Standard is at-least-once delivery, so timeouts can cause redelivery and duplicates. A DLQ with a redrive policy prevents poison messages from retrying forever by moving them after repeated failures. Idempotent processing (for example, storing a processed marker in a database with conditional logic keyed by an idempotency key) prevents duplicate side effects when retries occur for valid messages.
✗Increase the SQS visibility timeout and, when validation fails, call DeleteMessage in the consumer to remove the message immediately.Wrong answer — click to see why▾
Why this is wrong here
Increasing visibility timeout does not prevent poison messages from retrying indefinitely; they would still be redelivered until deleted manually. Also, deleting on validation failure only removes poison messages but does not address duplicate side effects from legitimate retries, as the worker may still process the same message multiple times before the timeout expires.
★ When this WOULD be the correct answer
This option would be correct if the question asked: 'How to ensure a message is not processed by another consumer while a worker is still handling it, and how to remove invalid messages immediately?' In that scenario, increasing visibility timeout prevents premature redelivery, and deleting on validation failure removes poison messages without further retries.
Why candidates choose this
Candidates may think that increasing visibility timeout gives enough time to acknowledge, and deleting poison messages on validation failure seems like a direct fix. They overlook that poison messages would still be retried until the visibility timeout expires, and that legitimate retries due to timeouts are not handled idempotently.
✗Move to SNS topics with subscriptions and rely on SNS to provide exactly-once delivery to eliminate duplicates automatically.Wrong answer — click to see why▾
Why this is wrong here
SNS does not provide exactly-once delivery; it delivers messages at least once, so duplicates can still occur. Additionally, SNS does not handle poison messages or retries, so it fails to address both requirements.
★ When this WOULD be the correct answer
This option would be correct if the question required decoupling message publication from processing, fanning out messages to multiple subscribers, and did not require poison message handling or duplicate prevention.
Why candidates choose this
Candidates may mistakenly believe SNS offers exactly-once delivery or confuse SNS's fan-out capability with SQS's message handling, overlooking that SNS alone cannot manage retries or poison messages.
✗Change the queue to FIFO and enable content-based deduplication, leaving the consumer logic unchanged.Wrong answer — click to see why▾
Why this is wrong here
FIFO queues guarantee exactly-once processing but do not prevent duplicate side effects from legitimate retries (e.g., after timeout) because the same message can be redelivered with a different deduplication ID. Also, poison messages would still retry indefinitely unless a DLQ is configured, which is not mentioned.
★ When this WOULD be the correct answer
A question where the requirement is to eliminate duplicate messages entirely and poison messages are not a concern, or where the consumer is idempotent and the main issue is message ordering and deduplication at the queue level.
Why candidates choose this
Candidates may think FIFO queues provide exactly-once delivery and thus solve both problems, overlooking that redeliveries due to timeouts can still cause duplicates and that poison messages need explicit handling via DLQ.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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.