C100DEV Indexing Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a standard unique index on the email field

  Why it's wrong here

  A standard unique index treats a missing email as null and rejects the second document lacking the field, so absent values collide. It is tempting because plain unique indexes are the normal way to enforce one-of-a-kind values, and they work correctly when every document is guaranteed to contain the field.

• ✗

  Create a sparse index on the email field without uniqueness

  Why it's wrong here

  A sparse index omits documents that do not contain the indexed field from the index structure, but omitting the unique property fails to enforce the core business requirement that present email addresses must remain strictly unique.

• ✗

  Create a wildcard index on the email field

  Why it's wrong here

  A wildcard index indexes every field path, which cannot enforce uniqueness on email and still permits duplicate addresses. It is tempting because wildcard indexes genuinely serve ad-hoc queries over unpredictable field names, but uniqueness constraints require a single-field index with a partial filter.

• ✓

  Create a unique partial index with a filter expression requiring email to exist

  Why this is correct

  A partial index applies the uniqueness constraint only to documents matching its filter expression, so requiring the email field to exist excludes documents lacking it. This satisfies the constraint that missing-email documents must not trigger duplicate key violations.