An event ingestion service writes to a DynamoDB table where the partition key is tenantId and the sort key is eventTime. During a campaign, one tenant generates a disproportionate share of traffic, causing write throttling and increased latency for that tenant’s writes. You can change the data model and application queries, but you must still efficiently retrieve events for a tenant for the last 10 minutes. Which change best improves write throughput by reducing hot partitions?

Keep tenantId as the partition key and rely on DynamoDB adaptive capacity to automatically remove all throttling.

Adaptive capacity may help with some workloads, but it cannot eliminate the fundamental issue when a single partition key (tenantId) receives sustained traffic beyond that partition’s throughput. For a hot tenant, you still need to distribute writes across multiple physical partitions.

Change the sort key to eventTimeBucket (for example, eventTime rounded to 1-minute buckets) while keeping the partition key as tenantId.

Changing only the sort key does not resolve hot partition issues because the partition key (tenantId) still concentrates all writes for that tenant into a single partition. DynamoDB distributes capacity primarily by partition key, not sort key.

Enable DAX and use it for write operations so throttled writes are served from cache instead of reaching DynamoDB.

DAX is a read-through cache designed to accelerate reads, not to absorb write throughput or bypass DynamoDB write capacity limits. Throttling on writes occurs before any cached read path, so DAX does not address the hot-partition write bottleneck.

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: Add a shard attribute to the partition key (partition key = tenantId#shard, where shard is randomly selected from a fixed range). Query all shards for the tenant for eventTime values in the last 10 minutes, then merge results in the application. — DynamoDB throttling is happening because one partition key value (tenantId) is receiving too many writes for the throughput available to that hot partition. The most effective model change is to shard the partition key (for example, tenantId#shard) so writes are distributed across multiple partitions. You can still efficiently retrieve the last 10 minutes by performing a sort-key time range query (eventTime) on each shard and merging results in the application. (A) Adaptive capacity is not a substitute for partition-key distribution when a single partition key is consistently overloaded. (C) Sort-key changes alone do not distribute write load because all writes still target the same partition key value. (D) DAX accelerates reads only and cannot prevent write throttling caused by hot partition capacity limits.

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.