SAA-C03 Practice Question 34: SQS Dead Letter Queue
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 4 · question 4 of 10
Worker EC2 instances poll an SQS queue and process order messages. A small number of malformed messages cause the worker to throw an exception before deleting the message. Each one becomes visible again after the visibility timeout and is picked up forever, consuming worker capacity and delaying valid orders. The team wants the bad messages set aside for later inspection without losing them and without stopping the workers.
What should the solutions architect configure?
Show answer and explanation
Answer:
A redrive policy names a dead-letter queue and a maxReceiveCount. Once a message has been received that many times without being deleted, SQS moves it to the dead-letter queue, where it is retained for inspection and can be redriven back to the source queue after a fix. That isolates the poison messages from the workers exactly as required, and valid orders stop queueing behind them.
Option A makes the symptom less frequent and lasts longer per attempt, but the message still returns indefinitely and still consumes a worker each time. It also delays genuine retries of transient failures.
Option C does eventually remove the messages, by deleting them; the requirement is that they be preserved for inspection. A shorter retention period also risks discarding valid messages during a processing backlog.
Option D changes ordering semantics without addressing the failure. In a FIFO queue a poison message blocks its entire message group from progressing, which makes the delay worse rather than better.
Reference: Amazon SQS dead-letter queues