Give failed jobs a place to wait for help — SQS and Dead-letter queues

Your goal

Give a queue a dead-letter destination and set a receive limit.

Why this matters

Repeatedly troublesome messages need a separate place for investigation. You will configure a dead-letter destination and receive limit. The lab checks the policy without pretending a job has already failed.

Words you will use

A dead-letter queue holds messages that repeatedly fail processing. A redrive policy sets when they move there. Redrive also describes moving them back for another attempt.

How to proceed

Start a fresh emulator, read each numbered step, and enter the practice settings shown. Run the action, inspect its API receipt, then continue. Finish lab checks the emulator state again before saving your progress.

1. Create a work queue and a failure queue

Create two standard queues. The first holds ordinary work; the second will hold messages that exceed a receive limit. A dead-letter queue needs an investigation and replay process too.

2. Choose when work moves aside

Save a redrive policy naming the failure queue and your maximum receive count. A receive count is not the same as a known number of application failures.

Maximum receives: Choose 1–10 receives before a message becomes eligible for the dead-letter queue. Suggested practice value: 3.

3. Inspect the redrive policy

Read RedrivePolicy and compare its destination ARN and receive limit. This lab checks failure-handling configuration; it does not claim a message has already failed or moved.

Practice, then check your understanding

Perform the actions yourself and inspect the returned state. Errors keep your settings so you can retry. Starting another lab clears the previous live environment. Earned XP is kept, and signed-in achievements sync to your account. Replay does not award duplicate XP.

Read the official AWS documentation for service behavior and production details.