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.

• ✓

  Make the message handler idempotent.

  Why this is correct

  SQS provides at-least-once delivery, meaning the same message can be delivered to a consumer more than once, especially during network timeouts or consumer crashes. An idempotent handler design ensures that processing a duplicate message does not cause duplicate side effects, such as creating duplicate database records or processing the same payment twice. This is typically achieved by storing a unique message identifier or business key and checking for prior processing before executing the business logic. Idempotency is the fundamental corrective control for SQS's inherent lack of exactly-once semantics.

• ✓

  Set the SQS visibility timeout long enough for normal processing to complete.

  Why this is correct

  The SQS visibility timeout is the period during which a message is hidden from other consumers after it has been received. If the consumer does not delete the message before this timeout expires, the message becomes visible again and can be redelivered, even if the original processing was still in progress. Setting the visibility timeout to a duration that comfortably exceeds the normal maximum processing time prevents this type of unintended redelivery, giving the consumer enough time to complete processing and delete the message before the timeout expires. This reduces duplicate deliveries caused by timeouts, but it does not eliminate duplicates from other causes, such as network retries.

• ✗

  Switch from SQS to Amazon SNS for reliable buffering.

  Why it's wrong here

  Amazon SNS is a publish/subscribe notification service that immediately pushes messages to all active subscribers; it does not provide durable message buffering or queue semantics. SNS does not retain messages when there are no subscribers, does not allow consumers to poll for messages at their own pace, and lacks visibility timeouts or per-message lifecycle controls. Therefore, switching to SNS would remove the buffering capacity that SQS provides and would increase the chance of message loss, not prevent duplicate processing. SQS remains the appropriate service for reliable work queues where messages must persist until processed and deleted.

• ✗

  Shorten the queue retention period so messages expire quickly.

  Why it's wrong here

  The queue retention period defines how long a message remains in the queue if it is not deleted by a consumer, typically ranging from 1 minute to 14 days. Shortening this period does not affect the at-least-once delivery behavior of SQS; duplicates can still occur as long as a message exists. Worse, a shortened retention period increases the risk that valid messages expire before a consumer can process them, especially during a prolonged outage or a backlog. This approach not only fails to address duplicate deliveries but also makes the system less reliable, as it can lead to permanent message loss.

• ✗

  Disable retries in the consumer application.

  Why it's wrong here

  Disabling retries in the consumer application is a flawed response to duplicate messages because retries are essential for handling transient failures like temporary network blips, throttling limits, or brief downstream service outages. Without retries, a single temporary error causes the message to remain unprocessed and eventually be redelivered by SQS, so the underlying problem is not solved; instead, the message may ultimately be lost if the consumer gives up permanently. SQS itself relies on consumers to retry and delete messages after successful processing, and disabling application-level retries makes the workload more brittle, not less. The correct strategy is to keep retries for transient failures and use idempotent processing to safely handle any duplicates that result from those retries.

Go deeper

Related to this question