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.

• ✗

  Set the SQS queue’s retention period to 10 years and rely on application retries to eventually succeed.

  Why it's wrong here

  SQS retention period defines the maximum length of time a message can remain in the queue, from 1 minute to 14 days; a value of 10 years becomes invalid as SQS will reject it, and even the maximum 14 days merely keeps messages available rather than protecting the workflow from repeat failures. Relying on application retries alone means the same poison message will be attempted again and again, wasting compute and potentially growing fetch/processing costs without advancing past the fault. Retention controls storage duration, not redrive behavior, so it does not provide any threshold-based mechanism to move a repeatedly failing message to a quarantine location for diagnosis.

  When this WOULD be correct

  If the question asked for ensuring message durability for long-term processing where failures are transient and no poison messages exist, setting a long retention period would be correct.

• ✗

  Increase visibility timeout to a very large value and avoid dead-letter queues to keep ordering stable.

  Why it's wrong here

  Overly long visibility timeouts delay redelivery of any message, including those that experience short transient errors, because the message stays hidden until the timeout expires even though the consumer may have already failed. More importantly, without a dead-letter queue, a poison message that always fails is returned to the queue every time the timeout elapses, so it keeps being retried indefinitely and can still block subsequent messages in a FIFO case. Visibility timeout influences when retries happen, but it provides no threshold-based quarantine mechanism, which is the only way to stop processing a permanently bad record.

  When this WOULD be correct

  In a scenario where message ordering is critical and you cannot tolerate any message loss or reordering, and you have a mechanism to ensure all messages eventually succeed (e.g., idempotent processing with exponential backoff), you might avoid DLQs and use a very large visibility timeout to prevent premature retries.

• ✓

  Configure a redrive policy with a dead-letter queue (DLQ) and set an appropriate visibility timeout greater than the maximum processing time.

  Why this is correct

  A redrive policy defines a dead-letter queue (DLQ) and a maxReceiveCount; once a message is received that many times without being deleted, SQS moves it to the DLQ, quarantining poison messages for inspection or manual redrive. Setting the visibility timeout longer than the worst-case processing time prevents the message from becoming visible again while a consumer is still working, which would otherwise cause duplicate deliveries. Together, these settings bound both the retry window and the queue depth, allowing transient failures to retry while isolating permanent failures without losing data.

• ✗

  Switch the queue to FIFO and remove retries in the Lambda event source mapping entirely.

  Why it's wrong here

  Switching to FIFO guarantees strict ordering, but ordering and poison-message isolation are unrelated; a failing front message can still block the group, and FIFO leaves no choice but to either retry or discard. Removing all retries from the Lambda event source mapping means a message that fails even once is immediately given up on, leading to data loss unless a separate failure destination is configured. Disabling retries entirely also eliminates the opportunity to recover from temporary backend hiccups, and without a DLQ redrive policy there is no buffer where the failed message can be quarantined for later analysis or replay.

  When this WOULD be correct

  This option would be correct in a scenario where the requirement is to process messages in strict order and any failed message must be discarded immediately to avoid blocking subsequent messages, with no tolerance for retries or reordering.

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.

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