DOP-C02 DynamoDB on-demand capacity Practice Question
A company uses AWS Lambda functions to process streaming data from Amazon Kinesis Data Streams. The Lambda function processes records in batches and writes the results to an Amazon DynamoDB table. Recently, the operations team noticed that the Lambda function is experiencing a high number of throttling errors (HTTP 400) when writing to DynamoDB. The DynamoDB table has on-demand capacity mode enabled. The CloudWatch metrics show that the DynamoDB consumed write capacity is well below the provisioned limits, but the Lambda function's error rate is increasing. The Lambda function's reserved concurrency is set to 100, and the function's timeout is 1 minute. The Kinesis stream has 10 shards. What is the MOST likely cause of the throttling errors?
⚠ Common exam trap
The trap is assuming that on-demand capacity eliminates throttling, but hot partitions can still cause throttling even when overall capacity is sufficient.
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 DynamoDB table is experiencing hot partitions due to uneven access patterns.
The most likely cause is hot partitions in the DynamoDB table due to uneven access patterns. Even with on-demand capacity, DynamoDB partitions have throughput limits, and if the Lambda function writes to a few partitions heavily, throttling occurs. The consumed write capacity being below provisioned limits indicates that the issue is not overall capacity but partition-level contention.
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 DynamoDB table is experiencing hot partitions due to uneven access patterns.
Why this is correct
DynamoDB on-demand capacity protects against table-level throttling but still enforces a per-partition limit of about 1,000 write capacity units. When access patterns are uneven, such as a single partition key receiving a disproportionate share of writes from the Kinesis stream, that partition hits its limit and throttles requests even though the overall table has plenty of capacity. Adaptive capacity can redistribute some of this load, but it is not instantaneous and does not fully prevent throttling during sharp spikes.
- ✗
The Lambda function's timeout is too short, causing the function to retry and overload DynamoDB.
Why it's wrong here
A Lambda timeout controls how long an invocation can run before it is terminated, not the rate at which invocations are attempted. If a Lambda function times out, the event source mapping may retry the batch, but this creates isolated retry traffic rather than sustained overload of a specific DynamoDB partition. The common timeout value of 1 minute is not directly linked to throttling; the actual issue is the distribution of writes across partition keys, not invocation duration.
- ✗
The Lambda function's reserved concurrency is too high, causing too many concurrent invocations.
Why it's wrong here
Reserved concurrency is a cap, not a throttle trigger. For a Kinesis stream with 10 shards, each shard processes one batch at a time, so the maximum number of concurrent Lambda invocations is approximately 10 (regardless of a reserved concurrency setting of 100), because the event source mapping polls one batch per shard. Setting reserved concurrency high does not force DynamoDB requests beyond its per-partition limits; actual throughput is dictated by shard count, batch size, and the partition keys being written.
- ✗
The Kinesis stream's batch size is too large, causing the Lambda function to write too many records at once.
Why it's wrong here
Batch size determines how many Kinesis records are passed to a single Lambda invocation, but it does not create hot partitions. If all records in a batch share the same partition key, DynamoDB throttling occurs regardless of whether the batch size is 10 or 10,000. Conversely, a well-distributed set of partition keys can write large batches without throttling. Therefore, the root cause lies in uneven key access patterns, not the volume of records per invocation.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Amazon Web Services exam blueprint
This DOP-C02 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 DOP-C02 exam.