Worker failures occasionally poison SQS messages — after 3 receives they should move aside for inspection, then return to the queue once fixed. Which configuration does this?
A.Increase visibility timeout so retries take longer
Visibility timeout delays retries but never removes the poison message.
B.Attach a dead-letter queue with maxReceiveCount=3, then use DLQ redrive
Correct. DLQ + redrive = capture, inspect, replay.
C.Delete the messages manually
Manual deletion loses messages — redrive preserves them.
D.Switch to SNS for at-least-once delivery
SNS fans out notifications; it has no per-message DLQ retry semantics for a consumer queue.
Why this answer
A DLQ with maxReceiveCount moves repeatedly-failed messages aside automatically; the console's DLQ redrive pushes them back to the source queue after you fix the consumer — the standard poison-message workflow.
Correct answer: B · Last reviewed 2026-11-01
Official AWS references
Practice this interactively
Answer without seeing the solution first in the Decoupling & Messaging practice session.
Practice Decoupling & Messaging