← SAA-C03·Amazon Web Services

Question 203 of 1,040

Design High-Performing Architectures →mediumMultiple ChoiceObjective-mapped

DynamoDB Hot Partition Solution: Shard Key Design

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.

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?

A
Add a Global Secondary Index (GSI) with the same partition key (tenantId) and eventTimestamp, and rely on the GSI to spread load.
Why wrong: 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.
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.
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.
C
Increase the table’s write capacity (or on-demand baseline) without changing the partition key, because DynamoDB will automatically balance hotspots.
Why wrong: 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.
D
Switch the sort key to a random value to prevent writes from landing on the same physical partition.
Why wrong: 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.

Full breakdown with real-world context →

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.

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.

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 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.
Related concept
Read the scenario before looking for a memorised answer.
✗
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 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.

Common exam traps

Common exam trap: answer the scenario, not the keyword

The trap here is that candidates often 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.

Detailed technical explanation

How to think about this question

DynamoDB's partition allocation is based on the partition key's hash value; a single partition key value maps to exactly one physical partition, regardless of table capacity. By using a shard key (e.g., tenantId + '#' + shardId), each unique shard value maps to a different partition, allowing write throughput to scale linearly with the number of shards. The fan-out query pattern is a common design pattern for hot keys, and merging results by eventTimestamp ensures the application can still retrieve items in chronological order.

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 startup's cloud architect reviews their monthly bill and notices costs are higher than expected for a long-running batch job. Switching from on-demand instances to Reserved Instances — or using Spot/Preemptible VMs — can reduce compute costs by up to 72 %. Questions like this test whether you understand the tradeoffs between commitment, flexibility, and cost across cloud pricing models.

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.

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

Design Secure Architectures practice questions

Practise SAA-C03 questions linked to Design Secure Architectures.

Design Resilient Architectures practice questions

Practise SAA-C03 questions linked to Design Resilient Architectures.

Design High-Performing Architectures practice questions

Practise SAA-C03 questions linked to Design High-Performing Architectures.

Design Cost-Optimized Architectures practice questions

Practise SAA-C03 questions linked to Design Cost-Optimized Architectures.

SAA-C03 VPC practice questions

Practise SAA-C03 questions linked to SAA-C03 VPC.

SAA-C03 S3 lifecycle policy questions

Practise SAA-C03 questions linked to SAA-C03 S3 lifecycle policy questions.

SAA-C03 RDS Multi-AZ questions

Practise SAA-C03 questions linked to SAA-C03 RDS Multi-AZ questions.

SAA-C03 IAM policy practice questions

Practise SAA-C03 questions linked to SAA-C03 IAM policy.

SAA-C03 Route 53 failover questions

Practise SAA-C03 questions linked to SAA-C03 Route 53 failover questions.

SAA-C03 CloudFront practice questions

Practise SAA-C03 questions linked to SAA-C03 CloudFront.

SAA-C03 NAT gateway questions

Practise SAA-C03 questions linked to SAA-C03 NAT gateway questions.

SAA-C03 VPC endpoint questions

Practise SAA-C03 questions linked to SAA-C03 VPC endpoint questions.

Practice this exam

Start a free SAA-C03 practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

10 questions 20 questions 30 questions 50 questions Timed 30

SAA-C03 practice-test guide →Study guide →Browse all practice tests

FAQ

Questions learners often ask

What does this SAA-C03 question test?

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: 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. — 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.

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.

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 →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

3 more ways this is tested on SAA-C03

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. 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?

hard

✓ A.Add a sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards.
B.Enable DynamoDB Streams so the table can process writes more quickly.
C.Switch the table to on-demand capacity mode and keep the same key design.
D.Add a global secondary index on eventTime and query the index instead of the base table.

Why A: 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.

Variation 2. 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 3. 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.

Keep practising

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.

Loading comments…

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.