SAA-C03 Design Resilient Architectures Practice Question
A service processes customer payments from a message queue. Because the queue provides at-least-once delivery, the same payment message can be delivered more than once if the consumer times out before committing its state. Currently, the service sometimes charges the customer twice.
Which design change most directly prevents duplicate charges while still allowing safe retries?
⚠ Common exam trap
Many exam-takers confuse at-least-once delivery with exactly-once delivery and assume that increasing visibility timeouts or using single-threaded consumers will prevent duplicates, when in fact only idempotency guarantees safe retries without duplicate charges.
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 payment processing idempotent by recording an idempotency key for each payment and ensuring repeated deliveries do not apply the charge twice.
Making payment processing idempotent using an idempotency key ensures that even if the same message is delivered multiple times due to at-least-once delivery semantics, the charge is applied only once. The consumer records a unique key (e.g., payment ID) in a durable store (like DynamoDB or Redis) and checks it before processing; if the key already exists, the charge is skipped. This directly prevents duplicate charges while still allowing safe retries, as the consumer can safely reprocess messages without side effects.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Delete the message from the queue immediately after receive to prevent redelivery.
Why it's wrong here
Deleting a message immediately after receive means the queue no longer retains it, so if the consumer fails before finishing the payment, the message is permanently lost and the charge never happens. In contrast, standard practice is to change visibility or lease and delete only after successful processing. This strategy also does not address duplicate delivery that occurred before deletion or from other concurrent consumers, so it fails to ensure consistency.
When this WOULD be correct
If the question required exactly-once processing with no retries and the consumer could guarantee successful processing upon receipt, deleting immediately would be correct.
- ✓
Make the payment processing idempotent by recording an idempotency key for each payment and ensuring repeated deliveries do not apply the charge twice.
Why this is correct
Because message queues provide at-least-once delivery, a payment message may be delivered multiple times if a consumer times out or fails after processing. By writing the payment's idempotency key (for example, a payment reference) to a durable store with a unique constraint before applying the charge, the consumer can detect and ignore repeated deliveries. This ensures the charge happens exactly once even when a redelivery occurs, making the system safe against at-least-once semantics.
- ✗
Increase the queue visibility timeout to a very large value so messages rarely reappear.
Why it's wrong here
Setting a very long visibility timeout can temporarily hide a message, but once the timeout lapses—whether due to consumer failure, crash, or normal lease renewal—the message will reappear and be redelivered. This approach merely postpones duplicates rather than preventing them, and it dangerously increases the detection time for a truly failed payment job. It also gives no protection against a message that is redelivered after a successful charge but before deletion.
When this WOULD be correct
This option would be correct in a scenario where the queue is used for time-sensitive tasks that must not be processed concurrently, and the consumer is highly reliable with minimal failure risk, such as processing a single critical job that should not be retried quickly.
- ✗
Switch to a single-threaded consumer with one worker so messages are processed in order.
Why it's wrong here
Constraining the system to a single-threaded consumer reduces concurrent processing conflicts but does nothing to change the queue's at-least-once redelivery behavior. If the message visibility timeout expires while the message is still being processed, the same message can be redelivered and processed again, even by the same single worker. It sacrifices scalability and throughput while failing to solve the duplicate-charging problem.
When this WOULD be correct
This option would be correct in a scenario where the queue guarantees exactly-once delivery but the consumer needs to maintain strict ordering and avoid race conditions from multiple concurrent workers.
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 payment processing idempotent by recording an idempotency key for each payment and ensuring repeated deliveries do not apply the charge twice.Correct answer▾
Why this is correct
Because message queues provide at-least-once delivery, a payment message may be delivered multiple times if a consumer times out or fails after processing. By writing the payment's idempotency key (for example, a payment reference) to a durable store with a unique constraint before applying the charge, the consumer can detect and ignore repeated deliveries. This ensures the charge happens exactly once even when a redelivery occurs, making the system safe against at-least-once semantics.
✗Delete the message from the queue immediately after receive to prevent redelivery.Wrong answer — click to see why▾
Why this is wrong here
Deleting the message immediately after receive prevents redelivery but also eliminates the ability to retry if processing fails, which violates the requirement of allowing safe retries.
★ When this WOULD be the correct answer
If the question required exactly-once processing with no retries and the consumer could guarantee successful processing upon receipt, deleting immediately would be correct.
Why candidates choose this
Candidates may think that eliminating redelivery directly solves duplicate charges, overlooking the need for retries in case of failures.
✗Increase the queue visibility timeout to a very large value so messages rarely reappear.Wrong answer — click to see why▾
Why this is wrong here
Increasing the visibility timeout to a very large value does not guarantee that a consumer won't crash or timeout, and it can delay processing of other messages, leading to potential bottlenecks and still allowing duplicate charges if the consumer fails after processing but before deleting the message.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the queue is used for time-sensitive tasks that must not be processed concurrently, and the consumer is highly reliable with minimal failure risk, such as processing a single critical job that should not be retried quickly.
Why candidates choose this
Candidates may think that a larger visibility timeout prevents message redelivery during normal processing, overlooking that failures or timeouts can still occur, and that this approach does not address the root cause of duplicate processing due to at-least-once delivery semantics.
✗Switch to a single-threaded consumer with one worker so messages are processed in order.Wrong answer — click to see why▾
Why this is wrong here
Single-threading does not prevent duplicate charges because the same message can still be redelivered after a timeout, even with one worker; the core issue is at-least-once delivery, not concurrency.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the queue guarantees exactly-once delivery but the consumer needs to maintain strict ordering and avoid race conditions from multiple concurrent workers.
Why candidates choose this
Candidates may think that processing messages sequentially eliminates duplicates, but they overlook that at-least-once delivery can still cause redelivery of the same message to a single-threaded consumer.
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.