DynamoDB Hot Key Throttling Causes and Solutions
A company is using Amazon DynamoDB for a high-traffic application. The application is experiencing intermittent `ProvisionedThroughputExceededException` errors. The team has already increased the read and write capacity units multiple times but the errors persist. Which of the following is the MOST likely cause of the issue?
Quick Answer
The answer is a hot key or uneven partition access pattern causing throttling. Even when overall DynamoDB provisioned capacity appears sufficient, a single partition receiving a disproportionate share of traffic—a hot key—can exhaust that partition’s throughput, triggering ProvisionedThroughputExceededException errors despite multiple capacity increases. This scenario tests your understanding of DynamoDB’s internal partition architecture: each partition has a fixed throughput limit, and uneven access patterns bypass the global capacity allocation. On the AWS Certified Database Specialty DBS-C01 exam, this is a classic trap where candidates assume more RCUs/WCUs always solve throttling, but the real culprit is often a skewed workload. Remember the memory tip: “Hot key, cold table”—a single popular item can starve the rest of the table, so always inspect partition distribution before scaling capacity.
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
✓
A hot key or uneven partition access pattern is causing throttling
Hot keys or uneven partition access patterns can cause throttling even if overall provisioned capacity appears sufficient. Option A is wrong because DynamoDB Accelerator (DAX) is an in-memory cache that reduces read load, but it does not directly fix capacity exceeded errors; misconfiguration might cause cache misses but not ProvisionedThroughputExceededException. Option B is wrong because Global Tables replication does not cause throttling on the source table; conflicts are handled by last-writer-wins. Option C is wrong because increasing capacity units multiple times without resolving the underlying access pattern suggests the issue is not simply insufficient 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.
- ✗
DynamoDB Accelerator (DAX) is not properly configured
Why it's wrong here
DAX is an in-memory cache that reduces read load, but it does not directly fix capacity exceeded errors; misconfiguration might cause cache misses but not ProvisionedThroughputExceededException.
- ✗
The table is part of a DynamoDB Global Table and replication is causing conflicts
Why it's wrong here
Global Tables replication does not cause throttling on the source table; conflicts are handled by last-writer-wins.
- ✗
The provisioned capacity is not increased enough
Why it's wrong here
Increasing capacity units multiple times without resolving the underlying access pattern suggests the issue is not simply insufficient capacity.
- ✓
A hot key or uneven partition access pattern is causing throttling
Why this is correct
Hot keys or uneven partition access patterns can cause throttling even if overall provisioned capacity appears sufficient.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every DBS-C01 question from scratch — 1,663 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
3 more ways 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 is using Amazon DynamoDB for a session management application. The application is experiencing higher latency during peak hours. The DynamoDB table uses on-demand capacity. Which TWO steps should a database specialist take to diagnose the issue?
medium- A.Review the table's ReadCapacityUnits and WriteCapacityUnits to ensure they are sufficient.
- B.Examine the CloudWatch metric for UserErrors to identify client-side issues.
- ✓ C.Check the CloudWatch metric for ThrottledRequests to see if any requests are being throttled.
- D.Enable DynamoDB Streams to capture all write events for analysis.
- ✓ E.Analyze the PartitionKey metrics to detect if a single partition is receiving a disproportionate amount of traffic.
Why C: Checking ThrottledRequests helps identify if requests are being throttled, even with on-demand. Reviewing PartitionKey metrics helps detect hot partitions. ReadCapacityUnits and WriteCapacityUnits are not applicable for on-demand. Latency metrics show end-to-end performance but are less diagnostic.
Variation 2. A developer is troubleshooting an application that uses Amazon DynamoDB. The application sometimes receives ProvisionedThroughputExceededException errors. The table has on-demand capacity mode. The errors occur in short bursts. What is the most likely cause?
medium- A.The table has a low read/write capacity mode limit that needs to be increased.
- B.The global secondary index (GSI) has a different throughput limit.
- C.The table has reached the maximum provisioned throughput.
- ✓ D.The request rate exceeds the partition's throughput capacity in a short burst.
Why D: On-demand capacity mode can handle up to the table's previous peak traffic. However, if traffic spikes suddenly, DynamoDB might throttle. Option D is correct because on-demand has a limit on the maximum throughput per partition. Option A is wrong because indexes share the table's capacity. Option B is wrong because on-demand does not have provisioned limits. Option C is wrong because the table is on-demand, not provisioned.
Variation 3. A developer is troubleshooting an application that uses Amazon DynamoDB. The application is experiencing throttled requests (ProvisionedThroughputExceededException). Which CloudWatch metric should be monitored to troubleshoot this issue?
easy- ✓ A.ThrottledRequests
- B.SuccessfulRequestLatency
- C.UserErrors
- D.ConsumedWriteCapacityUnits
Why A: ThrottledRequests is a CloudWatch metric that directly counts the number of requests that were throttled due to exceeding provisioned throughput. For troubleshooting throttling issues, this metric provides immediate visibility into when throttling occurs. ConsumedWriteCapacityUnits (option D) shows capacity usage but does not directly indicate throttling; high consumption may lead to throttling but is not a direct measure. SuccessfulRequestLatency (option B) measures latency, not throttling, and UserErrors (option C) tracks client-side errors like invalid parameters, not capacity-related throttling.
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.