Question 395 of 724
DVA-C02 Troubleshooting and Optimization Practice Question
A developer notices that an AWS Lambda function, which processes messages from an SQS queue, is taking longer than expected. The function has a reserved concurrency of 5 and a batch size of 10. The SQS queue has a large backlog. CloudWatch metrics show that the function's throttles are high. The function is idempotent and can process up to 100 messages per invocation. What is the most effective way to increase throughput without increasing reserved concurrency?
⚠ Common exam trap
A common pitfall is assuming that Lambda's SQS batch size is limited to 10. In fact, for standard queues the maximum is 10,000. Since the function can process up to 100 messages per invocation, increasing the batch size to 100 directly increases throughput without increasing reserved concurrency. Candidates may also incorrectly consider increasing reserved concurrency, which is explicitly outside the scope of the question.
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 batch size to 100.
Increasing the batch size to 100 directly reduces the number of Lambda invocations required to process the backlog, thereby decreasing throttling without increasing reserved concurrency. The function's capacity to handle up to 100 messages per invocation makes this alignment optimal. SQS event source mappings support batch sizes up to 10,000 for standard queues, so a batch size of 100 is feasible. Short polling (option D) would not improve throughput; it causes frequent empty responses and does not reduce throttling. Increasing reserved concurrency violates the constraint, and changing timeout (option C) does not address throttling.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the batch size to 100.
Why this is correct
By increasing the SQS batch size to 100, the Lambda function processes up to 100 messages in a single invocation. Since the function is capable of handling this volume, this optimization significantly reduces the total number of Lambda invocations required to process a given message backlog. Fewer invocations directly translate to a lower invocation rate, effectively alleviating the throttling issues experienced by the function and optimizing resource utilization.
- ✗
Increase reserved concurrency to 10.
Why it's wrong here
While increasing reserved concurrency would allow the Lambda function to execute more instances in parallel, potentially improving overall throughput, the problem statement explicitly forbids this action. Reserved concurrency guarantees dedicated execution capacity but cannot be modified under the given constraints. Therefore, despite its general utility, this option is invalid for addressing the throttling problem within the specified limitations.
- ✗
Change the function timeout to 15 minutes.
Why it's wrong here
Modifying the Lambda function timeout to 15 minutes would only be beneficial if the function was frequently terminating due to exceeding its current execution duration. The problem describes a throttling issue, indicating the function is being invoked too frequently or exceeding concurrency limits, not that individual invocations are failing due to timeouts. Therefore, increasing the timeout would not reduce the invocation rate or address the root cause of throttling.
- ✗
Enable SQS short polling to reduce latency.
Why it's wrong here
Enabling SQS short polling causes the `ReceiveMessage` API call to return immediately, even if no messages are available, leading to a higher frequency of empty responses. This behavior increases the number of API requests made to SQS and does not improve the efficiency of message processing by the Lambda function. Consequently, it would not reduce the Lambda invocation rate and could potentially worsen the overall system load, making it an ineffective solution for throttling.
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 |
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.