An orders service publishes payment instructions to an Amazon SQS Standard queue. A downstream consumer sometimes times out and retries the work, causing the consumer to process the same instruction more than once. Operationally, the team must ensure that duplicate processing does not create duplicate charges. The queue type cannot be changed. What is the most resilient application-side approach?

Rely on SQS Standard to provide exactly-once delivery for each message, since the consumer uses retries.

Amazon SQS Standard provides at-least-once delivery. Even with retries, duplicates can still occur, so exactly-once behavior is not guaranteed by SQS.

Increase the queue’s visibility timeout to 24 hours so messages never reappear even if the consumer times out.

A long visibility timeout only reduces how soon duplicates might be re-delivered; it does not eliminate duplicate processing. It can also increase the duration of stuck failures and does not guarantee correctness.

Delete and recreate the queue with a different name whenever duplicates are detected in production.

Recreating queues is disruptive, does not address the underlying at-least-once + retry behavior, and does not provide a reliable correctness mechanism for preventing duplicate charges.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Implement idempotent processing using a persistent deduplication key (for example, paymentInstructionId) so repeated messages are ignored or safely merged. — With an SQS Standard queue, duplicates can occur due to at-least-once delivery and timeout/retry patterns in consumers. Since the queue type cannot change, the most resilient solution is to make the consumer idempotent. Use a stable key such as paymentInstructionId and persist processing state (for example, in a database) so that if the same instruction is received again, the consumer can safely return without charging a second time (or deterministically merge outcomes). This protects correctness regardless of delivery and retry behavior. Option A is incorrect because SQS Standard does not guarantee exactly-once delivery. Option C changes timing but cannot ensure correctness and can worsen operational risk by hiding failures for too long. Option D is an operational workaround that does not prevent future duplicates from being processed incorrectly.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.