C100DBA Replication Practice Question
A DBA is troubleshooting a replica set where the secondary is consistently lagging behind the primary by several hours. The DBA notices that the secondary's optime is far behind the primary's optime, and the secondary's oplog window is only 1 hour. The primary has a heavy write workload. Which action should the DBA take to reduce the replication lag and prevent the secondary from falling off the oplog?
⚠ Common exam trap
The trap here is focusing on oplog size as the primary solution, when the immediate cause of lag is the secondary's insufficient resources to apply writes; a larger oplog only delays the inevitable resync if lag persists.
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
✓
Scale the secondary vertically by adding more CPU, RAM, or faster disk I/O.
Replication lag is typically caused by the secondary's inability to apply oplog entries as quickly as the primary generates them. Improving the secondary's hardware resources—CPU, RAM, and especially disk I/O—increases its oplog application throughput, directly reducing lag. Increasing oplog size only buys time, and write concern does not affect replication speed.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Scale the secondary vertically by adding more CPU, RAM, or faster disk I/O.
Why this is correct
Replication lag often occurs when the secondary cannot apply oplog entries as fast as the primary generates them. Upgrading the secondary's hardware—especially faster disks and more CPU—can increase its oplog application rate, reducing lag. This addresses the underlying performance bottleneck and is the most direct way to improve replication throughput.
- ✗
Convert the secondary to an arbiter to reduce its workload.
Why it's wrong here
An arbiter does not store data and cannot replicate or serve reads. Converting a lagging secondary to an arbiter would remove a data-bearing member, reducing redundancy and read capacity. It does not help with replication lag because the arbiter does not apply oplog entries. This would worsen the situation by eliminating a replica.
- ✗
Increase the write concern on the primary to ensure the secondary acknowledges writes.
Why it's wrong here
Increasing write concern to require acknowledgment from the secondary would slow down the primary's write throughput and could increase lag if the secondary is already struggling. Write concern controls durability guarantees, not replication speed. It does not help the secondary apply oplog entries faster and may exacerbate the problem by adding latency.
- ✗
Increase the size of the oplog on the primary and secondaries.
Why it's wrong here
Increasing the oplog size extends the oplog window, which helps prevent the secondary from falling off the oplog and requiring a full resync. However, it does not address the root cause of the lag, which is likely insufficient write capacity or network throughput on the secondary. A larger oplog is a mitigation, not a solution to reduce lag.
About these practice questions
Courseiva writes every C100DBA question from scratch — 222 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 MongoDB exam blueprint
This C100DBA practice question is part of Courseiva's free MongoDB 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 C100DBA exam.