C100DBA Sharding Practice Question
A collection has a 'status' field with only three possible values: 'active', 'pending', and 'closed'. Why is 'status' a poor choice for a shard key by itself?
⚠ Common exam trap
Candidates often incorrectly assume that low cardinality is beneficial because it simplifies query routing, failing to realize that it prevents the cluster from splitting data into many chunks.
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
✓
Low cardinality prevents the creation of many chunks.
A good shard key needs high cardinality to allow for a large number of chunks. If a shard key only has three possible values, the cluster can have at most three chunks for that collection. This limits the total number of shards that can participate in storing and processing the data, leading to scalability bottlenecks and imbalance.
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 field is not a unique identifier for the documents.
Why it's wrong here
Shard keys are not required to be unique identifiers. Many documents can share the same shard key value. The problem here is the lack of variety in those values, which prevents the database from splitting the data into enough chunks to distribute across a larger number of shards.
- ✓
Low cardinality prevents the creation of many chunks.
Why this is correct
With only three possible values, MongoDB can only create a very limited number of chunks. Even in a cluster with ten shards, only three shards would ever hold data for this collection, while the others remain empty. This effectively caps the horizontal scalability of the database to three nodes.
- ✗
The field type must be an ObjectID for performance reasons.
Why it's wrong here
There is no requirement that a shard key be an ObjectID. Any BSON type can be used as a shard key. The performance of a shard key depends on its cardinality and write pattern rather than its specific data type, provided the field is indexed and consistently present.
- ✗
The balancer cannot migrate chunks based on string values.
Why it's wrong here
The balancer is perfectly capable of migrating chunks regardless of the data type of the shard key, including strings. It operates on range boundaries defined by the BSON sort order. The issue is the limited number of ranges available for migration when the set of values is so small.
About these practice questions
This C100DBA question is part of Courseiva's 222-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 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.