SAA-C03 Design Resilient Architectures Practice Question
Exhibit
Amazon SQS worker log: 2026-04-27T14:02:11Z Received messageId=82f3a9 paymentId=78341 receiveCount=1 2026-04-27T14:02:57Z Charged card successfully for paymentId=78341 2026-04-27T14:03:05Z Timeout occurred before DeleteMessage 2026-04-27T14:03:12Z Received messageId=82f3a9 paymentId=78341 receiveCount=2 2026-04-27T14:03:43Z Duplicate charge blocked manually Queue configuration: VisibilityTimeout=30 seconds RedrivePolicy=not configured
Based on the exhibit, duplicate payment charges occasionally occur when the worker times out after the charge is submitted but before the message is deleted. What change best prevents duplicate charges while keeping retry behavior?
⚠ Common exam trap
Many candidates assume FIFO queues with deduplication guarantee exactly-once processing, but they fail to recognize that deduplication only prevents duplicate message delivery, not duplicate processing when the consumer times out after processing but before acknowledging the message.
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
✓
Make the consumer idempotent by storing a processed payment key and rejecting repeat charges.
Making the consumer idempotent ensures that even if the same message is processed more than once (due to a timeout after the charge is submitted but before the message is deleted), the duplicate charge will be rejected. By storing a processed payment key (e.g., a unique transaction ID) and checking it before processing, the system can safely retry without causing duplicate payments. This approach preserves retry behavior while preventing duplicates, which is the core requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch the queue to FIFO and rely on content-based deduplication to guarantee exactly-once processing.
Why it's wrong here
FIFO queues provide exactly-once delivery within a five-minute deduplication window, but content-based deduplication uses the message body hash, so a retry with the same body after that window or with a slightly altered field produces a separate message. More fundamentally, if the consumer calls the payment API successfully but then crashes before deleting the message, FIFO redelivers it after the visibility timeout, causing the same charge to execute again. FIFO reduces duplicate deliveries but does not make an external side effect such as a credit-card charge idempotent.
When this WOULD be correct
A question where the requirement is to guarantee exactly-once delivery of messages in a distributed system, and the application can tolerate a 5-minute deduplication window. For example: 'A financial application must ensure that payment requests are processed exactly once, even if the producer sends duplicate messages. Which queue type should be used?'
- ✓
Make the consumer idempotent by storing a processed payment key and rejecting repeat charges.
Why this is correct
The worker can still receive the same message more than once because SQS Standard is at-least-once delivery and the delete happened after the charge. Idempotency is the correct safety control because it prevents the payment from being applied twice even when the message is retried. A processed-payment record or conditional write lets retries remain possible without creating duplicate charges.
- ✗
Reduce the visibility timeout so the message becomes available again sooner after a timeout.
Why it's wrong here
The visibility timeout only prevents other workers from seeing a message while it is being processed; shortening it makes the message visible again sooner, increasing the chance that two workers or the same worker on retry will process it concurrently. If the original worker is still executing the charge when the timeout expires, another delivery can start the payment again. A shorter visibility timeout therefore amplifies duplicate-processing risk instead of protecting the consumer from repeated side effects.
When this WOULD be correct
This option would be correct in a scenario where the goal is to minimize latency for retrying failed messages, and duplicate processing is acceptable or handled elsewhere. For example, a question asking 'How to ensure a message is retried quickly after a worker failure?' would make reducing visibility timeout the best answer.
- ✗
Add a dead-letter queue and disable retries so the message is never processed twice.
Why it's wrong here
A dead-letter queue does not change SQS's at-least-once delivery semantics; it merely captures messages that exhaust their retry count. Disabling retries would cause message loss if the consumer crashes after receiving the message but before deleting it, and even with retries enabled the identical message can be redelivered when the original worker times out or fails to delete. Since the payment side effect occurs before deletion, the duplicate charge can still happen regardless of DLQ configuration.
When this WOULD be correct
A question where the requirement is to prevent duplicate processing of poison-pill messages that cannot be handled successfully, and retries are not needed. For example: 'An order processing system fails repeatedly on certain malformed messages. What is the most cost-effective way to isolate these messages for manual inspection without retrying them?'
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.
✓Make the consumer idempotent by storing a processed payment key and rejecting repeat charges.Correct answer▾
Why this is correct
The worker can still receive the same message more than once because SQS Standard is at-least-once delivery and the delete happened after the charge. Idempotency is the correct safety control because it prevents the payment from being applied twice even when the message is retried. A processed-payment record or conditional write lets retries remain possible without creating duplicate charges.
✗Switch the queue to FIFO and rely on content-based deduplication to guarantee exactly-once processing.Wrong answer — click to see why▾
Why this is wrong here
FIFO queues with content-based deduplication provide exactly-once delivery, but the issue here is a timeout after submission but before deletion, which can still cause duplicate processing if the worker retries. FIFO deduplication does not prevent duplicate charges if the same message is sent again after a timeout, as deduplication is based on message content within a 5-minute window, not on processing state.
★ When this WOULD be the correct answer
A question where the requirement is to guarantee exactly-once delivery of messages in a distributed system, and the application can tolerate a 5-minute deduplication window. For example: 'A financial application must ensure that payment requests are processed exactly once, even if the producer sends duplicate messages. Which queue type should be used?'
Why candidates choose this
Candidates often associate FIFO queues with exactly-once processing and assume that deduplication solves all duplicate issues, without considering that the duplicate here arises from a retry after a timeout, not from duplicate message sends.
✗Reduce the visibility timeout so the message becomes available again sooner after a timeout.Wrong answer — click to see why▾
Why this is wrong here
Reducing the visibility timeout would cause the message to reappear sooner after a timeout, increasing the likelihood of duplicate processing rather than preventing it. It does not address the root cause of duplicate charges when the worker times out after submitting the charge.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the goal is to minimize latency for retrying failed messages, and duplicate processing is acceptable or handled elsewhere. For example, a question asking 'How to ensure a message is retried quickly after a worker failure?' would make reducing visibility timeout the best answer.
Why candidates choose this
Candidates may think that making the message available again faster will reduce the chance of duplicate charges by allowing the worker to delete the message before a new attempt, but they overlook that the duplicate charge has already occurred before the timeout.
✗Add a dead-letter queue and disable retries so the message is never processed twice.Wrong answer — click to see why▾
Why this is wrong here
Adding a dead-letter queue and disabling retries prevents duplicate charges by eliminating retries, but the question explicitly requires keeping retry behavior. This option removes retries, which violates the requirement.
★ When this WOULD be the correct answer
A question where the requirement is to prevent duplicate processing of poison-pill messages that cannot be handled successfully, and retries are not needed. For example: 'An order processing system fails repeatedly on certain malformed messages. What is the most cost-effective way to isolate these messages for manual inspection without retrying them?'
Why candidates choose this
Candidates may think that a dead-letter queue is a standard solution for preventing duplicates, and disabling retries seems like a direct way to avoid reprocessing, overlooking the explicit requirement to retain retry behavior.
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.