DVA-C02 Troubleshooting and Optimization Practice Question
A developer is running an AWS Lambda function that is triggered by Amazon S3 events. The function writes processed data to an Amazon DynamoDB table. Over time, the function's execution time has increased significantly. CloudWatch Logs show many DynamoDBProvisionedThroughputExceededException errors. The table is configured with 5 read capacity units (RCUs) and 5 write capacity units (WCUs). The function performs both reads and writes. Which optimization will MOST effectively reduce throttling errors while maintaining performance?
⚠ Common exam trap
Candidates often confuse read throttling with write throttling and reach for DAX (a read cache) or assume that increasing Lambda resources will solve database-level throughput issues, when the real fix is to match the database capacity mode to the workload pattern.
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
✓
Switch the DynamoDB table to on-demand capacity mode
The DynamoDBProvisionedThroughputExceededException errors indicate that the Lambda function is exceeding the provisioned write capacity of 5 WCUs. Switching to on-demand capacity mode eliminates the need to manage throughput, automatically scaling to handle the workload without throttling. This directly resolves the root cause—capacity exhaustion—without requiring manual adjustments or architectural changes.
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 RCUs and WCUs of the table to 50 each
Why it's wrong here
Increasing RCUs and WCUs to 50 each would raise the DynamoDB table's throughput capacity, directly addressing the provisioned throughput exceeded errors by allowing more writes per second. However, this does not resolve the root cause: the Lambda function likely performs inefficient repeated reads or writes, such as retrieving the same item multiple times or using a suboptimal write pattern. The correct optimisation would instead implement DynamoDB Accelerator (DAX) for caching reads or batch writes to reduce per-request consumption. This option is tempting because scaling capacity is the intuitive fix for throttling, and it would be correct if the function's workload genuinely exceeded the original 5 WCUs/RCUs due to increased traffic rather than inefficient access patterns.
- ✓
Switch the DynamoDB table to on-demand capacity mode
Why this is correct
Switching to on-demand capacity mode allows DynamoDB to automatically scale read and write throughput based on the actual traffic patterns generated by the Lambda function. This eliminates ProvisionedThroughputExceededException errors by dynamically adjusting capacity, ensuring the table can handle unpredictable or spiky workloads without manual intervention or capacity planning. It directly resolves throttling issues stemming from insufficient provisioned capacity.
- ✗
Implement a DynamoDB Accelerator (DAX) cluster for caching reads
Why it's wrong here
A DynamoDB Accelerator (DAX) cluster is designed to provide in-memory caching for read-heavy workloads, significantly reducing read latency and offloading read capacity from the primary DynamoDB table. However, DAX does not cache or accelerate write operations. If the Lambda function is experiencing throttling due to exceeding write capacity, DAX will not mitigate these write-related ProvisionedThroughputExceededException errors.
- ✗
Increase Lambda function memory to 1024 MB
Why it's wrong here
Increasing a Lambda function's memory allocation primarily enhances its CPU power, network bandwidth, and available temporary disk space within the execution environment. While this can improve the function's internal processing speed, it has no direct impact on the external capacity limits of a DynamoDB table. Throttling errors originate from DynamoDB's inability to process requests due to insufficient provisioned or on-demand capacity, not from the Lambda function's resource constraints.
Visual reference
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 724 original DVA-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.