DEA-C01 Data Store Management Practice Question

A company uses Amazon DynamoDB to store user session data. The table has a partition key of user_id and a sort key of session_start. The workload is read-heavy and eventually consistent reads are acceptable. The table is provisioned with 1000 RCUs and 500 WCUs. During peak hours, the application experiences throttling on read operations, but CloudWatch shows that the consumed read capacity is well below the provisioned amount. What is the most likely cause of the throttling?

⚠ Common exam trap

The trap here is assuming that throttling always means insufficient provisioned capacity, overlooking per-partition limits that cause hot partitions.

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

✓

The table has a hot partition because user_id values are not evenly distributed, causing some partitions to exceed their read capacity limits.

DynamoDB throttling can occur even when overall consumed capacity is below provisioned if a single partition exceeds its per-partition limit. With a partition key like user_id, if some users are much more active, their items concentrate on one partition, causing that partition to throttle. The solution is to distribute the workload more evenly, such as by adding a random suffix to the partition key or using a composite partition key.

Answer analysis

Option-by-option breakdown

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

✗
The table's sort key is causing uneven data distribution across partitions, leading to throttling.
Why it's wrong here
The sort key does not determine partition placement; only the partition key does. DynamoDB partitions are based on the partition key hash. Uneven sort key values do not cause hot partitions. The issue is with the partition key distribution, not the sort key. Changing the sort key would not resolve the throttling.
✗
The application is using strongly consistent reads, which consume twice the read capacity units and cause throttling.
Why it's wrong here
The scenario states that eventually consistent reads are acceptable, implying they are used. Strongly consistent reads would double the RCU consumption, but if consumed capacity is below provisioned, that would not cause throttling. The throttling is likely due to per-partition limits, not consistency model. Switching to eventually consistent reads would not fix a hot partition.
✓
The table has a hot partition because user_id values are not evenly distributed, causing some partitions to exceed their read capacity limits.
Why this is correct
DynamoDB partitions have a maximum read capacity of 3000 RCUs per partition. If a few user_id values are accessed much more frequently than others, those items reside on the same partition, causing that partition to throttle even though overall table capacity is underutilized. This is a classic hot partition scenario, and the fix is to distribute the workload more evenly, such as by adding a random suffix to the partition key.
✗
The table's provisioned read capacity is too low for the workload, and the engineer should increase it to resolve throttling.
Why it's wrong here
CloudWatch shows consumed read capacity is below provisioned, so increasing provisioned capacity would not help. The throttling is due to per-partition limits, not overall table capacity. Adding more RCUs would not alleviate the hot partition issue and would increase cost unnecessarily. The root cause is uneven data access, not insufficient provisioned throughput.

Go deeper

DEA-C01 Data Store Management Practice Question

Why each option matters

Option-by-option breakdown

Related to this question