SAA-C03 Design Resilient Architectures Practice Question
A payments service receives payment orders by consuming messages from an Amazon SQS Standard queue. The downstream processor occasionally exceeds its processing timeout. As a result, some messages reappear in the queue and may be processed more than once.
The team wants to prevent duplicate side effects (for example, double-charging) and also ensure poison messages do not repeatedly consume processing capacity.
What approach best satisfies both goals?
⚠ Common exam trap
Test-takers frequently confuse 'exactly-once delivery' (FIFO queues) with 'exactly-once processing,' failing to realize that idempotency is still required to handle failures after message receipt, and that a DLQ is necessary to manage poison messages regardless of queue type.
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
✓
Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.
It addresses both requirements: idempotent processing (e.g., storing processed payment IDs in DynamoDB) ensures that even if a message is processed more than once, duplicate side effects like double-charging are prevented. Configuring an SQS dead-letter queue (DLQ) with a redrive policy and an appropriate maxReceiveCount (e.g., 3 or 5) automatically moves messages that exceed the maximum number of receives to the DLQ, preventing poison messages from repeatedly consuming processing capacity.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.
Why this is correct
With SQS Standard’s at-least-once delivery, duplicates can occur. Idempotency ensures repeated processing of the same payment ID does not create duplicate side effects. A DLQ with redrive policy isolates poison messages: after a message is received and fails processing more than maxReceiveCount times, SQS moves it to the DLQ instead of cycling it back to the main queue indefinitely.
- ✗
Rely only on increasing the SQS visibility timeout so duplicates rarely occur, without adding idempotency checks or a DLQ.
Why it's wrong here
Increasing the SQS visibility timeout only reduces the window in which a message can become visible again after a consumer fails to delete it; it does not eliminate at-least-once delivery, because a consumer can still crash mid-processing, or a message's visibility can expire during long-running tasks, causing the same payment order to be delivered again. Without idempotency checks, a duplicate delivery can lead to a second charge or duplicate side effect. Moreover, this approach ignores poison messages: if a message consistently fails to process (e.g., malformed payload), it will be retried indefinitely, clogging the queue and consuming resources without ever being moved to a DLQ.
When this WOULD be correct
This option would be correct in a scenario where the processing time is consistently predictable and the only concern is to avoid temporary overlaps, with no requirement for duplicate prevention or poison message handling.
- ✗
Switch to a FIFO queue and delete messages immediately upon receipt to avoid duplicates.
Why it's wrong here
Deleting a message immediately upon receipt is dangerous because it assumes the processing will always succeed; if the payment logic fails after deletion, the message is lost forever, and the payment order may never be processed, violating the reliability required for a payments workload. A FIFO queue does guarantee strict ordering and exactly-once delivery within a consumer group, but that guarantee only holds if you delete the message after successfully processing it and committing the side effect. Immediate deletion also defeats the purpose of SQS's at-least-once model, which exists to allow safe retries, and it does not address duplicate application-level side effects if processing itself is not idempotent.
When this WOULD be correct
A question where the requirement is to process messages in strict order without duplicates, and the processing is idempotent or the message is deleted only after successful processing (e.g., using a FIFO queue with a consumer that deletes after processing and a DLQ for failures).
- ✗
Move the workload to SNS and use synchronous HTTP endpoints so the sender retries until the receiver confirms success.
Why it's wrong here
SNS delivery is not a guaranteed exactly-once request/response mechanism. Even with retry behavior, duplicate deliveries and partial failures can still occur, and this approach does not directly provide the same DLQ + idempotency protections for at-least-once delivery semantics.
When this WOULD be correct
This option would be correct in a scenario where the team needs to fan out messages to multiple subscribers and requires immediate, synchronous confirmation of processing, with no concern for duplicate prevention or poison message handling.
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.
✓Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.Correct answer▾
Why this is correct
With SQS Standard’s at-least-once delivery, duplicates can occur. Idempotency ensures repeated processing of the same payment ID does not create duplicate side effects. A DLQ with redrive policy isolates poison messages: after a message is received and fails processing more than maxReceiveCount times, SQS moves it to the DLQ instead of cycling it back to the main queue indefinitely.
✗Rely only on increasing the SQS visibility timeout so duplicates rarely occur, without adding idempotency checks or a DLQ.Wrong answer — click to see why▾
Why this is wrong here
Increasing visibility timeout reduces duplicates but does not guarantee idempotency; messages can still be processed multiple times if the timeout is exceeded. It also fails to handle poison messages that repeatedly fail processing.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the processing time is consistently predictable and the only concern is to avoid temporary overlaps, with no requirement for duplicate prevention or poison message handling.
Why candidates choose this
Candidates may think that increasing visibility timeout is a simple fix to prevent duplicates, overlooking the need for idempotency and poison message management.
✗Switch to a FIFO queue and delete messages immediately upon receipt to avoid duplicates.Wrong answer — click to see why▾
Why this is wrong here
FIFO queues guarantee exactly-once processing, but the question states messages reappear due to processing timeout; deleting immediately upon receipt would lose messages that fail processing, and FIFO does not prevent duplicate side effects if processing is not idempotent.
★ When this WOULD be the correct answer
A question where the requirement is to process messages in strict order without duplicates, and the processing is idempotent or the message is deleted only after successful processing (e.g., using a FIFO queue with a consumer that deletes after processing and a DLQ for failures).
Why candidates choose this
Candidates may think FIFO queues eliminate duplicates entirely, but they only prevent duplicates during delivery, not during processing; they also overlook the need for idempotency and poison message handling.
✗Move the workload to SNS and use synchronous HTTP endpoints so the sender retries until the receiver confirms success.Wrong answer — click to see why▾
Why this is wrong here
SNS with synchronous HTTP endpoints does not guarantee exactly-once processing; the sender may still retry, and the receiver could process duplicates. It also lacks a mechanism to handle poison messages that repeatedly fail, as there is no dead-letter queue.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the team needs to fan out messages to multiple subscribers and requires immediate, synchronous confirmation of processing, with no concern for duplicate prevention or poison message handling.
Why candidates choose this
Candidates may think synchronous processing eliminates duplicates because the sender waits for a response, but they overlook that retries can still cause duplicates, and there is no built-in poison message handling.
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
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.