C100DEV Indexing Practice Question
A developer is working with a MongoDB collection that stores user profiles. The collection has a unique index on `email` and a compound index on `{ lastName: 1, firstName: 1 }`. The developer needs to enforce that no two documents have the same combination of `tenantId` and `username`. Which TWO of the following statements are correct regarding the creation and behavior of a unique compound index for this requirement? (Choose two.)
⚠ Common exam trap
The trap here is assuming that a unique compound index makes each field individually unique or that it is automatically sparse, when it actually enforces uniqueness only on the full field combination.
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
✓
Creating a unique compound index on `{ tenantId: 1, username: 1 }` enforces uniqueness across the combination of both fields, not on each field individually.
A unique compound index on `{ tenantId: 1, username: 1 }` enforces uniqueness on the combination of both fields, not on either field alone. If existing duplicates are present, the index build will fail until they are resolved or excluded via a partial filter expression. The index is not sparse by default, does not enforce prefix uniqueness, and is created with `createIndex`, not `collMod`.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Creating a unique compound index on `{ tenantId: 1, username: 1 }` enforces uniqueness across the combination of both fields, not on each field individually.
Why this is correct
A unique compound index enforces that the combined values of the indexed fields are unique. It does not require each field to be unique on its own. In this scenario, the same `username` could appear under different `tenantId` values, and the same `tenantId` could appear with different `username` values, as long as the pair is unique.
- ✓
If the collection already contains duplicate `{ tenantId, username }` pairs, the unique index creation will fail unless duplicates are removed or the index is created with a partial filter expression.
Why this is correct
MongoDB will not create a unique index if existing documents violate the uniqueness constraint. The index build fails with a duplicate key error. To succeed, duplicates must be removed or the index must be defined with a partial filter expression that excludes documents that should not be subject to uniqueness. This is a critical pre-check before deployment.
- ✗
The unique compound index will also enforce uniqueness on `tenantId` alone, because the first field of a compound index is treated as a separate unique key.
Why it's wrong here
A compound unique index enforces uniqueness only on the full combination of indexed fields. It does not enforce uniqueness on any prefix field alone. The first field `tenantId` can repeat across documents as long as the full `{ tenantId, username }` pair is unique. Treating prefixes as separate unique keys is not how MongoDB compound indexes work.
- ✗
Creating the unique compound index requires the `collMod` command to be run first on the collection to enable unique constraints.
Why it's wrong here
Unique constraints are enabled by creating an index with the `unique: true` option, not by running `collMod`. The `collMod` command is used to modify collection options such as TTL or validator settings, but it does not enable unique index behavior. The correct approach is `db.collection.createIndex({ tenantId: 1, username: 1 }, { unique: true })`.
- ✗
A unique compound index automatically becomes a sparse index, so documents missing either `tenantId` or `username` are excluded from the uniqueness constraint.
Why it's wrong here
Unique indexes are not sparse by default. A unique compound index includes documents even if some indexed fields are missing, treating missing fields as null. To exclude documents missing fields, the index must be explicitly created with the `sparse` option or a partial filter expression. Automatic sparseness does not occur.
Visual reference
About these practice questions
This C100DEV question is part of Courseiva's 259-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 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.