DEA-C01 Data Store Management Practice Question

A company uses Amazon DynamoDB as the primary data store for a gaming application. The application stores user profiles and game state. During peak hours, the application experiences throttling on writes to the UserProfiles table. The table's read capacity is underutilized. Which solution should resolve the write throttling?

⚠ Common exam trap

Test-takers frequently confuse read and write capacity solutions, such as selecting DAX (which only helps reads) or auto scaling for reads, when the issue is specifically write throttling.

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 provisioned write capacity units for the table.

Write throttling occurs when the number of write requests exceeds the provisioned write capacity units (WCUs) for the DynamoDB table. Since the read capacity is underutilized, the correct solution is to increase the provisioned WCUs to accommodate the peak write traffic. This directly addresses the capacity deficit without affecting read operations.

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 provisioned write capacity units for the table.
Why this is correct
Increasing provisioned write capacity units directly raises the table's write throughput ceiling, eliminating the throttling caused by write requests exceeding the current WCU allocation during peak hours. Since read capacity is underutilised, only write capacity needs adjustment, making this the precise fix for the stated write bottleneck.
✗
Enable DynamoDB Accelerator (DAX) on the table.
Why it's wrong here
DAX caches read results in front of the table, reducing read latency and consumed read capacity; it does not add write throughput, so write throttling persists. It is tempting because the stem notes reads are underutilised, and DAX would be correct if the bottleneck were repeated read-heavy queries against eventually consistent data.
✗
Add a global secondary index (GSI) to the table.
Why it's wrong here
A GSI adds a separate index with its own capacity, consuming additional WCUs on writes rather than relieving the throttling on the base table. GSIs suit query patterns needing alternative partition or sort keys, not resolving write capacity exhaustion.
✗
Configure auto scaling for read capacity units.
Why it's wrong here
Read capacity is already underutilised, so scaling RCUs leaves the write bottleneck untouched; the table needs more WCUs. Auto scaling is the right tool for smoothing variable throughput on the capacity axis that is actually constrained, which here is writes.

Visual reference

Go deeper

DEA-C01 Data Store Management Practice Question

Why each option matters

Option-by-option breakdown

Related to this question