DVA-C02 SQS Redrive Policy Practice Question
A developer is troubleshooting an AWS Lambda function that is triggered by an Amazon SQS queue. The function processes messages but occasionally fails. The failed messages are not being sent to the dead-letter queue (DLQ). What is the most likely reason?
⚠ Common exam trap
Candidates often confuse the two types of DLQs: Lambda function DLQ (for asynchronous invocations) and SQS queue DLQ (redrive policy). For SQS-triggered Lambda, the correct DLQ is on the SQS queue, not on the Lambda function.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The SQS queue's redrive policy is not configured.
When Lambda is triggered by SQS, the recommended approach is to configure a dead-letter queue (DLQ) on the SQS queue itself using a redrive policy. This ensures that messages that fail processing after reaching the maximum receive count are automatically moved to the DLQ. Option B is correct because the absence of a redrive policy means failed messages remain in the main queue or are discarded, not sent to a DLQ. Option D is incorrect; configuring a DLQ on the Lambda function is intended for asynchronous invocations, not SQS-triggered Lambda. Option A is incorrect because the redrive policy does not rely on Lambda's IAM role; it is a configuration on the SQS queue. Option C is incorrect because reserved concurrency set to 0 would prevent all invocations, but the issue described is about occasional failures, not complete lack of invocation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Lambda function's execution role does not have permission to send messages to the DLQ.
Why it's wrong here
When an SQS queue's redrive policy is configured to send failed messages to a Dead-Letter Queue (DLQ), it is the SQS service itself that performs the action of moving the message. The Lambda function's execution role is only responsible for permissions related to its own operations, such as reading from the source SQS queue or writing to other AWS services. Therefore, the Lambda function's execution role does not require permissions to send messages to the DLQ; the SQS service handles this internally based on its own permissions and configuration.
- ✓
The SQS queue's redrive policy is not configured.
Why this is correct
When an AWS Lambda function processes messages from an SQS queue, and an invocation fails (e.g., due to an error in the function code or a timeout), SQS will return the message to the queue after its visibility timeout expires. If the message processing continues to fail and the SQS queue does not have a redrive policy configured, the message will eventually be discarded by SQS after its maximum receive count is exceeded, rather than being moved to a Dead-Letter Queue (DLQ). Therefore, a missing redrive policy directly prevents failed messages from being captured in a DLQ associated with the source queue.
- ✗
The Lambda function's reserved concurrency is set to 0.
Why it's wrong here
Setting a Lambda function's reserved concurrency to 0 effectively throttles all invocations, preventing the function from running at all. If this were the case, the function would not be processing any messages from SQS, and thus no messages would be failing or needing to be sent to a DLQ. The problem statement implies the function is running and experiencing occasional failures, making a reserved concurrency of 0 an inconsistent explanation for messages not appearing in a DLQ.
- ✗
The Lambda function does not have a dead-letter queue configured.
Why it's wrong here
For SQS-triggered Lambda functions, the SQS queue itself is responsible for handling failed messages by moving them to a Dead-Letter Queue (DLQ) via its redrive policy. A DLQ configured directly on the Lambda function applies only to asynchronous invocation patterns (e.g., API Gateway, S3 event notifications) where Lambda attempts retries and then sends the failed event to its configured DLQ. Since SQS manages the retry and DLQ logic for its own messages, a Lambda function's internal DLQ configuration is irrelevant in this scenario.
Visual reference
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 724 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DVA-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DVA-C02 exam.