Dead Letter Queue

5 minutes 5 Questions

A Dead Letter Queue (DLQ) is a special queue that stores messages that could not be processed by the main queue after multiple delivery attempts. These messages might require manual review or could indicate a bug in the processing logic. DLQ provides a way to isolate and handle these messages separately from the main processing logic. You can set up a redrive policy for your main queue, specifying the conditions under which messages should be sent to the DLQ, such as the maximum number of receive attempts.

Guide on Dead Letter Queue for AWS Solution Architect Exam

What is Dead Letter Queue (DLQ)?
Dead Letter Queue (DLQ) is a queue that other (source) queues can target for messages that can't be processed successfully. DLQs are used to isolate these messages to determine why their processing doesn't succeed.

Why DLQ is Important?
DLQ is important as it helps to troubleshoot why messages can’t be processed without interrupting the normal functioning of your application. It can save messages that can't be processed for later analysis.

How DLQ Works?
When a message can't be processed, it can be moved automatically to a DLQ. You can set a limit for the number of times a message delivery can be attempted, and upon reaching this limit, the message will be automatically sent to DLQ.

Exam Tips: Answering Questions on Dead Letter Queue
1. Remember the purpose of DLQ; it’s used to isolate messages that can't be processed and it provides troubleshooting abilities.
2. Understand how DLQ works, i.e., after a certain number of unsuccessful attempts, the message is moved to DLQ automatically.
3. Know the significant role of DLQ in high availability and fault tolerance strategy of AWS.
4. In a scenario where messages are failing and the cause is unknown, the ideal solution typically involves a DLQ.
5. Be aware that not all services will use DLQs; for example, an SNS topic will not use a DLQ. Instead, it uses event delivery failure logging.

Test mode:

Exam (Timed)

Practice (With explanations)

Start practice test

Question 1

You have an Amazon Lambda function processing messages from an SQS queue, and you want to implement a mechanism to handle messages that cannot be processed. What should you do?

Save failed messages to an Amazon RDS instance. Use an SQS Dead Letter Queue as the Lambda on-failure event destination. Use AWS X-Ray and AWS Step Functions to handle failed messages. Reconfigure the Lambda function timeout settings.

Correct Answer: Use an SQS Dead Letter Queue as the Lambda on-failure event destination.

A Dead Letter Queue (DLQ) can be specified as the on-failure event destination for messages that cannot be processed by the Lambda function. This allows for storage and analysis of unprocessed messages.

Question 2

An application is consuming messages from Amazon SQS, occasionally some messages fail to process due to an application bug. Which SQS feature can help diagnose and fix the problem?

Dead Letter Queue Long Polling FIFO queues Visibility Timeout

Correct Answer: Dead Letter Queue

Dead Letter Queue can help diagnose and fix the problem by storing failed messages for further analysis, while other options such as Visibility Timeout, Long Polling, FIFO Queues, and Message Retention Period, do not provide solutions to handle failed messages.

Question 3

A developer is working on a serverless application that makes use of AWS Lambda and Amazon SQS. The Lambda function processes SQS messages, but some messages are not being processed. How can unprocessed messages be stored and later analyzed?

Enable Amazon CloudWatch Monitoring on Lambda function. Implement an Amazon SNS topic for unprocessed messages. Configure the Lambda function's event source with a Dead Letter Queue. Enable AWS X-Ray to trace unprocessed messages.

Correct Answer: Configure the Lambda function's event source with a Dead Letter Queue.

Configuring the Lambda function's event source with a Dead Letter Queue ensures that unprocessed messages are stored and can be later analyzed. This is the most efficient way to handle unprocessed messages in a serverless application.

Go Premium