C100DEV CRUD Operations Practice Question
A developer queries the 'events' collection with db.events.find({ tags: { $in: ["sports", "music"] } }) and observes a COLLSCAN in explain output even though an index exists on the 'tags' array field. The collection holds a few hundred documents. Which explanation best accounts for the planner choosing a collection scan?
⚠ Common exam trap
The trap here is concluding the index is unusable or invalid from a COLLSCAN, when the planner may simply judge a full scan cheaper on a small collection.
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
✓
The query planner may prefer a collection scan when the collection is small, because the estimated cost of scanning is lower than the overhead of using a multikey index.
Query plan selection is cost-based. With a few hundred documents, the estimated cost of a full collection scan can be lower than the cost of using a multikey index plus document fetches, so the planner may reasonably choose COLLSCAN. As the collection grows, or with a more selective predicate, the same index is likely to be selected.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
COLLSCAN appears whenever a query returns more than one document, because index scans are limited to single-document lookups.
Why it's wrong here
Index scans routinely return many documents; there is no rule limiting them to single-document lookups. A range or membership predicate on an indexed field can match numerous entries and still use the index. This option invents a restriction that does not exist in MongoDB's execution engine.
- ✗
A multikey index cannot answer $in queries, so the planner ignores the tags index and falls back to a collection scan.
Why it's wrong here
Multikey indexes support $in predicates on array fields; the operator is evaluated against indexed array elements. The planner can use a multikey index for membership queries, so the claim that $in is unsupported is incorrect. The observed scan has a different cause related to plan cost, not operator compatibility.
- ✗
The index on 'tags' is invalid because arrays cannot be indexed directly, so it must be rebuilt as a compound index with _id first.
Why it's wrong here
MongoDB supports indexing array fields through multikey indexes, which create an index entry for each array element. Arrays can be indexed directly, so the index is not invalid. Requiring _id as a leading field is also unnecessary for an equality or membership filter on tags, making this explanation technically wrong.
- ✓
The query planner may prefer a collection scan when the collection is small, because the estimated cost of scanning is lower than the overhead of using a multikey index.
Why this is correct
The planner compares candidate plans by cost. For a very small collection, the estimated work of a full scan can be lower than traversing a multikey index and performing the associated fetches, so the planner legitimately selects COLLSCAN. The index is usable, but not chosen because it is not cheaper for this data size.
About these practice questions
Courseiva writes every C100DEV question from scratch — 259 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 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.