DVA-C02 Troubleshooting and Optimization Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Switch to provisioned capacity mode with auto-scaling.

  Why it's wrong here

  Switching to provisioned capacity mode with auto-scaling is an incorrect approach because Amazon DynamoDB On-Demand capacity mode is specifically designed to automatically handle unpredictable workloads and traffic spikes without requiring manual capacity management. Throttling in On-Demand is typically not due to insufficient *overall* table capacity but rather often stems from uneven data access patterns, such as hot partitions, which auto-scaling on provisioned capacity would not inherently resolve. This switch would introduce operational overhead and potentially higher costs without addressing the root cause of per-partition throughput limits.

• ✗

  Increase the write capacity units.

  Why it's wrong here

  Increasing write capacity units (WCUs) is not a viable solution in Amazon DynamoDB's On-Demand capacity mode because this mode completely abstracts away the concept of WCUs and RCUs. Unlike provisioned capacity, On-Demand automatically scales throughput based on actual usage patterns, meaning there are no configurable WCU settings to adjust. Therefore, attempting to modify WCUs would be impossible and would not resolve any throttling issues, which in On-Demand are often related to hot partitions rather than insufficient configured capacity.

• ✓

  Review the partition key design and consider adding a suffix to distribute writes.

  Why this is correct

  Reviewing the partition key design and considering adding a suffix to distribute writes is the correct approach because even with On-Demand capacity, Amazon DynamoDB enforces per-partition throughput limits. A 'hot partition' occurs when a single partition key value receives a disproportionately high volume of write requests, exceeding its individual throughput capacity and leading to throttling for operations targeting that specific key. By adding a random or time-based suffix to the partition key, writes are effectively spread across multiple logical partitions, thereby distributing the load more evenly and mitigating the impact of hot spots.

• ✗

  Increase the read capacity units.

  Why it's wrong here

  Increasing the read capacity units (RCUs) would not address write throttling because read and write operations consume distinct capacity resources within Amazon DynamoDB. The problem statement explicitly indicates write throttling, meaning the bottleneck is related to the ability to process write requests, not read requests. Even if RCU adjustments were possible in On-Demand mode, increasing read capacity would have no impact on alleviating write-specific performance issues.

Go deeper

Related to this question