DVA-C02 Development with AWS Services Practice Question
A developer is designing a messaging system where orders are placed into an SQS queue and processed by a Lambda function. The developer wants to ensure that failed messages are not lost and can be analyzed later. Which TWO steps should the developer take? (Choose 2.)
⚠ Common exam trap
Test-takers frequently confuse Lambda retries (which only re-invoke the function) with the SQS DLQ mechanism, failing to realize that without a DLQ, messages that exhaust all retries are silently deleted from the queue and permanently lost.
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 a dead-letter queue (DLQ) for the SQS queue.
Configuring a dead-letter queue (DLQ) for the SQS queue ensures that messages that cannot be processed successfully after a specified number of attempts are moved to a separate queue. This prevents message loss and allows the developer to analyze the failed messages later, fulfilling the requirement to not lose failed messages and to enable analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure a dead-letter queue (DLQ) for the SQS queue.
Why this is correct
A dead-letter queue (DLQ) is a standard SQS queue that receives messages from a source queue after they have failed to be processed successfully a specified number of times. Configuring a DLQ prevents messages from being lost due to repeated processing failures, allowing for later inspection, debugging, or manual reprocessing. This mechanism is crucial for ensuring message durability and reliability in a distributed messaging system, isolating problematic messages.
- ✗
Enable Lambda function retries on failure.
Why it's wrong here
While enabling retries for a Lambda function invoked by SQS can help overcome transient processing issues, it only dictates how many times Lambda attempts to process a message before giving up. If all retries fail, the message is returned to the SQS queue, potentially leading to an infinite loop or eventual message loss if not handled by a DLQ on the SQS side. Lambda retries themselves do not preserve messages that ultimately fail SQS processing.
- ✓
Set the redrive policy to move messages to the DLQ after a specified number of receive attempts.
Why this is correct
The redrive policy is configured directly on the source SQS queue and specifies the dead-letter queue (DLQ) to which messages should be sent. Crucially, it defines the `maxReceiveCount`, which is the maximum number of times a message can be received from the source queue by consumers before SQS automatically moves it to the associated DLQ. This automated mechanism ensures that persistently problematic messages are isolated without manual intervention, preventing them from blocking the main queue.
- ✗
Increase the visibility timeout of the SQS queue.
Why it's wrong here
The visibility timeout temporarily hides a message from other consumers after it has been received by one, giving that consumer time to process and delete it. Increasing this timeout might prevent duplicate processing attempts if the consumer needs more time, but it does not address the scenario where a message *fails* processing entirely. If the consumer fails to delete the message within the extended timeout, it becomes visible again, potentially leading to repeated failures without preserving the message.
- ✗
Set up a CloudWatch alarm to monitor the queue depth.
Why it's wrong here
A CloudWatch alarm monitoring SQS queue depth can notify operators when the number of messages in the queue exceeds a certain threshold, indicating a potential backlog or processing issue. While useful for operational awareness and triggering scaling actions, an alarm merely provides a notification. It does not actively preserve or redirect messages that are failing to be processed, nor does it prevent message loss from the queue itself.
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 1,135 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.