Why DynamoDB Auto Scaling Isn't Increasing Capacity
A company uses Amazon DynamoDB with auto scaling enabled. The application experiences increased latency during peak hours. The DynamoDB table has a read capacity of 10,000 RCU and write capacity of 5,000 WCU. The auto scaling target utilization is 70%. During peak hours, the consumed read capacity reaches 8,000 RCU, but auto scaling does not increase capacity. What is the most likely reason?
Quick Answer
The answer is that the auto scaling configuration has a maximum capacity setting that prevents scaling beyond a certain limit. Even though the consumed read capacity of 8,000 RCU represents 80% utilization against the provisioned 10,000 RCU—well above the 70% target—DynamoDB auto scaling will not increase capacity if the table’s maximum provisioned capacity has been set too low. This scenario tests your understanding that auto scaling operates within explicit upper and lower bounds; without a sufficient maximum, the service cannot scale out regardless of sustained demand. On the AWS Certified Database Specialty DBS-C01 exam, this is a common trap where candidates assume auto scaling will always respond to high utilization, forgetting that the maximum capacity acts as a hard ceiling. A key memory tip is “max before min”—always check the maximum capacity first when DynamoDB auto scaling is not scaling up, as it is the most frequent culprit for stalled scaling during peak loads.
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
✓
The auto scaling configuration has a maximum capacity that prevents scaling beyond a certain limit.
Auto scaling in DynamoDB adjusts capacity based on consumed capacity relative to provisioned capacity. With a target utilization of 70%, the expected consumed capacity for 10,000 RCU is 7,000 RCU. However, the actual consumed capacity is 8,000 RCU, which is 80% utilization, above the target. Auto scaling should normally increase capacity to bring utilization back to 70%. But if the auto scaling configuration has a maximum read capacity limit (e.g., 8,000 RCU), scaling cannot exceed that limit, explaining why capacity does not increase. Option A is incorrect because auto scaling can trigger even before throttling occurs. Option C is incorrect because auto scaling can increase both read and write capacity. Option D is incorrect because auto scaling scales based on sustained consumption above target utilization, not necessarily exceeding provisioned 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.
- ✗
The consumed capacity is still below the provisioned capacity, so no throttling occurs, and auto scaling does not trigger.
Why it's wrong here
Auto scaling is based on utilization, not just throttling.
- ✓
The auto scaling configuration has a maximum capacity that prevents scaling beyond a certain limit.
Why this is correct
If the maximum capacity is set to 10,000 RCU, auto scaling cannot increase further.
- ✗
Auto scaling for DynamoDB does not support increasing read capacity; it only decreases capacity.
Why it's wrong here
Auto scaling supports both increasing and decreasing capacity.
- ✗
Auto scaling only scales out when the consumed capacity exceeds the provisioned capacity.
Why it's wrong here
Auto scaling can scale out before reaching provisioned capacity when utilization exceeds the target.
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
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 uses Amazon DynamoDB with auto scaling enabled. During a sales event, the write capacity consumption increases, but the table does not scale up as expected, resulting in throttled requests. The table has read/write capacity mode set to 'Provisioned' with auto scaling configured. What should the team check first to troubleshoot the issue?
easy- ✓ A.Check the target utilization percentage in the auto scaling policy
- B.Verify that the auto scaling role has the necessary IAM permissions
- C.Check whether the table class is DynamoDB Standard-IA
- D.Check if a global secondary index (GSI) has its own write capacity that is throttling
Why A: The target utilization percentage in the auto scaling policy determines when scaling triggers. If set too high (e.g., 90%), the table may not scale until near full consumption, causing throttling during spikes. Option B is incorrect: IAM permissions for the auto scaling role are typically preconfigured and less likely to cause scaling failures—permission issues would appear in CloudTrail, not as a gradual throttling problem. Option C is incorrect: table class (Standard vs. Standard-IA) affects storage costs, not write capacity scaling behavior. Option D is incorrect: while a GSI can throttle if its write capacity is insufficient, the primary table's auto scaling is independent; the question states the table itself does not scale, so the GSI is not the first check.
Variation 2. A database team uses Amazon DynamoDB with auto scaling enabled. They observe frequent throttling on a table during peak hours. The table's read capacity is set to 5000 RCU with auto scaling range 3000-7000. The consumed read capacity graph shows spikes to 6000 RCU but throttling occurs at 5500. What is the most likely cause?
hard- A.Write capacity units are insufficient
- B.Auto scaling is disabled for the table
- C.The table has too many partitions
- ✓ D.Auto scaling cannot react quickly enough to sudden traffic spikes
Why D: Auto scaling uses a target utilization (default 70%) and cannot scale fast enough for sudden spikes. Option A is wrong because auto scaling is enabled. Option B is wrong because WCU are separate. Option C is wrong because partition count doesn't directly cause throttling if RCU is sufficient.
Variation 3. A company has an Amazon DynamoDB table with auto scaling enabled. During a traffic spike, the application experiences high write latencies. Which action should the company take to troubleshoot the latency issue?
easy- ✓ A.Monitor the ThrottledWriteEvents metric in CloudWatch.
- B.Switch the table to on-demand capacity mode.
- C.Disable auto scaling and manually increase write capacity.
- D.Increase the read capacity of the table.
Why A: ThrottledWriteEvents metric indicates write requests that were throttled due to exceeding provisioned capacity. If this metric spikes during traffic spikes, it suggests that auto scaling is not scaling fast enough, leading to high write latencies. Option B is incorrect because switching to on-demand is a remediation, not a troubleshooting step; it does not help identify the root cause. Option C is incorrect because disabling auto scaling and manually increasing capacity might solve the issue temporarily but is not a troubleshooting approach; it bypasses auto scaling logic. Option D is incorrect because read capacity does not affect write latencies.
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.