SAA-C03 Practice Question 57: DynamoDB Hot Partition Key

Every item written on a given day shares one partition key value, so every write lands on one physical partition. A DynamoDB partition is designed to deliver at most 1,000 write units per second, which caps this table at roughly 1,000 of the required 4,000 writes per second no matter how much capacity is provisioned table-wide. That is the signature in the metrics: heavy throttling alongside consumed capacity well under the provisioned figure. Write sharding (turning 2026-09-17 into 2026-09-17.1 through 2026-09-17.N) spreads the same traffic across N partition key values and therefore across many partitions, which is the documented remedy for a workload whose access is not uniform across partition keys.

Option A changes how capacity is billed and how the table-level ceiling is managed. It does not raise the per-partition limit, and adaptive capacity applies in both modes, so a single overloaded partition key value keeps throttling in on-demand mode too.

Option B misunderstands what an index is. You cannot write to a global secondary index directly (DynamoDB populates it from writes to the base table), so the base table's hot partition key is still in the path, and the GSI adds its own write capacity consumption on top.

Option C is a read accelerator. DAX caches reads and passes writes straight through to the table, so it neither relieves write throttling nor changes the distribution of write traffic. The problem described is entirely on the write side.

Reference: Best practices for designing and using partition keys effectively in DynamoDB