SAA-C03 Design High-Performing Architectures Practice Question
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?
⚠ Common exam trap
Watch out — 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.
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 sharding suffix to the partition key, such as tenantId#shardId, and query across the tenant's shards.
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.
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.
- ✗
Enable DynamoDB Streams so the table can process writes more quickly.
Why it's wrong here
DynamoDB Streams capture item-level changes after a write has already succeeded, making them a tool for event-driven workflows, triggers, or replication—not a mechanism to accelerate or absorb incoming write throughput. A hot partition arises because all requests for a given tenantId hash to the same partition, and that partition's write capacity is exhausted before the database even persists an item; enabling streams does nothing to redistribute that traffic or raise the partition's throughput limit. In fact, because stream records are produced by the same write path, a throttled write is not recorded in the stream at all, so the feature is entirely orthogonal to the latency and throttling problem described.
- ✗
Switch the table to on-demand capacity mode and keep the same key design.
Why it's wrong here
Switching to on-demand capacity mode automatically scales table-level throughput in response to total traffic, but that scaling applies across the entire table, not to an individual partition. DynamoDB still enforces a per-partition throughput ceiling (commonly 1000 WCU per partition for items up to 1 KB), and if the partition key design funnels all of tenant ACME's writes into a single partition, that partition will hit its ceiling and throttle requests even though the table as a whole has plenty of available capacity. A skewed key design is thus the root cause, and on-demand mode merely changes how the aggregate capacity is calculated—it cannot split the hot key's data across physical storage.
- ✗
Add a global secondary index on eventTime and query the index instead of the base table.
Why it's wrong here
A global secondary index on eventTime would use eventTime as the index partition key, meaning it would group items by time rather than by tenant, so querying that index would return events from every tenant in a given time range and force additional filtering to isolate a specific issuer's data. This both breaks the required tenant-scoped access pattern and introduces a different hot partition: any surge of writes at the same timestamp (or into the same time bucket) would concentrate on one index partition and throttle. Moreover, a GSI still stores items under a partition key that determines physical placement; without a well-distributed partition key such as tenantId as the sort key or a tenant+shard compound key, the index does not solve the underlying partition distribution problem.
Go deeper
Related to this question
About these practice questions
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.