Sample questions
Mongodb Schema ModelingDifficulty 1
A user document embeds a preferences sub-document. One update changes preferences.theme and preferences.language together. What MongoDB guarantee makes this layout useful?
- aMongoDB automatically creates an index for every embedded field
- bMongoDB replicates each embedded field to a different shard
- cA write that updates multiple fields in one document is atomic at the document level✓
- dEmbedded sub-documents are exempt from the 16 MB BSON document limit
Explanation:MongoDB guarantees atomicity for a write operation on a single document, even when that operation changes multiple embedded fields. Keeping values that must change together in one document can therefore avoid a multi-document transaction. Embedding does not create indexes automatically, distribute fields across shards, or bypass the BSON size limit.
Mongodb Schema ModelingDifficulty 1
In MongoDB schema design, what does "referencing" mean?
- aStoring the full text of a document twice, once in each collection
- bUsing a
$lookup-free join performed entirely by the driver in application memory - cStoring another document's
_id as a field and fetching that document separately when needed✓ - dRenaming a field so it matches the name used in another collection
Explanation:Referencing keeps related data in a separate document/collection and links to it by storing that document's _id (or another identifying field), requiring a follow-up query (or $lookup) to fetch the related data — the opposite of embedding it inline.
Mongodb Schema ModelingDifficulty 2
A blogPost document needs to store a handful of comments that are almost always read together with the post and rarely queried on their own. Which approach fits best?
- aEmbed the comments as an array inside the blogPost document✓
- bStore each comment in its own top-level database with a dedicated connection
- cReference each comment by
_id in a separate comments collection and $lookup on every read - dStore comments only in an external full-text search engine, never in MongoDB
Explanation:A small, bounded, read-together-with-the-parent relationship (one-to-few) is the classic case for embedding: it avoids an extra query and keeps the data that's used together stored together. Referencing would add unnecessary lookups for data that's small and always read with the post.
Mongodb Schema ModelingDifficulty 2
A user document could theoretically embed all of that user's orders, but a single active user may place millions of orders over years. Which design is safer?
- aEmbed all orders in the user document; MongoDB will paginate the array transparently
- bEmbed only the user's 3 favorite orders and silently discard the rest
- cEmbed the orders but disable the document size limit for this one collection
- dReference the orders: store each order in its own collection with a
userId field pointing back to the user✓
Explanation:An unbounded, ever-growing one-to-many relationship should be modeled by referencing: each order lives in its own collection with a userId back-reference, so the user document stays small and orders can be queried/paginated normally. MongoDB does not auto-paginate embedded arrays, and the document size limit cannot be disabled.
Mongodb Schema ModelingDifficulty 1
What is the maximum size of a single BSON document in MongoDB?
- a1 MB, matching the default WiredTiger page size
- b16 MB, a fixed limit enforced regardless of storage engine✓
- c64 MB, but only for documents containing arrays
- dThere is no fixed limit; it depends on available RAM
Explanation:MongoDB enforces a hard 16 MB limit per BSON document, mainly to keep documents efficient to send over the wire and to discourage unbounded growth. This limit is fixed and does not depend on storage engine or available memory.
Mongodb Schema ModelingDifficulty 2
A developer keeps pushing new items into an embedded logs array on a single document, and eventually an update fails. What is the most likely cause?
- aMongoDB limits arrays to 100 elements by default
- bThe
logs field name is reserved and cannot be used inside an array - cThe update would make the document exceed the 16 MB BSON size limit✓
- dArrays cannot be updated after the document's first insert
Explanation:Continuously appending to an embedded array grows the whole document. MongoDB rejects the update that would make the document exceed the 16 MB BSON limit, so the oversized version is never stored successfully. This is a key risk of unbounded arrays.