A DynamoDB-backed multi-tenant app experiences throttling. Most write traffic for tenant 'ACME' targets a single logical stream of events (you write items for ACME in near-real time). The table currently uses partition key = tenantId and sort key = eventTimestamp. CloudWatch shows partition-level throttling concentrated in the ACME partition. What design change most directly improves write throughput for the hottest tenant while still enabling efficient queries for recent events for that tenant?

Add a Global Secondary Index (GSI) with the same partition key (tenantId) and eventTimestamp, and rely on the GSI to spread load.

A GSI routes writes and reads based on its own partition key. If the GSI uses the same partition key value (tenantId) and 'ACME' remains dominant, the traffic will still concentrate on a small set of partitions. The hotspot problem remains.

Increase the table’s write capacity (or on-demand baseline) without changing the partition key, because DynamoDB will automatically balance hotspots.

Scaling capacity may reduce throttling in some cases, but it does not change the fundamental routing: all ACME writes still map to the same underlying partition(s). Partition-level hot keys can continue to throttle even when overall capacity increases.

Switch the sort key to a random value to prevent writes from landing on the same physical partition.

The physical partition mapping depends on the partition key, not the sort key. Randomizing the sort key changes ordering within the partition, but it does not distribute traffic across partitions for the hot tenantId.

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: Mitigate the hotspot by changing the partition key to include a shard value (for example, tenantId + '#' + shardId) and write using shardId. Query recent events by fanning out across ACME shards and merging results by eventTimestamp. — DynamoDB routes all traffic for a given partition key value (here, tenantId='ACME') to specific partitions. When ACME dominates writes, those partitions throttle. The most direct fix is to add sharding by incorporating shardId into the partition key (for example, tenantId#shardId), which spreads ACME writes across multiple partitions. Queries for recent events remain efficient by querying each shard for ACME using eventTimestamp as the sort key (for the time range) and merging results client-side (or in an application layer) by timestamp. Using a GSI with the same tenantId partition key does not change partition routing for ACME, so the hotspot persists. Increasing overall capacity does not eliminate partition-level hot keys because the same partition key values still map to the same underlying partitions. Changing the sort key does not change which physical partitions receive traffic; only the partition key (tenantId#shardId) controls that routing.

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.