A DynamoDB table uses this schema: partition key = customerId, sort key = timestamp. During a marketing campaign, one customer generates extremely high read traffic and the application sees ProvisionedThroughputExceeded errors even though the table’s total capacity is sufficient. What change most directly improves read distribution across partitions?

Increase the table’s provisioned read capacity units while keeping partition key = customerId.

Increasing provisioned read capacity can raise the overall throughput, but it does not address the root cause of hot partitions: all reads for a given customerId target the same partition(s). If a single partition must serve most reads, throttling can still occur even with more total capacity.

Remove the sort key and use timestamp as the partition key to increase cardinality.

Using timestamp as the partition key may increase the number of distinct partition key values, but it does not guarantee distribution aligned with the customer’s read hotspot. During a campaign, traffic volume per customer is still the dominant factor; reads could still concentrate on the same time windows or key values relative to query patterns.

Switch to on-demand capacity and rely on DynamoDB to automatically distribute reads across partitions.

On-demand capacity can absorb bursts by provisioning capacity dynamically, but it does not change how requests map to partitions. If the partition key design causes a single partition key value to receive a disproportionate share of traffic, throttling behavior can still appear for that hot partition even in on-demand mode.

What does this SAA-C03 question test?

Read the scenario before looking for a memorised answer.

What is the correct answer to this question?

The correct answer is: Add a salt component to the partition key by changing it to customerId#salt, where salt is derived from a hash of requestId so a single customer’s requests are spread across many partitions; keep the sort key as timestamp. — DynamoDB throttling like ProvisionedThroughputExceeded often happens at the partition level. With partition key = customerId, all requests for the hot customerId concentrate on the same partition key value. Adding a salt to the partition key (for example, customerId#salt where salt is a hash of requestId) spreads one customer’s reads across many logical partition keys, increasing parallelism across partitions. Simply increasing capacity or switching to on-demand postpones throttling but doesn’t fundamentally fix the partitioning imbalance. Why others are wrong: Provisioned capacity increases overall headroom but still routes the majority of reads for the hot customer to the same partition key value. Changing the sort key/partitioning approach to timestamp does not ensure distribution for customer-driven hotspots and may create time-window skew. On-demand mode changes billing/provisioning behavior but does not change the partition key mapping that causes hot partitions in the first place.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.