SAA-C03 Design Resilient Architectures Practice Question
Exhibit
Amazon SQS queue QueueName: payments-standard QueueType: Standard VisibilityTimeout: 120 seconds Worker logs 14:01:10 Received messageId=msg-4412 orderId=4412 14:03:09 Charged customer card successfully 14:03:10 Lambda timed out before DeleteMessage completed 14:03:35 Same message received again and charged a second time Business requirement A payment must never be charged twice even if a message is delivered again.
Based on the exhibit, the payment worker sometimes processes the same SQS Standard message more than once after a timeout. What change best prevents duplicate charges while keeping the queue architecture?
⚠ Common exam trap
It's easy for candidates to think increasing the visibility timeout (Option A) or switching to a FIFO queue (Option B) will solve duplicate processing, but they overlook that the root cause is the worker's timeout behavior, which requires application-level idempotency to prevent 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 workflow idempotent by recording a unique order key before charging.
Making the payment workflow idempotent ensures that even if the same SQS Standard message is processed more than once (due to a visibility timeout), the duplicate charge is prevented by checking a unique order key before processing. This is the most robust solution for handling at-least-once delivery semantics of Standard queues without changing the queue architecture.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the SQS visibility timeout to 15 minutes and leave the worker unchanged.
Why it's wrong here
A longer visibility timeout can reduce the chance of a duplicate becoming visible too early, but it does not guarantee correctness. A retry, function timeout, worker crash, or later redelivery can still cause a second charge if the business operation itself is not protected.
When this WOULD be correct
This option would be correct in a scenario where messages are consistently being processed before the visibility timeout expires, but the timeout is too short for the current processing time, causing unnecessary retries. Increasing the timeout to match the maximum processing time would prevent those retries.
- ✗
Replace the Standard queue with a FIFO queue and rely only on message ordering.
Why it's wrong here
FIFO queues help with ordering and can reduce duplicate delivery within a deduplication window, but they do not make an external payment call exactly once by themselves. The application still needs to protect the side effect.
When this WOULD be correct
If the question required ensuring exactly-once processing and message ordering without changing the worker logic, and the architecture allowed replacing the queue type, then using a FIFO queue would be correct. For example: 'A financial application must process payments in strict order without duplicates. Which queue type ensures this?'
- ✓
Make the payment workflow idempotent by recording a unique order key before charging.
Why this is correct
SQS Standard queues are at-least-once delivery, so duplicate messages are always possible. The correct safeguard is idempotency: store a unique order or payment request key, check whether that key has already been processed, and only perform the charge the first time it is seen. Any later delivery is safely ignored.
- ✗
Add a second consumer so duplicate messages are processed faster.
Why it's wrong here
Adding a second consumer only increases throughput; it does nothing to prevent a duplicate message from being delivered and charged twice. Standard SQS queues provide at-least-once delivery, so every message can arrive more than once, and with two consumers the same message may be picked up in parallel, making race conditions and double charges more likely rather than less. Without an idempotency key or similar guard, the payment side effect remains unprotected regardless of how many consumers are running.
When this WOULD be correct
When the goal is to increase throughput and reduce latency for processing messages, and duplicate processing is acceptable or handled elsewhere (e.g., idempotent 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 workflow idempotent by recording a unique order key before charging.Correct answer▾
Why this is correct
SQS Standard queues are at-least-once delivery, so duplicate messages are always possible. The correct safeguard is idempotency: store a unique order or payment request key, check whether that key has already been processed, and only perform the charge the first time it is seen. Any later delivery is safely ignored.
✗Increase the SQS visibility timeout to 15 minutes and leave the worker unchanged.Wrong answer — click to see why▾
Why this is wrong here
Increasing the visibility timeout to 15 minutes does not prevent duplicate processing; it only reduces the likelihood of timeouts causing duplicates. The worker can still process the same message twice if the timeout expires after 15 minutes, and the change does not address the root cause of duplicate charges.
★ When this WOULD be the correct answer
This option would be correct in a scenario where messages are consistently being processed before the visibility timeout expires, but the timeout is too short for the current processing time, causing unnecessary retries. Increasing the timeout to match the maximum processing time would prevent those retries.
Why candidates choose this
Candidates may think that a longer visibility timeout guarantees that a message won't be reprocessed, overlooking that timeouts can still occur after the increased duration, and that the fundamental issue of duplicate processing remains unaddressed.
✗Replace the Standard queue with a FIFO queue and rely only on message ordering.Wrong answer — click to see why▾
Why this is wrong here
FIFO queues guarantee exactly-once processing and ordering, but the question asks to prevent duplicate charges while keeping the queue architecture. Replacing Standard with FIFO changes the queue type, which may not be desired, and FIFO alone does not prevent duplicate charges if the worker is not idempotent.
★ When this WOULD be the correct answer
If the question required ensuring exactly-once processing and message ordering without changing the worker logic, and the architecture allowed replacing the queue type, then using a FIFO queue would be correct. For example: 'A financial application must process payments in strict order without duplicates. Which queue type ensures this?'
Why candidates choose this
Candidates know FIFO queues prevent duplicates and assume that solves the problem, overlooking that the worker must also be idempotent to handle retries, and that the question explicitly says 'keep the queue architecture' (i.e., Standard queue).
✗Add a second consumer so duplicate messages are processed faster.Wrong answer — click to see why▾
Why this is wrong here
Adding a second consumer does not prevent duplicate processing; it may even increase the chance of duplicates if both consumers process the same message after a timeout.
★ When this WOULD be the correct answer
When the goal is to increase throughput and reduce latency for processing messages, and duplicate processing is acceptable or handled elsewhere (e.g., idempotent workers).
Why candidates choose this
Candidates may think more consumers reduce the chance of any single message being processed twice, but they overlook that duplicate processing stems from visibility timeout issues, not consumer count.
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.