After maximum receives, unprocessable code-violation payloads must not block the main SQS backlog forever. What should the team configure?
Select an answer to reveal the explanation.
Short Explanation
Poison letters belong in a side bin, not forever at the front of the citizen complaint line. A dead-letter queue peels off messages that hit max receives so the main backlog keeps moving. Infinite retries, deleting before validation, or hoping FIFO dedupe alone won't quarantine bad payloads.
Full Explanation
After maximum receives, unprocessable code-violation payloads must not block the main SQS backlog forever—configure a dead-letter queue so poison messages move aside for separate inspection. The main queue keeps draining valid violations for field crews while bad payloads wait in the DLQ for schema fixes and controlled replay. Without a DLQ, poison messages recycle repeatedly, inflating ApproximateReceiveCount and delaying legitimate work that shares the consumer fleet.
An infinite retry loop on the main queue with no maximum receive count guarantees ongoing disruption from a single bad message. Calling DeleteMessage on every receive before validation hides failures and drops work that citizens still expect to appear as cases. Relying on a single shared FIFO queue with content-based deduplication as the only safeguard addresses duplicates, not quarantine of persistently failing payloads.
Exam caveat: set maxReceiveCount thoughtfully—too low sends transient blips to the DLQ; too high delays detection. DLQ retention must preserve enough payload for diagnosis. Redrive only after fixing the root cause, and keep DLQ processing IAM and alarms separate from the main pipeline.
Operational check: attach a DLQ with a modest maxReceiveCount; alarm on DLQ depth and age; capture correlation IDs in the message body; practice redrive in non-prod with intentional bad messages; and assign an owner for poison-message triage during code-enforcement peaks.