- A
Assume the consumer will always delete the SQS message in the same execution path, and ignore the timeout case.
Why wrong: Timeouts and crashes do occur; assuming deletion always succeeds leads directly to duplicate processing.
- B
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.
Idempotency based on a stable identifier prevents duplicates by making processing repeatable and safely detectable.
- C
Switch to SQS Standard because it provides exactly-once delivery, so duplicates cannot happen.
Why wrong: SQS Standard is at-least-once delivery; duplicates can still occur, and exactly-once is not guaranteed.
- D
Increase the consumer timeout and reduce the number of retries so that duplicates rarely occur.
Why wrong: Reducing retries lowers frequency but does not guarantee correctness; resilience requires correctness under duplicates.
Quick Answer
The answer is to use idempotency by storing a deterministic payment request identifier in a DynamoDB table with a conditional write. This design ensures that even when the same SQS message is delivered multiple times due to consumer timeouts, the payment is created only once because the conditional write will fail if the identifier already exists. This directly addresses the core challenge of SQS’s at-least-once delivery semantics, where a consumer might process a message, create a payment record, but time out before deleting the message, leading to duplicate processing. On the SAA-C03 exam, this scenario tests your understanding of idempotency for SQS consumers to prevent duplicate payments, often appearing as a trap where candidates mistakenly focus on increasing visibility timeouts or using FIFO queues alone. A common memory tip is “DynamoDB conditional write = one-shot payment lock,” reminding you that the database itself enforces exactly-once processing regardless of how many times the message is redelivered.
SAA-C03 Design Resilient Architectures Practice Question
This SAA-C03 practice question tests your understanding of design resilient architectures. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
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?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue:
"best"Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
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.
Option B is correct because 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.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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
Timeouts and crashes do occur; assuming deletion always succeeds leads directly to duplicate processing.
- ✓
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
Idempotency based on a stable identifier prevents duplicates by making processing repeatable and safely detectable.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
Switch to SQS Standard because it provides exactly-once delivery, so duplicates cannot happen.
Why it's wrong here
SQS Standard is at-least-once delivery; duplicates can still occur, and exactly-once is not guaranteed.
- ✗
Increase the consumer timeout and reduce the number of retries so that duplicates rarely occur.
Why it's wrong here
Reducing retries lowers frequency but does not guarantee correctness; resilience requires correctness under duplicates.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates 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.
Detailed technical explanation
How to think about this question
DynamoDB conditional writes use the `ConditionExpression` parameter to check that an item does not already exist before writing, leveraging the table's primary key as a unique constraint. This approach is atomic and consistent, even under concurrent access, because DynamoDB ensures serializable isolation for conditional writes. In practice, the payment request identifier should be derived from idempotent fields (e.g., order ID + timestamp) to guarantee uniqueness across retries, and the DynamoDB table should be configured with on-demand capacity to handle burst retries without throttling.
KKey Concepts to Remember
- Read the scenario before looking for a memorised answer.
- Find the constraint that changes the correct option.
- Eliminate answers that are true in general but not in this case.
TExam Day Tips
- Watch for words such as best, first, most likely and least administrative effort.
- Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A cloud solutions architect for a retail company is evaluating services for a new workload. The correct answer here reflects best practice for the specific scenario described — not a general cloud recommendation. Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option. Cloud exam questions reward reading the constraint carefully: the same technology can be right or wrong depending on the use case.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
- →
Design Resilient Architectures — study guide chapter
Learn the concepts, then practise the questions
- →
Design Resilient Architectures practice questions
Targeted practice on this topic area only
- →
All SAA-C03 questions
1,040 questions across all exam domains
- →
SAA-C03 study guide
Full concept coverage aligned to exam objectives
- →
SAA-C03 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
Related SAA-C03 practice-question pages
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Design Secure Architectures practice questions
Practise SAA-C03 questions linked to Design Secure Architectures.
Design Resilient Architectures practice questions
Practise SAA-C03 questions linked to Design Resilient Architectures.
Design High-Performing Architectures practice questions
Practise SAA-C03 questions linked to Design High-Performing Architectures.
Design Cost-Optimized Architectures practice questions
Practise SAA-C03 questions linked to Design Cost-Optimized Architectures.
SAA-C03 VPC practice questions
Practise SAA-C03 questions linked to SAA-C03 VPC.
SAA-C03 S3 lifecycle policy questions
Practise SAA-C03 questions linked to SAA-C03 S3 lifecycle policy questions.
SAA-C03 RDS Multi-AZ questions
Practise SAA-C03 questions linked to SAA-C03 RDS Multi-AZ questions.
SAA-C03 IAM policy practice questions
Practise SAA-C03 questions linked to SAA-C03 IAM policy.
SAA-C03 Route 53 failover questions
Practise SAA-C03 questions linked to SAA-C03 Route 53 failover questions.
SAA-C03 CloudFront practice questions
Practise SAA-C03 questions linked to SAA-C03 CloudFront.
SAA-C03 NAT gateway questions
Practise SAA-C03 questions linked to SAA-C03 NAT gateway questions.
SAA-C03 VPC endpoint questions
Practise SAA-C03 questions linked to SAA-C03 VPC endpoint questions.
Practice this exam
Start a free SAA-C03 practice session
Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.
FAQ
Questions learners often ask
What does this SAA-C03 question test?
Design Resilient Architectures — This question tests Design Resilient Architectures — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: 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. — Option B is correct because 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.
What should I do if I get this SAA-C03 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "best". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. An orders service consumes payment instructions from an Amazon SQS queue. Sometimes the consumer times out after applying the payment but before deleting the SQS message. As a result, the same payment instruction is processed again. Which design change most directly prevents duplicate side effects caused by message retries?
easy- A.Delete the SQS message immediately after it is received, before processing, to ensure it is not retried.
- ✓ B.Implement idempotency by recording a processed marker keyed by the instruction ID and ignoring duplicates.
- C.Increase the SQS visibility timeout to a maximum value to avoid retries entirely.
- D.Convert the queue to FIFO and enable content-based deduplication.
Why B: Option B is correct because implementing idempotency ensures that even if the same payment instruction is processed multiple times due to a timeout and retry, the side effect (e.g., applying the payment) occurs only once. By recording a processed marker keyed by the instruction ID (e.g., using a DynamoDB table or Redis), the consumer can check the marker before processing and ignore duplicates. This directly addresses the root cause—duplicate processing—without altering the queue's retry behavior.
Variation 2. An order-processing worker consumes messages from Amazon SQS. Occasionally, the worker times out after successfully creating a payment record but before deleting the message, which causes duplicate charges during retries. Some messages also fail validation repeatedly because required fields are missing. Which two changes should the team make? Select two.
medium- ✓ A.Make the payment step idempotent using a unique transaction identifier.
- ✓ B.Configure an SQS dead-letter queue with a redrive policy.
- C.Reduce the visibility timeout so failed messages return to the queue faster.
- D.Run only one long-lived worker instance so the queue can never be processed twice.
- E.Switch from a standard queue to a FIFO queue and remove all other changes.
Why A: Option A is correct because making the payment step idempotent using a unique transaction identifier ensures that if the same message is processed multiple times due to a timeout, the payment is only charged once. This is a common pattern for handling at-least-once delivery semantics in Amazon SQS, where the worker must be designed to handle duplicate messages safely.
Variation 3. A payment worker consumes messages from an Amazon SQS queue. Sometimes the worker finishes the payment creation, but a timeout prevents message deletion and the same payment request is delivered again. Which two design changes best reduce the risk of duplicate charges and keep bad messages from looping forever? Select two.
medium- ✓ A.Make the payment operation idempotent by storing a unique request identifier before charging.
- B.Reduce the visibility timeout so retries happen sooner after each timeout.
- C.Move the queue to Amazon SNS so each message is delivered only once.
- D.Increase the message retention period so failed payments stay available longer.
- ✓ E.Configure a dead-letter queue with a redrive policy for messages that exceed the max receive count.
Why A: Option A is correct because making the payment operation idempotent ensures that even if the same message is processed multiple times due to a timeout, the payment is only charged once. This is typically achieved by storing a unique request identifier (e.g., a UUID or idempotency key) in a database or cache before processing; subsequent duplicate requests with the same identifier are detected and ignored, preventing duplicate charges.
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.