SAA-C03 Design Resilient Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

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

  Why it's wrong here

  Amazon SQS Standard queues provide at-least-once delivery, meaning a message can be delivered more than once under normal operation. Consumer retries do not change the queue's delivery contract: a retry after a timeout or a visibility timeout expiry can result in the same message being processed a second time. Relying on SQS Standard for exactly-once semantics is therefore fundamentally incorrect and will permit duplicate charges.

• ✓

  Implement idempotent processing using a persistent deduplication key (for example, paymentInstructionId) so repeated messages are ignored or safely merged.

  Why this is correct

  Because SQS Standard is at-least-once, the consumer must assume duplicates are possible. Persisting a record keyed by paymentInstructionId (or using a database unique constraint) lets the consumer detect that a given instruction was already processed successfully and safely skip the charge or merge results deterministically.

• ✗

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

  Why it's wrong here

  Setting the visibility timeout to 24 hours merely prevents a message from becoming visible again during the timeout period; it does not stop duplicates from a consumer that crashes before deleting the message, nor does it protect against a second consumer poll that reads the message before the first one completes. A long visibility timeout can actually mask application failures for an entire day and delay processing of other messages in the same queue, while duplicate delivery can still occur after the timeout expires.

• ✗

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

  Why it's wrong here

  Deleting and recreating the queue with a different name is an operational workaround that does not resolve duplicate processing caused by the at-least-once delivery model. Any messages already in flight or already processed would be lost, and a new queue would not retroactively deduplicate charges already applied. This approach introduces downtime and does not provide a deterministic way to prevent the same payment instruction from being executed more than once, so it fails to address the root cause.

Go deeper

Related to this question