C100DEV Indexing Practice Question
When creating an index on a large collection in a production environment, what is the primary advantage of using the 'background' option (for versions prior to 4.2) or the standard build process in 4.2+?
⚠ Common exam trap
Candidates often think index creation locks the entire database indefinitely, missing that modern MongoDB versions use optimized background builds to maintain high availability.
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
✓
It prevents the index build from blocking read and write operations on the collection.
In modern MongoDB (4.2+), all index builds use an optimized process that only holds an exclusive lock at the beginning and end of the operation, allowing the database to remain available for reads and writes. This prevents the index creation from blocking application traffic, which is essential for maintaining high availability and a good user experience during maintenance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The index build completes much faster than a foreground build.
Why it's wrong here
Actually, background or optimized index builds often take longer to complete than foreground builds because they yield to other database operations. The trade-off is not speed, but availability. A foreground build (in older versions) would lock the database and finish quickly but would prevent any other operations from occurring.
- ✗
The index will take up significantly less space on the disk.
Why it's wrong here
The method used to build the index (foreground vs. background) has no impact on the final size of the index on disk. Both methods result in the same B-tree structure. Disk space is determined by the number of documents, the values being indexed, and the compression settings of the storage engine.
- ✓
It prevents the index build from blocking read and write operations on the collection.
Why this is correct
The modern index build process is designed to be non-blocking. By allowing concurrent read and write operations, developers can create indexes on live production systems without causing downtime or significant latency spikes. This is a critical feature for managing large datasets that require new indexes as application requirements evolve.
- ✗
It automatically creates the index on all secondaries in a single transaction.
Why it's wrong here
While index builds are replicated to secondaries, they are not handled as a single distributed transaction. Each member of the replica set builds the index independently. The optimized build process ensures that secondaries can also continue to serve reads while the index is being constructed, maintaining the health of the entire cluster.
About these practice questions
One of 259 original C100DEV 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 C100DEV 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 C100DEV exam.