Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
A
Best answer
Implement idempotent processing (for example, store processed payment IDs in DynamoDB) and configure an SQS dead-letter queue (DLQ) using a redrive policy with an appropriate maxReceiveCount.
With SQS Standard’s at-least-once delivery, duplicates can occur. Idempotency ensures repeated processing of the same payment ID does not create duplicate side effects. A DLQ with redrive policy isolates poison messages: after a message is received and fails processing more than maxReceiveCount times, SQS moves it to the DLQ instead of cycling it back to the main queue indefinitely.
B
Distractor review
Rely only on increasing the SQS visibility timeout so duplicates rarely occur, without adding idempotency checks or a DLQ.
Increasing visibility timeout reduces how often duplicates happen, but it cannot guarantee elimination (timeouts, crashes, or long-tail processing delays can still cause re-delivery). It also does not handle poison messages that consistently fail.
C
Distractor review
Switch to a FIFO queue and delete messages immediately upon receipt to avoid duplicates.
Deleting immediately removes the ability to retry safely. If processing fails after deletion, the payment order may never be processed, causing lost or inconsistent outcomes.
D
Distractor review
Move the workload to SNS and use synchronous HTTP endpoints so the sender retries until the receiver confirms success.
SNS delivery is not a guaranteed exactly-once request/response mechanism. Even with retry behavior, duplicate deliveries and partial failures can still occur, and this approach does not directly provide the same DLQ + idempotency protections for at-least-once delivery semantics.