Courseiva

SOA-C02 Reliability and Business Continuity Practice Question

A company processes orders using an Amazon SQS standard queue. The order processing application occasionally fails to process a message. The SysOps administrator wants to ensure that any message that fails to be successfully processed after three attempts is automatically moved to a separate queue for manual review. Which SQS feature should be configured?

⚠ Common exam trap

Watch out — candidates often confuse increasing the visibility timeout (which only delays reprocessing) with the automatic isolation provided by a Dead Letter Queue, or think that converting to FIFO or enabling a redrive allow policy alone solves the problem, when the core requirement is a DLQ with a configured redrive policy that specifies the maxReceiveCount.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Configure a Dead Letter Queue (DLQ) with a redrive policy

A Dead Letter Queue (DLQ) with a configured redrive policy is the correct SQS feature to automatically move messages that have failed processing after a specified number of attempts (in this case, three) to a separate queue for manual review. The redrive policy defines the source queue, the DLQ, and the maximum receive count (maxReceiveCount) threshold. When a message is received from the source queue more times than the maxReceiveCount, SQS automatically redirects it to the DLQ, isolating problematic messages without manual intervention.

Answer analysis

Option-by-option breakdown

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

  • ✓

    Configure a Dead Letter Queue (DLQ) with a redrive policy

    Why this is correct

    A Dead Letter Queue (DLQ) with a redrive policy is the correct mechanism for handling messages that repeatedly fail to process successfully. When you set a redrive policy with a maximum receive count, SQS automatically moves a message to the configured DLQ after that many attempted receives (e.g., after the consumer has received it but failed to delete it). This isolates poison-pill messages from the main queue, allowing the main queue to continue processing healthy messages without retrying broken ones indefinitely, and enables later analysis or manual correction in the DLQ.

  • ✗

    Increase the visibility timeout of the queue

    Why it's wrong here

    Increasing the visibility timeout only extends the period during which a message is hidden from other consumers after a receive call. It does not track how many times a message has been received, nor does it move the message to another queue. While a longer visibility timeout might give a slow consumer more time to finish before the message becomes visible again, it does not address the underlying problem of a message that continually causes processing failure — the message will simply reappear and be retried forever until the visibility timeout is repeatedly extended.

  • ✗

    Convert the queue to a FIFO queue

    Why it's wrong here

    Converting the queue to a FIFO queue changes the semantics to strict ordering and exactly-once processing support, but it has no built-in handling for failed messages. FIFO queues require a message group ID, limit throughput, and do not automatically discard or redirect messages that fail to process. A poison-pill message in a FIFO queue can block all subsequent messages in its group, making the situation worse; you still need a DLQ with a redrive policy to rescue those failures.

  • ✗

    Enable redrive allow policy on the queue

    Why it's wrong here

    A redrive allow policy is a configuration on the DLQ that specifies which source queues are permitted to use that DLQ. It is a permission or scope control, not an action that moves messages. Without a corresponding redrive policy on the source queue that specifies the DLQ and max receive count, enabling the allow policy alone does nothing to send failing messages anywhere. So, while it may be a prerequisite or companion setting, it is not the mechanism that actually moves messages to the DLQ.

About these practice questions

One of 1,169 original SOA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SOA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SOA-C02 exam.