DEA-C01 Data Operations and Support Practice Question
A company uses AWS DMS to migrate data from an on-premises Oracle database to Amazon Aurora MySQL. The migration is successful, but the ongoing replication task is experiencing high latency. Which configuration change is most likely to reduce latency?
⚠ Common exam trap
The trap is reaching for task-level tuning parameters (batch size, timeout) when the root cause is instance capacity — candidates often assume configuration tweaks beat vertical scaling for latency.
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
✓
Increase the size of the DMS replication instance.
Ongoing replication latency in AWS DMS is most commonly caused by insufficient compute, memory, or I/O capacity on the replication instance, especially when CDC processing, transformations, or high transaction volumes are involved. Increasing the replication instance size provides more CPU, memory, and network throughput to process change streams faster. This is the standard first remediation for sustained CDC latency before tuning task-level parameters.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Increase the size of the DMS replication instance.
Why this is correct
Replication latency often stems from insufficient CPU, memory, or I/O on the replication instance. Upsizing it gives more resources to apply changes and process transactions, reducing the lag between source Oracle and target Aurora MySQL.
- ✗
Decrease the task's batch size and batch apply timeout.
Why it's wrong here
Reducing batch size and timeout shrinks each transaction commit, which lowers throughput and typically increases latency on a high-volume replication stream. Tuning batch parameters is tempting because it addresses memory pressure and apply errors, and it is correct when the target rejects large transactions, not when the bottleneck is change capture or network throughput.
- ✗
Change the target endpoint to Amazon S3.
Why it's wrong here
Amazon S3 is a target for data lake ingestion, not a relational endpoint, so switching targets abandons the Aurora MySQL destination and cannot reduce replication latency. S3 is tempting because it absorbs writes cheaply at scale, and it is the right target when landing raw change data for later transformation rather than replicating into Aurora.
- ✗
Enable Change Data Capture (CDC) from binary logs.
Why it's wrong here
CDC from binary logs is a MySQL source mechanism; the source here is Oracle, which supplies changes through LogMiner or Binary Reader, so this setting cannot be enabled for the task. It tempts administrators familiar with MySQL replication, and it would be correct if the source endpoint were MySQL or Aurora MySQL rather than on-premises Oracle.
Go deeper
Related to this question
About these practice questions
This DEA-C01 question is part of Courseiva's 1,321-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 →
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.