DOP-C02 Resilient Cloud Solutions Practice Question
A company has a serverless application using AWS Lambda functions that process messages from an Amazon SQS queue. The Lambda function sometimes fails due to transient errors. The company wants to ensure that failed messages are retried and eventually processed or sent to a dead-letter queue after 3 retries. What is the correct configuration?
⚠ Common exam trap
The trap is assuming Lambda's retry settings apply to SQS-triggered invocations; candidates often confuse asynchronous invocation retries with poll-based event source mapping retries, leading them to pick Lambda DLQ options instead of SQS redrive policy.
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's redrive policy with maxReceiveCount: 3 and a dead-letter queue.
For Lambda functions that poll an SQS queue, the retry behavior and dead-letter queue are configured on the SQS queue itself using a redrive policy. The redrive policy specifies the maxReceiveCount (e.g., 3) and the ARN of the dead-letter queue. After a message is received the specified number of times without being deleted, SQS moves it to the DLQ. This is the correct way to handle retries and DLQ for SQS-triggered Lambda.
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 Lambda function's retry policy to Maximum retries: 3 and configure a DLQ on the Lambda function.
Why it's wrong here
The Lambda function's retry policy and DLQ configuration apply only to asynchronous invocations, not to events sourced from SQS. When an SQS queue triggers Lambda via an event source mapping, the Lambda service polls the queue and invokes the function synchronously, so the function-level Maximum retries and DLQ settings are never engaged. Message redelivery and dead-lettering are governed instead by the SQS queue's own redrive policy, making this option ineffective.
- ✗
Set the Lambda function's DLQ to an SQS queue and configure the event source mapping to use that DLQ after 3 retries.
Why it's wrong here
Lambda's DLQ configuration is strictly tied to asynchronous invocation failures, and the event source mapping for SQS does not support directing failed messages to a function-level DLQ. Even if you attached an SQS DLQ to the Lambda function, the invocation from the SQS event source mapping would not use it because that mapping invokes the function synchronously. The correct mechanism is an SQS dead-letter queue specified within the source queue's redrive policy, where the maxReceiveCount controls how many delivery attempts occur before the message is diverted.
- ✓
Configure the SQS queue's redrive policy with maxReceiveCount: 3 and a dead-letter queue.
Why this is correct
This is the correct pattern because SQS itself owns the retry and dead-letter behavior when Lambda consumes from a queue. A redrive policy with maxReceiveCount: 3 instructs SQS to allow a message to be received up to three times; if the Lambda function fails to process it each time, SQS automatically moves the message to the configured dead-letter queue. This is a native, serverless-friendly mechanism that avoids unnecessary compute and precisely matches the requirement for '3 retries before a DLQ'.
- ✗
Create an AWS Step Functions workflow that polls the SQS queue, processes messages, and retries failures up to 3 times before moving to a DLQ.
Why it's wrong here
While a Step Functions workflow could technically mimic retries and DLQ routing, it is far too complex for this simple messaging scenario. To make Step Functions poll an SQS queue, you would have to build a custom polling loop (e.g., with a Lambda function or a state machine), adding latency, cost, and operational overhead that the native SQS redrive policy eliminates. The recommended architecture uses SQS's built-in dead-letter queue capabilities, leaving Step Functions for orchestrating more complex, multi-step business processes.
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
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.