SAA-C03 Design Resilient Architectures Practice Question
An orders system sends payment instructions to an Amazon SQS queue. The consumer sometimes times out after it has already created the payment record but before it deletes the SQS message. As a result, the same instruction can be processed more than once. Which design best ensures the consumer remains resilient and does not create duplicate payments when the same instruction is delivered multiple times?
⚠ Common exam trap
Watch out — candidates often assume SQS FIFO queues provide exactly-once delivery, but the question specifies an SQS queue (likely Standard), and even FIFO queues only guarantee exactly-once processing within a limited deduplication window, not absolute idempotency; the correct solution is to make the consumer itself idempotent.
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
✓
Use idempotency: store a deterministic payment request identifier in a DynamoDB table and only create a payment when a conditional write indicates it was not processed before.
It implements idempotency using a DynamoDB table with a conditional write. By storing a deterministic payment request identifier (e.g., a hash of the message body) and only creating the payment if the conditional write succeeds (i.e., the identifier does not already exist), the consumer can safely process the same SQS message multiple times without creating duplicate payments. This pattern ensures resilience against the at-least-once delivery semantics of SQS and consumer timeouts that prevent message deletion.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Assume the consumer will always delete the SQS message in the same execution path, and ignore the timeout case.
Why it's wrong here
Relying on the same execution path for successful deletion is unsafe because SQS operates with a visibility timeout: if the consumer crashes, times out, or hits a network error after processing the message but before calling DeleteMessage, the message becomes visible again and is delivered to another worker. Even a perfectly coded path can be interrupted by process termination or a Lambda timeout between payment creation and deletion, producing the exact duplicate you are trying to avoid. There is no way to guarantee deletion happens on the first try without adding a persistent marker of completed work, so ignoring the timeout case leaves a clear double-payment risk.
- ✓
Use idempotency: store a deterministic payment request identifier in a DynamoDB table and only create a payment when a conditional write indicates it was not processed before.
Why this is correct
Implementing idempotency with a DynamoDB table keyed by a deterministic payment request ID (for example, an MD5/SHA-256 hash of the order ID, amount, and currency) lets a consumer use a conditional PutItem with ConditionExpression 'attribute_not_exists(id)'. A successful conditional write claims the ID for the first request; a failed write on retry tells the consumer the payment was already handled, so no charge is created again. This turns at-least-once SQS delivery into effectively exactly-once processing because duplicate messages either see the existing record or lose the race to create it, and the payment action is triggered only on the first successful claim.
- ✗
Switch to SQS Standard because it provides exactly-once delivery, so duplicates cannot happen.
Why it's wrong here
This is the inverse of the truth: Amazon SQS Standard is an at-least-once service, meaning duplicate messages are possible when a producer retries or when a message is redelivered after a visibility timeout, so it cannot provide exactly-once delivery. The option appears to confuse SQS Standard with SQS FIFO, which offers deduplication, but even FIFO's batch-level dedup does not replace the need for an idempotent consumer to handle retries from the application's own processing logic. Switching queues does not remove the fundamental trade-off that distributed message delivery cannot guarantee exactly once; it only changes the frequency of duplicates.
- ✗
Increase the consumer timeout and reduce the number of retries so that duplicates rarely occur.
Why it's wrong here
Tuning the visibility timeout and the retry count can lower the probability of duplicates, but it cannot eliminate them, because a consumer that crashes mid-processing after reading a message still causes redelivery once the timeout expires. Reducing retries also risks dropping legitimate messages, which in a payment flow leads to lost orders or missed charges rather than solving the correctness problem. Distributed reliability demands that the system behave correctly when duplicates do happen, which is exactly the job of idempotency, so this mitigation is merely a band-aid, not a fix.
Go deeper
Related to this question
About these practice questions
One of 935 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.