DOP-C02 Resilient Cloud Solutions Practice Question
A company uses AWS Lambda functions to process events from an Amazon SQS queue. The Lambda function occasionally fails due to a transient downstream service error. The DevOps team wants to ensure that failed messages are not lost and can be retried later. The team also wants to reduce the number of invocations on the downstream service. Which configuration should the team use?
⚠ Common exam trap
A common mix-up: candidates confuse a Lambda function's DLQ (which captures invocation records) with an SQS queue's DLQ (which captures the original messages), and they overlook that reserved concurrency is a direct way to throttle invocation rate, not just a capacity planning tool.
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) on the SQS queue and set the Lambda function's reserved concurrency to 1.
Configuring a dead-letter queue (DLQ) on the SQS queue ensures that messages that exhaust their retries (due to Lambda failures) are preserved for later reprocessing, preventing data loss. Setting the Lambda function's reserved concurrency to 1 throttles the function to a single concurrent invocation, which naturally reduces the rate of downstream service calls and allows the SQS queue's visibility timeout and redrive policy to manage retry timing, thereby reducing pressure on the downstream service.
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) on the SQS queue and set the Lambda function's reserved concurrency to 1.
Why this is correct
Setting a dead-letter queue (DLQ) on the SQS queue ensures that messages which exhaust their retry attempts are preserved for later inspection, while assigning reserved concurrency of 1 to the Lambda function caps the maximum number of concurrent invocations to exactly one. This hard limit prevents Lambda from scaling out to hundreds of executions when the downstream service is slow or failing, because the SQS event source mapping can only invoke one function at a time, thereby throttling the rate of calls to the downstream service. As a result, the downstream service receives at most one in‑flight request, avoiding overload and allowing it to recover gracefully. The queue‑level DLQ captures messages that ultimately fail after all retries, so no data is lost while the concurrency limit protects the bottleneck.
- ✗
Configure an Amazon SNS topic as a Lambda destination for failure events and subscribe the SQS queue to it.
Why it's wrong here
Amazon Lambda destinations—including SNS topics—are supported only for asynchronous invocations, whereas SQS event source mappings invoke Lambda synchronously, so this configuration is not applicable to the scenario. Even if a failure event were routed to an SNS topic that subscribes the same SQS queue, it would not reduce the invocation rate; instead, it would simply re‑inject those failed messages back into the queue, potentially creating an endless loop of reprocessing. This approach neither caps concurrency nor shields the downstream service from a burst of invocations; it merely adds architectural complexity and a real risk of duplicate or infinite processing. Lambda destinations are for notification and rerouting on asynchronous invocations—they do not provide throttling or backpressure for SQS‑triggered functions.
- ✗
Configure a dead-letter queue (DLQ) on the Lambda function and set the function's maximum retry attempts to 2.
Why it's wrong here
A Lambda function's DLQ configuration is only honored for asynchronous invocations; when the function is triggered by an SQS queue, the event source mapping issues synchronous invocations, so the function‑level DLQ is never used. The SQS‑based retry behavior is governed by the source queue's redrive policy, which determines when messages are moved to the queue‑level DLQ; without such a policy, setting retry attempts on the function has no effect on message durability. Moreover, tweaking maximum retry attempts to 2 only changes how many times the event source mapping attempts to deliver a batch before discarding it—but without a queue‑level DLQ those messages are permanently lost. This option also fails to introduce any concurrency constraint, so it does nothing to prevent the downstream service from being overwhelmed by parallel invocations.
- ✗
Configure the Lambda function to write failed messages to an Amazon DynamoDB table and set up a scheduled Lambda to retry.
Why it's wrong here
Writing failed messages to DynamoDB and scheduling a separate Lambda to retry them introduces additional latency and operational complexity, but more critically it does not natively reduce downstream invocations—the scheduled retry Lambda would still call the downstream service on every poll cycle regardless of whether the service has recovered. This approach is tempting because DynamoDB provides durable storage for failed records, and scheduled retries are a common pattern for decoupling retry logic from the primary processing path, which would be correct if the goal were simply to preserve messages for manual or time-delayed reprocessing without needing to throttle invocation frequency.
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 — 251 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 →
Same concept, more angles
2 more ways this is tested on DOP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company uses AWS Lambda functions to process events from Amazon SQS. The Lambda function sometimes fails due to timeouts. The team wants to preserve the event for reprocessing. How should they configure the integration?
hard- ✓ A.Set up a DLQ on the SQS queue that receives the events
- B.Use Lambda reserved concurrency
- C.Enable Lambda function DLQ with SNS topic
- D.Increase Lambda timeout to maximum
Why A: By configuring a dead-letter queue (DLQ) on the SQS queue, failed messages are preserved for later reprocessing.
Variation 2. A company uses AWS Lambda to process messages from an Amazon SQS queue. The Lambda function occasionally times out after 15 seconds. To improve resilience, the team wants to ensure messages are not lost and are retried. Which configuration is MOST appropriate?
medium- A.Reduce the Lambda timeout to 5 seconds to fail fast and retry quickly.
- B.Set the SQS queue visibility timeout to less than the Lambda timeout.
- C.Increase the batch size and remove the DLQ to speed up processing.
- ✓ D.Increase the Lambda timeout to 30 seconds and configure a dead-letter queue (DLQ) for the SQS queue.
Why D: Increasing the Lambda timeout to 30 seconds accommodates the occasional processing delays that cause the current 15-second timeout, preventing premature failures. Configuring a dead-letter queue (DLQ) for the SQS queue ensures that messages that repeatedly fail after all retries are exhausted are preserved for analysis and manual reprocessing, rather than being lost. This combination directly addresses the requirement to not lose messages and to allow retries, as Lambda will automatically retry failed invocations up to the function's configured retry count (default 2) before sending the message to the DLQ.
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.