Learn the vocabulary of isolating a persistently failing message instead of retrying it forever.
0 / 5 completed
1 / 5
At standup, a dev mentions a separate queue where a message that repeatedly fails processing gets routed after exceeding a retry limit, instead of being retried forever or silently dropped. What is this separate queue called?
A dead-letter queue, or DLQ, is a separate queue where a message that repeatedly fails processing gets routed after exceeding a retry limit, rather than being retried forever or silently dropped and lost. Retrying a failing message indefinitely risks it blocking the processing of every other message queued behind it. This separate queue is what isolates a persistently failing message while still preserving it for later inspection.
2 / 5
During a design review, the team wants to configure exactly how many times a message can fail before it's automatically moved to the dead-letter queue. Which capability supports this?
A max-retry count, or redrive policy, configures exactly how many times a message can fail before it's automatically moved to the dead-letter queue, rather than being retried an arbitrary or unlimited number of times. Moving every message to the DLQ on its very first attempt would treat a normal, transient failure the same as a genuinely broken, unprocessable message. This configurable retry count is what lets a system distinguish a message worth retrying from one that's truly stuck.
3 / 5
In a code review, a dev notices the team monitors and alerts on the dead-letter queue's depth, so a systemic processing failure affecting many messages is noticed quickly rather than discovered much later. What does this represent?
Monitoring dead-letter queue depth catches a systemic processing failure affecting many messages quickly, since a sudden spike in DLQ depth signals something has gone broadly wrong rather than a single, isolated failure. Letting the queue accumulate with no monitoring risks a widespread failure going unnoticed for a long time. This monitoring turns a dead-letter queue from a passive holding area into an active early-warning signal for the team.
4 / 5
An incident report shows a single poison-pill message was retried indefinitely, blocking the processing of every other message queued behind it, because no dead-letter queue or max-retry policy had been configured. What practice would prevent this?
Configuring a max-retry policy that routes a persistently failing message to a dead-letter queue isolates that poison-pill message so it stops blocking every other message behind it. Retrying it indefinitely with no such policy is exactly what causes the queue-wide blockage this incident describes. This configuration is a baseline safeguard for any message-processing system where a single bad message shouldn't be able to stall the entire queue.
5 / 5
During a PR review, a teammate asks why the team routes a persistently failing message to a dead-letter queue instead of either retrying it forever or dropping it silently. What is the reasoning?
A dead-letter queue isolates a poison message so it doesn't block the rest of the queue's processing, while still preserving that message for later inspection rather than losing it outright, unlike simply dropping it silently. Retrying it forever instead risks it stalling every other message queued behind it. The tradeoff is the ongoing operational responsibility of monitoring and eventually addressing whatever ends up accumulating in the dead-letter queue.
What does the "Dead-Letter Queues Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to dead-letter queues vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 17 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.