Your mobile app writes events to a single DynamoDB table with partition key = customerId and sort key = eventTime. During a promotional campaign, one tenant ("ACME") generates far more traffic than others. CloudWatch shows sustained throttling (ProvisionedThroughputExceeded) and elevated p99 latency only for that tenant. The workload pattern cannot be changed to a completely different schema, but you can change how items are partitioned. Which design change is most likely to reduce the hot-partition throttling while keeping efficient reads for ACME?

Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.

Increasing provisioned capacity can raise the overall throughput ceiling, but DynamoDB throttling for a hot partition is driven by per-partition limits (and uneven item/key distribution), not just by the table’s total capacity. If nearly all ACME writes still target the same partition (same customerId value), that single partition can remain the bottleneck, so throttling and p99 latency can persist during spikes.

Switch to on-demand capacity mode and keep the partition key unchanged.

On-demand capacity automatically scales the table’s overall capacity, but it does not remove per-partition request limits. If all ACME traffic still targets one partition key value, that partition can still become hot and throttle, so p99 latency and ProvisionedThroughputExceeded events can continue during spikes.

Enable Global Tables so that reads are served from a nearby replica for ACME.

Global Tables can reduce network latency and improve availability across regions, but they do not address hot partitions within a region. If ACME’s writes concentrate on a single partition key value, the corresponding partition in each replica can still be the throttling bottleneck for that tenant.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key. — ACME’s throttling is isolated to a single partition key value (customerId), which is the hallmark of a hot-partition problem. The most direct mitigation is to increase the number of partitions that receive ACME’s write traffic. Salting the partition key (for example, customerId + shardId) distributes ACME’s items across multiple physical partitions, reducing request rate per partition and therefore lowering throttling and p99 latency. Reads remain efficient because you can query a known set of shard partition keys for ACME (often in parallel) rather than performing full-table scans or relying on all tenants sharing the same hot partition. A increases total capacity but keeps the same single hot partition key value, so the per-partition bottleneck remains. C changes capacity mode but does not change partition-level limits; the hottest partition can still throttle. D improves cross-region access latency but does not resolve uneven partition utilization inside each region.

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.