The answer is to add a sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant’s shards. This resolves the DynamoDB hot partition by distributing the heavy write traffic from the single dominant tenant across multiple physical partitions, because DynamoDB’s partition key alone determines data placement and a single tenantId would bottleneck all writes onto one partition. On the SAA-C03 exam, this scenario tests your understanding of adaptive capacity versus manual sharding—a common trap is to simply increase write capacity units, which does not fix the underlying partition-level throttling. Remember that a hot partition is a partition key problem, not a table capacity problem; sharding spreads the load while preserving fast lookups by querying all shards for that tenant. Memory tip: “Shard the key, spread the heat—query all shards to stay fleet.”
SAA-C03 Design High-Performing Architectures Practice Question
This SAA-C03 practice question tests your understanding of design high-performing architectures. Read the scenario carefully and evaluate each option against the stated constraints before committing to an answer. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
Exhibit
Table schema:
- TableName: EventStore
- PartitionKey: tenantId (String)
- SortKey: eventTime (Number)
CloudWatch metrics during promotion:
- WriteThrottleEvents: increasing steadily
- ConsumedWriteCapacityUnits: near provisioned limit
- SuccessfulRequestLatency p95: 14 ms
Sample traffic distribution:
- tenantId=ACME: 82% of writes, 79% of reads
- all other tenants combined: 18% of writes, 21% of reads
Application note:
- Queries must continue to support tenant-scoped lookups by time range.
Based on the exhibit, a DynamoDB-backed event processing system is throttling during a promotion. The table uses tenantId as the partition key and eventTime as the sort key. One tenant accounts for most of the write traffic, and the application must preserve fast lookups for that tenant without relying on a single hot partition. What change is the best fix?
Clue words in this question
Noticing these words before you look at the options changes how you read each choice.
Clue: "best"
Why it matters: Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
Table schema:
- TableName: EventStore
- PartitionKey: tenantId (String)
- SortKey: eventTime (Number)
CloudWatch metrics during promotion:
- WriteThrottleEvents: increasing steadily
- ConsumedWriteCapacityUnits: near provisioned limit
- SuccessfulRequestLatency p95: 14 ms
Sample traffic distribution:
- tenantId=ACME: 82% of writes, 79% of reads
- all other tenants combined: 18% of writes, 21% of reads
Application note:
- Queries must continue to support tenant-scoped lookups by time range.
A
Add a sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards.
Sharding the partition key spreads ACME traffic across multiple partitions, which removes the hot key problem. Because the application still needs tenant-scoped time-range queries, it can fan out across the shard values and merge results.
B
Enable DynamoDB Streams so the table can process writes more quickly.
Why wrong: Streams capture changes after writes succeed, but they do not change partition distribution or write capacity pressure. The hot partition would still throttle under the same traffic pattern.
C
Switch the table to on-demand capacity mode and keep the same key design.
Why wrong: On-demand mode can absorb variable load, but it does not solve a single partition becoming hot. A skewed key can still throttle even when total table capacity increases automatically.
D
Add a global secondary index on eventTime and query the index instead of the base table.
Why wrong: A GSI changes the access pattern, but it still needs a well-distributed partition key. Indexing only by eventTime would not preserve tenant-scoped lookups and could introduce a new hot partition.
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Add a sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards.
Option A is correct because adding a sharding suffix (e.g., tenantId#shardId) to the partition key distributes write traffic for the hot tenant across multiple partitions, eliminating the single-partition bottleneck while preserving fast lookups by querying across all shards for that tenant. DynamoDB's partition key determines physical storage; without sharding, all writes for the hot tenant land on one partition, causing throttling even if the table has sufficient total capacity.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
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 sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards.
Why this is correct
Sharding the partition key spreads ACME traffic across multiple partitions, which removes the hot key problem. Because the application still needs tenant-scoped time-range queries, it can fan out across the shard values and merge results.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
✗
Enable DynamoDB Streams so the table can process writes more quickly.
Why it's wrong here
Streams capture changes after writes succeed, but they do not change partition distribution or write capacity pressure. The hot partition would still throttle under the same traffic pattern.
✗
Switch the table to on-demand capacity mode and keep the same key design.
Why it's wrong here
On-demand mode can absorb variable load, but it does not solve a single partition becoming hot. A skewed key can still throttle even when total table capacity increases automatically.
✗
Add a global secondary index on eventTime and query the index instead of the base table.
Why it's wrong here
A GSI changes the access pattern, but it still needs a well-distributed partition key. Indexing only by eventTime would not preserve tenant-scoped lookups and could introduce a new hot partition.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates often assume on-demand mode (Option C) eliminates all throttling, but it does not resolve the physical partition limit—a single hot partition still caps at 1,000 WCU/3,000 RCU, so throttling persists regardless of capacity mode.
Detailed technical explanation
How to think about this question
DynamoDB partitions data based on the partition key's hash value; a single partition can handle up to 1,000 write capacity units (WCU) or 3,000 read capacity units (RCU). By appending a random or calculated shard ID (e.g., 0–9) to tenantId, writes are spread across up to 10 partitions, each with its own capacity, effectively multiplying the write throughput for that tenant. Queries must then fan out across all shards and merge results, which is a common pattern for high-traffic multi-tenant workloads.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A media company stores terabytes of video archives that are accessed once a year for audit purposes. Moving these objects to a cold storage tier (Azure Archive, S3 Glacier, or Google Nearline) costs a fraction of hot storage. Questions like this test whether you understand storage tiers, access frequency tradeoffs, and retrieval latency requirements.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Design High-Performing Architectures — This question tests Design High-Performing Architectures — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Add a sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards. — Option A is correct because adding a sharding suffix (e.g., tenantId#shardId) to the partition key distributes write traffic for the hot tenant across multiple partitions, eliminating the single-partition bottleneck while preserving fast lookups by querying across all shards for that tenant. DynamoDB's partition key determines physical storage; without sharding, all writes for the hot tenant land on one partition, causing throttling even if the table has sufficient total capacity.
What should I do if I get this SAA-C03 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Are there clue words in this question I should notice?
Yes — watch for: "best". Signals that multiple options may be partially correct. Choose the option that most directly solves the exact problem described, not the one that sounds most complete.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A DynamoDB-backed event processing system experiences throttling during a promotion. All events are written and read using the same partition key value (tenantId = "ACME"). The workload is time-ordered per tenant, and the application can tolerate slight reordering across partitions. Which design change will most directly increase throughput and reduce hot-partition throttling?
medium
A.Increase the table's provisioned capacity (read/write units) to handle the promotion peak.
✓ B.Change the partition key to include an additional sharding attribute derived from a hash of eventId.
C.Enable DAX caching for all reads but keep the same partition key and item layout.
D.Switch the table to eventually consistent reads for queries to lower read throttling.
Why B: Option B is correct because adding a sharding attribute derived from a hash of eventId allows writes and reads to be distributed across multiple partition keys, breaking the single hot partition caused by using tenantId='ACME' for all operations. DynamoDB's throughput is limited per partition, so distributing the load across many partitions directly reduces throttling without changing the application's tolerance for slight reordering.
Variation 2. A DynamoDB-backed multi-tenant app experiences throttling during a promotion. Most writes and reads target tenant "ACME" and use the same partition key value, causing a hot partition. Which design change most directly improves performance?
easy
✓ A.Add a "shard" component to the partition key (for example, tenantId + hashed bucket) to spread traffic across partitions
B.Increase the table’s read capacity without changing the partition key
C.Switch all reads to strongly consistent reads to guarantee faster results
D.Store ACME data in S3 and query it directly to avoid DynamoDB throttling
Why A: Option A is correct because adding a shard component to the partition key (e.g., appending a random or hash-based suffix to the tenant ID) distributes writes and reads for the same tenant across multiple physical partitions. This directly alleviates the hot partition caused by all ACME traffic hitting a single partition key value, allowing DynamoDB to utilize its full provisioned throughput across partitions.
Variation 3. 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?
medium
A.Add a Global Secondary Index (GSI) with the same partition key (tenantId) and eventTimestamp, and rely on the GSI to spread load.
✓ B.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.
C.Increase the table’s write capacity (or on-demand baseline) without changing the partition key, because DynamoDB will automatically balance hotspots.
D.Switch the sort key to a random value to prevent writes from landing on the same physical partition.
Why B: Option B is correct because 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.
Last reviewed: Jun 11, 2026
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.