C100DEV Data Modeling Practice Question
A social media platform stores each user's followers as an array of ObjectIds inside the user document. Power users can have millions of followers, and the application frequently needs to paginate through the follower list and display total counts. Which data modeling change best addresses the document growth and query performance concerns?
⚠ Common exam trap
The trap here is assuming the 16MB BSON limit can be configured or bypassed, when it is a fixed constraint that must be designed around.
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
✓
Store followers in a separate collection with one document per follower relationship, indexed on the followed user.
When an embedded array can grow without a realistic upper bound, the document risks hitting the 16MB BSON limit and queries become costly because large arrays must be scanned. Modeling the relationship as its own collection with a supporting index keeps documents small, enables efficient pagination, and allows accurate counts using standard aggregation or count operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Store followers in a separate collection with one document per follower relationship, indexed on the followed user.
Why this is correct
With millions of followers, embedding ObjectIds in a single user document risks exceeding the 16MB BSON limit and forces large array scans. A separate collection with an index on the followed user supports efficient pagination and counts via cursor iteration and countDocuments, keeping individual documents small and queryable.
- ✗
Convert the followers array into a GridFS bucket so that the follower list is chunked across multiple files.
Why it's wrong here
GridFS is designed for storing files larger than 16MB, splitting binary data into chunks. It is not intended for structured arrays of ObjectIds, cannot be indexed or queried like normal fields, and would make pagination and counting far more complex and slower than a dedicated collection.
- ✗
Add a $slice projection to every query so only the first 100 followers are ever returned to the application.
Why it's wrong here
Using $slice limits what is returned but does not stop the array from growing without bound in the document. The document can still hit the 16MB limit, writes to a huge array remain expensive, and accurate total follower counts cannot be produced from a sliced projection.
- ✗
Increase the document size limit by enabling the largeDocuments storage engine option on the replica set.
Why it's wrong here
MongoDB enforces a hard 16MB BSON document limit that cannot be raised through any storage engine option. There is no largeDocuments setting in mongod or replica set configuration. This approach is technically impossible and would not solve the query performance issue even if it existed.
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.