DOP-C02 Resilient Cloud Solutions Practice Question
A company uses AWS Lambda to process messages from an SQS queue. They need to ensure that if the Lambda function fails, the message is not lost and can be processed again. Which configuration is required?
⚠ Common exam trap
Many exam-takers confuse the dead-letter queue (DLQ) as the mechanism for retrying messages, when in fact it only stores messages after all retry attempts are exhausted, and the key to ensuring retries on failure is the event source mapping's delete behavior.
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
✓
Set the Lambda event source mapping to not delete messages from the queue on failure.
The Lambda event source mapping for SQS can be configured to not delete messages from the queue if the function fails. This ensures that the message remains in the queue and becomes visible again after the visibility timeout expires, allowing it to be retried. Without this setting, Lambda automatically deletes messages upon successful processing, but on failure, the default behavior is to delete them as well, which would cause message loss.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set the visibility timeout to less than the Lambda function timeout.
Why it's wrong here
If the visibility timeout is configured shorter than the Lambda function timeout, a message can become visible to other consumers or a subsequent poll while the original invocation is still executing. This produces duplicate processing because the same message may be delivered and processed concurrently before the first attempt completes. SQS visibility should be at least the function timeout plus a margin to guarantee the message stays hidden until the function finishes.
- ✗
Enable SQS redrive policy to retry messages.
Why it's wrong here
An SQS redrive policy specifies the condition for moving a message to a dead-letter queue, such as after maxReceiveCount attempts, and does not itself initiate any retry. It is purely a routing configuration that removes the message from the active queue once the retry budget is exhausted. The event source mapping already retries by polling the queue again; the redrive policy only takes effect after those retries fail.
- ✗
Configure a dead-letter queue (DLQ) on the SQS queue.
Why it's wrong here
Configuring a DLQ on the SQS queue provides a destination for messages that have repeatedly failed after the maximum receive count is reached. Once a message is moved to the DLQ, it is no longer visible to the Lambda trigger, so retries cease, not continue. A DLQ is thus a failure-containment mechanism, not a retry strategy; enabling it would not help ensure that messages are retried on failure.
- ✓
Set the Lambda event source mapping to not delete messages from the queue on failure.
Why this is correct
The Lambda event source mapping for an SQS queue governs message deletion: it only deletes a message after the function returns a success response. By ensuring the mapping does not delete messages on failure (which is the standard behavior unless the function reports success), the failed message remains in the source queue. On subsequent polls, the event source mapping receives it again and invokes the function, giving the desired retry behavior. This is the correct way to let Lambda retry processing of a failed message.
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
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-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 DOP-C02 exam.