DEA-C01 Data Ingestion and Transformation Practice Question
A company uses Kinesis Data Streams to ingest IoT data. The data volume varies, and occasionally the shard write throughput is exceeded, causing ProvisionedThroughputExceeded exceptions. The data engineer needs to handle these spikes without losing data. Which approach is most cost-effective and requires minimal code changes?
⚠ Common exam trap
Watch out — candidates often assume increasing shards (Option B) is the only way to handle throughput spikes, but the question emphasizes cost-effectiveness and minimal code changes, making Firehose's buffering and retry mechanism the optimal choice without over-provisioning.
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
✓
Use Kinesis Data Firehose as a consumer with retries and buffer settings
Kinesis Data Firehose is the most cost-effective solution because it can be configured as a consumer of the Kinesis Data Stream with built-in retry logic and buffer settings (e.g., buffer size up to 128 MB or buffer interval up to 900 seconds). This handles throughput spikes by buffering data and retrying failed writes without requiring custom code, and it scales automatically without the need to manage shard counts.
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 custom retry logic using the Kinesis Client Library with exponential backoff
Why it's wrong here
Implementing custom retry logic with exponential backoff fails this scenario because it does not address the fundamental issue of exceeded shard write throughput. Retrying only re-attempts sending data to an already overloaded shard, potentially delaying processing and risking data loss if client buffers fill before a successful write. This approach is, however, a critical best practice for handling transient network issues, temporary service unavailability, or intermittent rate limiting from other services, ensuring eventual data delivery without requiring changes to the stream's underlying capacity.
- ✗
Increase the number of shards to handle peak throughput
Why it's wrong here
This is costly and may not be necessary for sporadic spikes.
- ✓
Use Kinesis Data Firehose as a consumer with retries and buffer settings
Why this is correct
Firehose can buffer data and retry, handling spikes with minimal code changes.
- ✗
Send data to an SQS queue first, then have a Lambda function write to Kinesis
Why it's wrong here
This adds latency, cost, and complexity without clear benefit.
Go deeper
Related to this question
About these practice questions
One of 1,711 original DEA-C01 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DEA-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 DEA-C01 exam.