DEA-C01 Data Ingestion and Transformation Practice Question
A company is using Amazon Kinesis Data Streams to ingest real-time clickstream data from a website. The data is consumed by an Amazon Kinesis Data Analytics for Apache Flink application that performs real-time analytics. The Flink application writes its results to an Amazon S3 bucket. The company has noticed that the Flink application is experiencing high checkpoint failure rates, causing delays. The CloudWatch metrics show that the checkpoint size is large and increasing. The data engineer needs to reduce the checkpoint size. Which action should the data engineer take?
⚠ Common exam trap
DEA-C01 often tests Flink checkpoint tuning. Candidates may think that reducing checkpoint interval or parallelism helps, but the trap is not knowing that incremental checkpointing is the key to reducing checkpoint size for large state.
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 incremental checkpointing in the Flink application to only write changes since the last checkpoint.
Enabling incremental checkpointing in the Flink application is the correct action because it only writes the changes since the last checkpoint, significantly reducing checkpoint size. This is especially effective when state is large and growing, as it avoids rewriting the entire state with each checkpoint.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Decrease the checkpoint interval to reduce the amount of state accumulated.
Why it's wrong here
Shortening the checkpoint interval makes checkpoints fire more often, but each still serialises the same accumulated keyed state, so size is unchanged and overhead rises. It is tempting because interval tuning is a common Flink remedy, and it would be correct when recovery-point frequency or end-to-end latency, not checkpoint size, is the failing metric.
- ✗
Reduce the parallelism of the Flink application.
Why it's wrong here
Lowering parallelism shrinks per-operator state only incidentally; the aggregate checkpoint size across subtasks stays driven by keyed state volume, and throughput per subtask worsens. It is tempting because parallelism tuning is a standard Flink lever, and it would be correct when the bottleneck is skewed load or operator backpressure rather than growing state.
- ✗
Increase the state time-to-live (TTL) configuration to retain state longer.
Why it's wrong here
Extending state TTL retains keyed entries for longer, so checkpoint size grows further rather than shrinking. It is tempting because TTL configuration is a genuine state-management control, and it would be correct when stale keys must be evicted sooner, or conversely when state is expiring prematurely and causing incorrect analytics results.
- ✓
Enable incremental checkpointing in the Flink application to only write changes since the last checkpoint.
Why this is correct
Incremental checkpointing writes only the state changes since the previous checkpoint rather than the full state, so checkpoint size stops growing with application state. This directly addresses the large and increasing checkpoint size causing the high failure rates.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 1,321 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 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 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.