Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in understanding DynamoDB throttling when provisioned capacity isn’t apparently exceeded. In production, this comes down to knowing exactly how local secondary indexes share capacity with tables and the critical importance of implementing exponential backoff retry logic to handle bursts. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Qwest Labs is developing an event tracking backend that writes records into an Amazon DynamoDB table. The team has designed the table with a Local Secondary Index (LSI) to support several query patterns. During stress testing, the application frequently encounters ProvisionedThroughputExceededException errors. However, their monitoring dashboards show that the provisioned write capacity for the table and the LSI is never exceeded.
The Requirement: #
Identify the primary reason that this throttling exception occurs despite not exceeding the table’s provisioned capacity limits.
The Options #
- A) The partition key values in the table are not evenly distributed, causing “hot” partitions to exceed throughput.
- B) The LSI consumes capacity from the table’s provisioned throughput, causing localized throttling even if the overall table limits seem sufficient.
- C) The application is not implementing exponential backoff retry logic when receiving throttling errors from DynamoDB.
- D) The application’s IAM role allows querying the table but lacks permissions to query the LSI.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
DynamoDB LSIs share the provisioned throughput of their parent table, so capacity limits apply collectively. Even if aggregate capacity is okay, specific LSI partitions can cause throttling. Proper retry logic (C) is important but not the root cause here.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
Local Secondary Indexes share the parent table’s provisioned throughput rather than having separate capacity. This means the capacity consumed by queries and writes to the LSI counts against the table’s total provisioned throughput. If LSI access patterns are uneven or bursty, they can cause throttling errors (ProvisionedThroughputExceededException) without exceeding the reported overall limits on the table capacity.
- This is a common source of confusion, as dashboards showing total consumed capacity might appear normal. But throttling is partition and operation-specific inside the table+LSI.
- Exponential backoff (Option C) is essential best practice but won’t stop throttling if capacity is truly exhausted on a partition or LSI.
- Uneven partition keys (Option A) can cause throttling but here the question points to LSI-related issues.
- Permission issues (Option D) cause access denied errors, not throughput exceptions.
The Trap (Distractor Analysis) #
- Why not A? Partition key “hot spots” cause throttling, but the question specifies LSI and presents no evidence of skew.
- Why not C? Lack of retry may cause higher error rates but not throttling itself.
- Why not D? Permissions errors do not generate throughput exceptions, it’s a separate error category.
The Technical Blueprint #
# Example of using AWS CLI to describe the DynamoDB table and its LSI to check capacities
aws dynamodb describe-table --table-name EventTrackingTable --query "Table.LocalSecondaryIndexes[*].[IndexName,ProvisionedThroughput.ReadCapacityUnits,ProvisionedThroughput.WriteCapacityUnits]"
The Comparative Analysis #
| Option | API Complexity | Performance Impact | Use Case Explanation |
|---|---|---|---|
| A | Low | Can cause throttling at partition level | Hot partition keys skew capacity utilization |
| B | Medium | Explains throttling despite overall capacity being fine | LSI shares capacity with table; localized limits matter |
| C | Low | Missing retry worsens UX but not root cause | Recommended practice but not direct cause |
| D | Low | No impact on throughput, only IAM errors | Incorrect usage scenario for throughput exception |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick B when you see DynamoDB LSI and throughput exceeded exceptions without overall capacity breach.
Real World #
In reality, teams might switch to GSI (Global Secondary Index) for isolated capacity allocation, or switch to on-demand billing to avoid these complexities at the cost of higher unit pricing.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.