DVA-C02 Development with AWS Services Practice Question
A company has an AWS Lambda function that processes messages from an Amazon SQS queue. The function sometimes fails due to transient errors. The developer wants to ensure that failed messages are retried automatically and then sent to a dead-letter queue after three failed attempts. How should the developer configure this?
⚠ Common exam trap
Many candidates confuse Lambda's asynchronous invocation DLQ (for events like S3 or SNS) with the SQS redrive policy, mistakenly thinking they can configure retries and DLQ on the Lambda function itself rather than on the SQS queue.
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
✓
Configure the SQS queue with a redrive policy and a dead-letter queue. Set the maxReceiveCount to 3.
Amazon SQS supports a redrive policy that automatically moves messages to a dead-letter queue (DLQ) after a specified number of receive attempts. By setting maxReceiveCount to 3, the SQS queue will retry delivering the message to the Lambda function up to three times (including the initial attempt). After three failed processing attempts, the message is automatically sent to the configured DLQ. This approach decouples retry logic from the Lambda function itself and leverages SQS's built-in reliability features.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable Lambda function's DLQ and set the retry attempts to 3.
Why it's wrong here
Enabling a Lambda function's built-in Dead-Letter Queue (DLQ) and retry attempts only applies to asynchronous invocation sources, such as SNS, S3, or direct API calls. When an SQS queue triggers a Lambda function, SQS itself manages the message lifecycle, including retries and dead-lettering. Therefore, configuring the Lambda function's own DLQ will not capture messages that fail processing when originating from SQS.
- ✗
Configure the Lambda function's reserved concurrency to 0 and set the DLQ on the function.
Why it's wrong here
Configuring a Lambda function's reserved concurrency to 0 will immediately throttle all invocations, effectively preventing the function from processing any messages from the SQS queue. While a DLQ might be configured on the function, no messages would ever reach the function for processing, let alone fail and be sent to that DLQ. This action completely halts message processing, which is not the intended solution for handling message failures.
- ✓
Configure the SQS queue with a redrive policy and a dead-letter queue. Set the maxReceiveCount to 3.
Why this is correct
This is the correct approach for handling message failures when an SQS queue triggers a Lambda function. By configuring a redrive policy on the SQS queue itself, along with a dead-letter queue and a `maxReceiveCount` of 3, SQS will automatically manage message retries. If the Lambda function fails to process a message three times, SQS will move that message to the specified dead-letter queue for later inspection and reprocessing, ensuring no messages are lost indefinitely.
- ✗
Use an Amazon SNS topic to send failed messages to a DLQ after three Lambda invocations.
Why it's wrong here
Using an Amazon SNS topic to send failed messages to a DLQ is not the appropriate solution for managing retries of SQS-triggered Lambda invocations. SNS is a publish/subscribe service and does not inherently provide the retry logic or `maxReceiveCount` functionality needed for SQS messages. The SQS queue itself is responsible for managing its message lifecycle, including retries and dead-lettering, making SNS an unnecessary and ineffective intermediary for this specific problem.
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.