DBS-C01 Workload-Specific Database Design Practice Question
A gaming company uses Amazon DynamoDB as the primary data store for player profiles and game state. The application experiences sudden spikes in traffic during new game launches, causing throttling on write requests. The current table has on-demand capacity mode. The table's partition key is 'player_id' (high cardinality). The read/write patterns are evenly distributed. Despite on-demand mode, throttling occurs because the per-partition throughput limit is being reached. The company wants to eliminate throttling without changing the partition key. Which solution should be recommended?
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
✓
Enable DynamoDB adaptive capacity and implement write sharding using a random suffix.
On-demand capacity mode already scales automatically, but per-partition throughput limits can still be reached if a single partition receives too many writes. Adaptive capacity (enabled by default) helps by dynamically adjusting per-partition throughput based on traffic patterns. However, if a specific partition key value experiences hot-spotting, write sharding—adding a random suffix to the partition key—further distributes writes across multiple partitions, increasing overall write capacity. Option A (DAX) caches reads, not writes. Option B (auto scaling with provisioned) does not solve per-partition limits; it adjusts table-level capacity. Option D (provisioned with increased WCU) also addresses table-level capacity, not per-partition limits.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Implement Amazon DynamoDB Accelerator (DAX) to offload read traffic.
Why it's wrong here
DAX does not help with write throttling.
- ✗
Use DynamoDB auto scaling with provisioned capacity.
Why it's wrong here
Auto scaling does not overcome per-partition limits.
- ✓
Enable DynamoDB adaptive capacity and implement write sharding using a random suffix.
Why this is correct
Adaptive capacity helps distribute load; write sharding further spreads writes across partitions.
- ✗
Switch to provisioned capacity mode and increase write capacity units.
Why it's wrong here
Per-partition limit still applies.
Go deeper
Related to this question
About these practice questions
This DBS-C01 question is part of Courseiva's 1,663-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 →
Same concept, more angles
1 more way this is tested on DBS-C01
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 company uses Amazon DynamoDB to store user session data for a web application. The table has a partition key of 'user_id' and no sort key. Each item is about 5 KB. The application performs frequent GetItem and UpdateItem operations. Recently, the application has been experiencing higher than expected latency and some throttling. The table's read and write capacity are set to on-demand mode. The CloudWatch metrics show that the ConsumedWriteCapacityUnits are well below the provisioned limits (if they were provisioned), but there are occasional ThrottledWriteEvents. The application team also notices that the throttling occurs for specific users. What is the most likely cause and solution?
medium- A.Create a global secondary index with a different partition key for the hot users.
- B.Add a sort key to the table to improve data distribution.
- ✓ C.Implement write sharding by appending a random suffix to the partition key for high-traffic users.
- D.Switch to provisioned capacity mode and increase the write capacity units significantly.
Why C: Implement write sharding by appending a random suffix to the partition key for high-traffic users. In DynamoDB on-demand mode, each partition can handle up to 3000 read request units or 1000 write request units per second. When a single partition key (user_id) receives high write traffic, that partition can become a hot partition and be throttled, even though overall consumption is within limits. Write sharding distributes the writes for a hot user across multiple partition key values by adding a random suffix to the user_id, thereby spreading the load across multiple partitions. Option A (creating a GSI) would not solve the base table write throttling because the base table writes still target the same partition. Option B (adding a sort key) does not change the partition key distribution; the partition key remains the same, so the hot partition issue persists. Option D (switching to provisioned capacity) would not automatically solve the hot partition; it would require proper partition design similarly.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DBS-C01 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 DBS-C01 exam.