DEA-C01 Eventually Consistent Reads Practice Question

Which TWO actions can help improve the read performance of an Amazon DynamoDB table that is experiencing throttling? (Choose two.)

⚠ Common exam trap

The trap is that candidates often overlook eventually consistent reads as a cost-effective way to reduce throttling, focusing instead on adding GSIs or enabling DAX, which address latency or query patterns but not the root cause of exceeding provisioned capacity.

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 read capacity units (RCUs) for the table.

Option B is correct because DynamoDB throttling on reads occurs when request rate exceeds the table's provisioned read capacity units (RCUs); increasing the provisioned RCUs directly raises the available read throughput and relieves the throttling. Option C is correct because eventually consistent reads consume only half the RCUs of strongly consistent reads (1 RCU per 4 KB vs. 1 RCU per 2 KB), so switching to eventually consistent reads effectively doubles the read throughput available for the same provisioned capacity. Option A is wrong because DAX is designed to accelerate read-heavy workloads by caching, not write-heavy ones, and it does not address the stated read throttling. Option D is wrong because adding a GSI does not increase the base table's read capacity and actually adds its own separate capacity costs and potential throttling. Option E is wrong because auto-scaling with a lower minimum capacity would reduce available RCUs and worsen, not improve, read 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.

✗
Enable DynamoDB Accelerator (DAX) for write-heavy workloads.
Why it's wrong here
DAX caches item reads, so pairing it with write-heavy workloads adds no read benefit and can introduce write-through overhead; throttling on reads persists. DAX is the right choice when the table is read-intensive with repeated key access patterns.
✓
Increase the provisioned read capacity units (RCUs) for the table.
Why this is correct
Raising provisioned RCUs directly lifts the table's read throughput ceiling, so sustained request rates that previously exceeded capacity no longer trigger ProvisionedThroughputExceededException throttling. This satisfies the stem's throttling constraint by matching allocated capacity to actual read demand, provided the workload is read-capacity-bound rather than partition-hot.
✓
Use eventually consistent reads instead of strongly consistent reads.
Why this is correct
Eventually consistent reads consume half the read capacity units of strongly consistent reads, directly easing the provisioned throughput constraint causing the throttling. This reduces capacity consumption per request, allowing more read operations within the same RCU budget, which improves read performance without altering table schema or capacity settings.
✗
Add a global secondary index (GSI) with a different partition key.
Why it's wrong here
Adding a GSI does not reduce throttling on the base table; it consumes separate write capacity and can worsen it. GSIs exist to serve queries on an alternative partition key, and would be the right choice when access patterns require a different key, not when the existing table is already throttled.
✗
Enable auto-scaling with a lower minimum capacity.
Why it's wrong here
Auto-scaling adjusts provisioned throughput in response to consumption; lowering the minimum capacity reduces the floor available during read spikes, worsening throttling. It is the correct lever when traffic is predictable and you want to trim cost during idle periods.

Go deeper

DEA-C01 Eventually Consistent Reads Practice Question

Why each option matters

Option-by-option breakdown

Related to this question