SAA-C03 Design High-Performing Architectures Practice Question
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?
⚠ Common exam trap
Many candidates think increasing provisioned capacity or switching to on-demand mode will automatically resolve a hot partition, but DynamoDB's per-partition throughput limit (3,000 RCU or 1,000 WCU) is a hard ceiling that cannot be overcome without redistributing the partition key.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
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.
It directly addresses the partition-level throttling by introducing a shard key (e.g., tenantId + '#' + shardId) as the partition key, which distributes ACME's write load across multiple physical partitions. To query recent events for ACME, the application must fan out queries across all shards and merge results by eventTimestamp, which is efficient because each shard holds a subset of the data and the sort key remains eventTimestamp for ordering.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a Global Secondary Index (GSI) with the same partition key (tenantId) and eventTimestamp, and rely on the GSI to spread load.
Why it's wrong here
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.
- ✓
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.
Why this is correct
In DynamoDB, the partition key controls which physical partitions receive traffic for that key value. By adding shardId into the partition key, ACME writes are distributed across multiple partitions, increasing aggregate write capacity and reducing partition-level throttling. Efficient recent-event queries are still possible by querying each ACME shard for the relevant time range (using eventTimestamp as the sort key) and merging the ordered results.
- ✗
Increase the table’s write capacity (or on-demand baseline) without changing the partition key, because DynamoDB will automatically balance hotspots.
Why it's wrong here
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.
Why it's wrong here
The partition key determines the DynamoDB partition to which an item is written; the sort key only orders items within that partition. Changing the sort key to a random value does not alter the hash of the partition key, so every ACME write still maps to the same physical partition(s). Consequently, the write workload for the hot tenant remains concentrated, and partition-level throttling continues. Worse, random sort keys break the natural time ordering, making efficient range queries on recent events impossible without a separate global index.
Go deeper
Related to this question
About these practice questions
Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.