DynamoDB & Partition Key — SAA-C03 Practice Question
A representative AWS Solutions Architect Associate (SAA-C03) exam question on DynamoDB & Partition Key. Work through it below, then read why each option is right or wrong.
Short answer
The correct answer is A. The hot partition problem: 100 critical devices create hot partitions because all reads concentrate on a few partition keys. Use DynamoDB DAX to cache the hot reads and reduce partition load.
This is a classic hot partition scenario. DynamoDB distributes data across partitions based on the partition key. With 100 critical devices receiving 95% of reads, those specific partitions experience disproportionate read traffic. DynamoDB Accelerator (DAX) is purpose-built for this — it caches frequently read items in memory, serving hot reads with microsecond latency without touching the underlying DynamoDB partitions. This eliminates the hot partition throttling.
The Question
An IoT company collects sensor data from 10,000 devices. Each device sends data every second to a DynamoDB table. The table's partition key is the device_id and the sort key is the timestamp. During analysis, the company discovers that 95% of read queries are for the 50 most recent data points from a subset of 100 "critical" devices. The remaining queries are distributed across all devices. Despite provisioning sufficient read capacity, reads for critical devices experience throttling. What is the MOST LIKELY cause and the appropriate solution?
Why A is correct
This is a classic hot partition scenario. DynamoDB distributes data across partitions based on the partition key. With 100 critical devices receiving 95% of reads, those specific partitions experience disproportionate read traffic. DynamoDB Accelerator (DAX) is purpose-built for this — it caches frequently read items in memory, serving hot reads with microsecond latency without touching the underlying DynamoDB partitions. This eliminates the hot partition throttling.
Why the other options are wrong
Simply increasing read capacity units does not solve hot partition throttling. DynamoDB distributes capacity across partitions, so adding more total capacity does not increase the per-partition limit proportionally. The hot partitions would still be throttled even with higher table-level capacity (though adaptive capacity helps, it has limits).
Adding a random suffix to the sort key would not help because reads are concentrated on specific partition keys (device_ids), not sort keys. The partition key determines physical distribution. Changing the sort key does not affect partition distribution. To scatter writes, you would need to modify the partition key, which would complicate the query pattern.
Creating a separate table does not fundamentally solve the hot partition problem — 100 critical devices would still create hot partitions in the new table. On-demand capacity mode helps with burst capacity but still has per-partition limits. DAX is the correct solution for caching hot reads.
Key idea: DynamoDB & Partition Key
Why A is correct: This is a classic hot partition scenario. DynamoDB distributes data across partitions based on the partition key. With 100 critical devices receiving 95% of reads, those specific partitions experience disproportionate read traffic. DynamoDB Accelerator (DAX) is purpose-built for this — it caches frequently read items in memory, serving hot reads with microsecond latency without touching the underlying DynamoDB partitions. This eliminates the hot partition throttling. Why B is wrong: Simply increasing read capacity units does not solve hot partition throttling. DynamoDB distributes capacity across partitions, so adding more total capacity does not increase the per-partition limit proportionally. The hot partitions would still be throttled even with higher table-level capacity (though adaptive capacity helps, it has limits). Why C is wrong: Adding a random suffix to the sort key would not help because reads are concentrated on specific partition keys (device_ids), not sort keys. The partition key determines physical distribution. Changing the sort key does not affect partition distribution. To scatter writes, you would need to modify the partition key, which would complicate the query pattern. Why D is wrong: Creating a separate table does not fundamentally solve the hot partition problem — 100 critical devices would still create hot partitions in the new table. On-demand capacity mode helps with burst capacity but still has per-partition limits. DAX is the correct solution for caching hot reads. On the SAA-C03 exam, questions in the "Design High-Performing Architectures" domain test whether you can map a scenario's constraints to the right choice. Read the requirement carefully, eliminate options that violate any single constraint, and pick the one that satisfies all of them with the least operational overhead.
Ready to see how you'd score?
Take the free practice quiz and find out which AWS Solutions Architect Associate domains you need to focus on. No signup required.
Practice 5 similar questions
Same cert, same or adjacent domain. Use these after reviewing the explanation.