C100DBA Server Administration Practice Question
You are monitoring a MongoDB replica set and notice that the replication lag on a secondary is increasing steadily. You suspect that the secondary is unable to keep up with the write load. Which administrative action should you take first to diagnose the issue?
⚠ Common exam trap
The trap here is jumping to corrective actions like restarting the secondary or resizing the oplog before confirming and understanding the replication lag.
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
✓
Check the output of rs.printSlaveReplicationInfo() to see the lag and the time of the last oplog entry.
The first step in diagnosing replication lag is to quantify it and check the secondary's progress. rs.printSlaveReplicationInfo() provides the lag in seconds and the timestamp of the last oplog entry applied, helping you understand the severity and whether the secondary is making progress. Other actions like restarting or resizing the oplog are premature without diagnosis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Check the output of rs.printSlaveReplicationInfo() to see the lag and the time of the last oplog entry.
Why this is correct
rs.printSlaveReplicationInfo() provides a quick summary of replication lag for each secondary, including how far behind the secondary is in seconds and the timestamp of its last oplog entry. This is the first step to confirm the lag and identify which secondary is affected. It helps determine if the lag is due to network, disk I/O, or other factors.
- ✗
Restart the secondary to see if the lag clears.
Why it's wrong here
Restarting the secondary is a disruptive action that should not be the first step. It may temporarily resolve issues but does not diagnose the root cause. It could also cause further lag if the secondary needs to resync. Diagnosis should begin with monitoring commands like rs.printSlaveReplicationInfo().
- ✗
Run db.currentOp() on the secondary to see long-running operations.
Why it's wrong here
db.currentOp() can show long-running operations on the secondary, but replication lag is typically caused by the secondary applying oplog entries, not by user queries. While it might reveal an issue, the first step should be to quantify the lag and check the oplog progress using rs.printSlaveReplicationInfo().
- ✗
Increase the oplog size on the primary to allow more time for the secondary to catch up.
Why it's wrong here
Increasing the oplog size does not address the secondary's inability to keep up; it only provides a larger window for the secondary to catch up if it falls behind. It does not diagnose or fix the underlying performance issue on the secondary. The first step should be to understand why the secondary is lagging.
About these practice questions
One of 222 original C100DBA 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 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.