DOP-C02 Resilient Cloud Solutions Practice Question
A company runs a serverless application using AWS Lambda functions that process messages from an Amazon SQS queue. The function scales up to handle high traffic but sometimes experiences throttling errors (HTTP 429) from Lambda. The company wants to improve the resilience of the application by reducing throttling. The SQS queue is configured as a Lambda event source with a batch size of 10. The Lambda function has a reserved concurrency of 100. Which combination of actions will best reduce throttling? (Choose the single best answer.)
⚠ Common exam trap
Watch out — candidates often confuse throttling with message processing failures and choose a dead-letter queue or batch size change, but the core issue is insufficient concurrency allocation, which only reserved concurrency adjustment can fix.
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
✓
Increase the Lambda function's reserved concurrency to 500.
Throttling errors (HTTP 429) occur when Lambda function invocations exceed the account-level concurrency limit or the function's reserved concurrency. By increasing the reserved concurrency from 100 to 500, the function can handle more concurrent invocations, reducing the likelihood of throttling when traffic spikes. This directly addresses the scaling bottleneck without changing the event source or message processing pattern.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the SQS queue to use a FIFO queue to guarantee exactly-once processing.
Why it's wrong here
Switching to a FIFO SQS queue would enforce exactly-once processing, but it does nothing to address the function's reserved concurrency ceiling. FIFO queues support a maximum of 300 messages per second per partition, which is far lower than standard SQS throughput and could actually make throttling worse by delivering messages more slowly and reducing the effective invocation rate. The root cause is that the Lambda function is already hitting its concurrency limit, so a different queue type won't remove that bottleneck.
- ✗
Increase the SQS batch size to 50 to process more messages per invocation.
Why it's wrong here
Increasing the SQS batch size to 50 allows each invocation to retrieve more messages, but Lambda's reserved concurrency still caps the number of simultaneous executions. If the function is being throttled, it means all permitted instances are already busy; a larger batch only amortizes overhead and may slightly improve per-invocation throughput, but it neither raises the concurrency ceiling nor reduces the incoming message rate. The queue will still accumulate and throttling will persist when the arrival rate exceeds the total processing capacity.
- ✗
Use a dead-letter queue (DLQ) for unprocessed messages and set up a CloudWatch alarm to trigger a second Lambda function to reprocess them.
Why it's wrong here
Configuring a DLQ to capture unprocessed messages and triggering a separate Lambda via CloudWatch alarms merely handles messages that failed after retries, not messages that were throttled due to concurrency limits. The DLQ does not increase the original function's reserved concurrency, so any reprocessing attempt will still hit the same throttling wall. Since throttling is a resource-availability problem rather than a per-message processing error, this architectural addition is irrelevant to the reported symptom.
- ✓
Increase the Lambda function's reserved concurrency to 500.
Why this is correct
Raising the Lambda function's reserved concurrency to 500 is correct because it directly increases the maximum number of simultaneous executions, allowing the SQS event source mapping to scale out beyond the previous limit and process more messages in parallel. With a higher concurrency ceiling, incoming SQS messages are consumed faster, preventing the burst of throttling attempts that occur when the function is already running at its current cap. This aligns with Lambda's SQS scaling model, where the number of active pollers grows with the message volume until the reserved concurrency is exhausted.
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.