- A
Keep tenantId as the partition key and rely on DynamoDB adaptive capacity to automatically remove all throttling.
Why wrong: 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.
- B
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.
This “write sharding” spreads a tenant’s traffic across multiple partition key values, which distributes the write load across multiple DynamoDB partitions (and thus multiple throughput slices). Reads for the last 10 minutes remain efficient because each shard still supports a sort-key range query on eventTime; the application merges results across shards.
- C
Change the sort key to eventTimeBucket (for example, eventTime rounded to 1-minute buckets) while keeping the partition key as tenantId.
Why wrong: 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.
- D
Enable DAX and use it for write operations so throttled writes are served from cache instead of reaching DynamoDB.
Why wrong: 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.
Quick Answer
The correct answer is to add a shard attribute to the partition key, making it tenantId#shard with a randomly selected shard from a fixed range, then query all shards for the last 10 minutes and merge results in the application. This resolves DynamoDB hot partition write throttling by distributing writes for a single noisy tenant across multiple physical partitions, a technique known as tenant salting. On the SAA-C03 exam, this scenario tests your understanding of adaptive capacity limits and the need to design partition keys for uniform access patterns, often appearing as a trap where candidates mistakenly choose to increase write capacity units instead of fixing the data model. The key insight is that DynamoDB’s 3000 RCU or 1000 WCU per partition ceiling cannot be overcome by scaling alone if one partition is overloaded. Remember the memory tip: “Salt the key, not the throughput” — when a hot tenant causes throttling, salting spreads the load horizontally while still allowing efficient time-range queries via parallel shard scans.
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.
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?
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.
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
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.
Option B is correct because it distributes writes for a hot tenant across multiple partitions by appending a random shard suffix to the tenantId partition key. This eliminates a single hot partition, allowing DynamoDB to scale write capacity horizontally. The application can then query all shards for the last 10 minutes and merge results, satisfying the retrieval requirement.
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.
- ✗
Keep tenantId as the partition key and rely on DynamoDB adaptive capacity to automatically remove all throttling.
Why it's wrong here
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.
- ✓
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.
Why this is correct
This “write sharding” spreads a tenant’s traffic across multiple partition key values, which distributes the write load across multiple DynamoDB partitions (and thus multiple throughput slices). Reads for the last 10 minutes remain efficient because each shard still supports a sort-key range query on eventTime; the application merges results across shards.
Clue confirmation
The clue word "best" in the question point toward this answer.
Related concept
Read the scenario before looking for a memorised answer.
- ✗
Change the sort key to eventTimeBucket (for example, eventTime rounded to 1-minute buckets) while keeping the partition key as tenantId.
Why it's wrong here
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.
Why it's wrong here
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.
Common exam traps
Common exam trap: answer the scenario, not the keyword
The trap here is that candidates assume adaptive capacity or caching (DAX) can solve write throttling, but neither addresses the root cause—a single partition exceeding its write capacity—which requires redistributing the partition key across multiple physical partitions.
Detailed technical explanation
How to think about this question
Under the hood, DynamoDB partitions data by partition key hash; a single partition can handle up to 1,000 write capacity units (WCU) and 3,000 read capacity units (RCU). By using a composite partition key like tenantId#shard with a random shard value (e.g., 0–9), writes are spread across up to 10 partitions, multiplying the effective write throughput for that tenant. The application must perform a scatter-gather query across all shards for the last 10 minutes, which is efficient because each shard query uses the sort key eventTime to filter recent data.
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 — study guide chapter
Learn the concepts, then practise the questions
- →
Design High-Performing Architectures practice questions
Targeted practice on this topic area only
- →
All SAA-C03 questions
1,040 questions across all exam domains
- →
SAA-C03 study guide
Full concept coverage aligned to exam objectives
- →
SAA-C03 practice test guide
How to use practice tests most effectively before exam day
Related practice questions
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.
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: 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. — Option B is correct because it distributes writes for a hot tenant across multiple partitions by appending a random shard suffix to the tenantId partition key. This eliminates a single hot partition, allowing DynamoDB to scale write capacity horizontally. The application can then query all shards for the last 10 minutes and merge results, satisfying the retrieval requirement.
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 →
Same concept, more angles
1 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. Your mobile app writes events to a single DynamoDB table with partition key = customerId and sort key = eventTime. During a promotional campaign, one tenant ("ACME") generates far more traffic than others. CloudWatch shows sustained throttling (ProvisionedThroughputExceeded) and elevated p99 latency only for that tenant. The workload pattern cannot be changed to a completely different schema, but you can change how items are partitioned. Which design change is most likely to reduce the hot-partition throttling while keeping efficient reads for ACME?
medium- A.Use the same partition key (customerId), but increase the table’s provisioned capacity for that tenant.
- ✓ B.Change the partition key to a salted key such as customerId + shard number, and include the eventTime ordering using the sort key.
- C.Switch to on-demand capacity mode and keep the partition key unchanged.
- D.Enable Global Tables so that reads are served from a nearby replica for ACME.
Why B: Option B is correct because salting the partition key by appending a shard number (e.g., customerId + random digit) distributes ACME's writes across multiple partitions, eliminating the hot partition. The sort key still preserves eventTime ordering, so queries for a specific customer can be parallelized across shards and merged client-side or via a composite sort key pattern, maintaining efficient reads.
Last reviewed: Jun 11, 2026
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.