MongoDB Overview and Document Model practice questions

Documents can contain up to 64MB of data.

Why it fails: The maximum size for a single BSON document is 16MB. This constraint exists to prevent memory exhaustion and encourage developers to design better data models. If data exceeds this size, it should be distributed across multiple documents or stored in GridFS to maintain optimal database performance and integrity.

The order of fields within a document is always strictly preserved.

Why it fails: While MongoDB preserves the order of fields in most scenarios, it does not guarantee that the order will remain identical after updates or operations. Applications should never rely on field order for business logic. Relying on field order can lead to bugs and data inconsistencies during database maintenance cycles.

Field names can contain any character, including null bytes.

Why it fails: Field names have restrictions; for instance, they cannot contain the null character. Additionally, field names starting with a dollar sign ($) are reserved for internal operators. Violating these naming conventions will result in errors when attempting to insert or update documents, potentially breaking the application's data persistence logic.

Float32

Why it fails: BSON does not support a specific Float32 type. It uses a 64-bit floating point number (Double) for numerical values that require decimals. Using the correct types is vital for developers to ensure that the database can perform accurate arithmetic and efficient storage across various programming language drivers.

Pointer

Why it fails: There is no 'Pointer' data type in the BSON specification. References between documents are handled by storing the value of the '_id' field of the referenced document. Introducing non-existent types would break compatibility with the BSON format and prevent the MongoDB driver from serializing data correctly for the server.

A compound index on `{ publishedYear: 1, author: 1 }` can support queries that sort by `publishedYear` and filter on `author`.

Why it fails: This index orders by `publishedYear` first, then `author`. A query filtering on `author` and sorting by `publishedYear` would not be able to use the index efficiently for the sort, because the sort field is not the leading field. The index might still be used for the filter on `author` as a non-prefix, but it would require a full index scan and an in-memory sort, which is less efficient.

An index on `{ title: 1 }` can improve the performance of a query that uses `$text` search on the `title` field.

Why it fails: The `$text` operator requires a special text index, not a regular index. A standard single-field index on `title` cannot be used for `$text` queries. To support full-text search, you must create a text index using `db.collection.createIndex({ title: 'text' })`. Therefore, a regular index does not help with `$text` search performance.

A query that uses a regular expression on the `title` field can use an index on `title` only if the regex is case-insensitive.

Why it fails: Indexes on string fields can be used for regular expression queries only when the regex is anchored to the beginning of the string and is case-sensitive. Case-insensitive regexes, such as those with the `i` option, cannot efficiently use an index because they require scanning all index keys. Therefore, this statement is false; case-insensitivity actually prevents index usage.

Use a bucket pattern to group comments into fixed-size buckets within the post document.

Why it fails: The bucket pattern is useful for time-series data or grouping related data to reduce document count, but it still embeds comments within the post document, risking the 16 MB limit. It adds complexity without fully solving the unbounded growth issue. For thousands of comments, a separate collection is more scalable and simpler to manage.

Embed all comments as an array of subdocuments within the post document.

Why it fails: Embedding thousands of comments in a single document can exceed the 16 MB BSON document size limit and degrade performance due to large document size. While it provides fast reads of the post and comments together, it becomes unwieldy as comments grow. Frequent updates to add comments also require rewriting the entire document, increasing write amplification.

Reference comments from the post document using an array of comment IDs.

Why it fails: Storing an array of comment IDs in the post document still grows unbounded and can hit the document size limit. It also requires a second query to fetch the actual comments, adding latency. While it avoids embedding full comment data, the array of IDs itself becomes a scalability bottleneck for posts with thousands of comments.

Create a multikey index on { "lineItems": 1 }.

Why it fails: Indexing the entire lineItems array is possible but not useful for this query because the query conditions are on specific subfields. A multikey index on the array would index each entire line item document, but querying by productId and quantity would not use the index effectively. It would not optimize the query as well as a compound index on the subfields.

Create a single index on { "lineItems.productId": 1 }.

Why it fails: An index on productId alone can help filter orders by product, but it cannot efficiently filter by quantity. The query would still need to examine the array elements to check the quantity condition, potentially scanning many documents. A compound index including quantity is more efficient.

Create a single index on { "lineItems.quantity": 1 }.

Why it fails: An index on quantity alone would allow filtering by quantity, but without productId, it would not efficiently narrow down orders to those containing the specific product. The query would have to scan many orders with quantities > 5, regardless of product. This is inefficient.

The nested firmware object can be stored using the BSON Document type, allowing embedded fields to be queried with dot notation.

Why it fails: Embedded documents are indeed a BSON type, but the question asks which types are appropriate for the described fields, and the firmware object is already expected to be a document. Selecting it does not add new capability beyond what the schema already assumes, while the timestamp and array fields are the ones whose type choices need justification. The stem asks for two supported type choices, and the document option is redundant.

The numeric temperature value can be stored using the BSON Decimal128 type, which is a 16-byte floating-point format designed for exact decimal arithmetic.

Why it fails: Decimal128 is a real BSON type, but it is a 128-bit IEEE 754-2008 decimal floating-point value intended for monetary and other exact decimal calculations. Using it for a simple sensor temperature adds storage and processing overhead with no accuracy benefit, and the scenario does not require exact decimal semantics. It is therefore not a suitable native choice here.

The sensor identifier can be stored using the BSON Symbol type, which is deprecated but still accepted by modern MongoDB servers.

Why it fails: The Symbol type is deprecated and should not be used in new application schemas. Modern drivers and the server treat Symbol values as strings in many contexts, and relying on a deprecated type creates compatibility risk. A sensor identifier should be stored as a string or an ObjectId, so this option does not represent a recommended native type for the field.

The WiredTiger storage engine keeps all documents in memory, so nested field updates are applied to the in-memory copy and then lazily persisted.

Why it fails: WiredTiger uses a cache and checkpoints, but it does not keep all documents in memory; documents can be read from disk as needed. Lazy persistence of updates is also not how WiredTiger durably applies writes. This option mixes storage-engine concepts with the document model and does not explain the ability to update nested fields.

MongoDB stores each document as a BSON object, and the server can modify individual field values in place without rewriting the whole document.

Why it fails: BSON is a binary encoding, but MongoDB does not generally update individual fields in place. In-place updates are an optimization only in specific cases, such as $set on an existing field where the value size does not change. Adding or enlarging a field usually requires rewriting the document, so this is not the general behavior the scenario needs.

Each document is assigned a fixed schema at insert time, and updates to nested fields are validated against that schema before being applied.

Why it fails: MongoDB does not assign a fixed schema at insert time. Schema validation is optional and is configured per collection with $jsonSchema or query operators, not per document. Even when validation is enabled, it does not determine whether nested field updates are possible. This option describes a relational behavior that does not apply to the document model.

Normalize all attributes into a secondary 'attributes' collection linked by ProductID.

Why it fails: Normalization forces costly application-level joins or multiple database roundtrips to retrieve a complete product view. This approach undermines MongoDB's document-oriented design, which is specifically optimized to avoid complex joins by storing related data in a single, self-contained, and naturally hierarchical document structure.

Implement a fixed schema using a single large object containing every possible attribute as a null value.

Why it fails: Storing every possible attribute as a null value increases document size unnecessarily without adding value. MongoDB documents only store data that exists, which is more storage-efficient. A fixed schema approach ignores the primary benefits of MongoDB's flexible schema design and leads to bloated, inefficient storage footprints.

Serialize the entire attribute set into a single base64-encoded string field.

Why it fails: Encoding data into base64 strings makes it impossible for the MongoDB query engine to inspect, index, or filter the individual attributes. This forces the application to retrieve the entire document and decode it manually, negating MongoDB's server-side query processing power and limiting the ability to optimize database reads.

It is a text-based format identical to JSON but with limited character support.

Why it fails: BSON is a binary format, not a text-based one like JSON. It is specifically designed to be lightweight and traversable, which provides significant performance advantages over raw text parsing. JSON is purely for data interchange, whereas BSON is for efficient data storage and rapid manipulation within the database.

It supports a subset of data types compared to standard JSON.

Why it fails: BSON actually supports a wider range of data types than standard JSON, including specific types for dates, timestamps, and binary data. These additional types enable MongoDB to perform more sophisticated operations like time-series analysis and efficient binary storage, which are not possible with standard JSON formatting.

It requires manual conversion by the driver for every read operation.

Why it fails: Drivers handle the conversion between BSON and application objects automatically, not manually. This abstraction layer allows developers to work with native language objects while the database efficiently persists and retrieves data in the binary BSON format, hiding the complexities of the underlying physical storage representation from the developer.

The '_id' field is invalid.

Why it fails: The '_id' field shown is a valid ObjectId, which is the standard primary key in MongoDB. It conforms to the required 12-byte format, so the insertion would not fail due to this field. The issue lies elsewhere in the document structure, specifically with the reserved character usage in field names.

The field 'metadata' is a reserved keyword.

Why it fails: The term 'metadata' is not a reserved keyword in MongoDB. Users are free to use this term for field names in their documents. The failure of the document is strictly related to the use of reserved characters in the nested field, not due to the choice of the parent key name.

The value 'null' is not allowed for the 'last_login' field.

Why it fails: MongoDB fully supports the null data type. Storing a null value is perfectly acceptable and common for fields that have no value or are not yet set. The failure is not caused by the data type, but rather by the illegal naming convention used for the parent object's key.

Normalize the data by creating a separate collection for child documents.

Why it fails: Normalization is generally discouraged for related data that is frequently accessed together. Creating a separate collection requires multiple roundtrips or a $lookup aggregation stage, which is significantly slower than reading an embedded document. This approach should only be reserved for cases where child data is accessed independently.

Store the child data in a separate database to isolate the write load.

Why it fails: Spreading data across databases for a single one-to-many relationship creates unnecessary complexity for data management and integrity. It does not provide any performance benefit for read operations and makes atomic updates across the relationship nearly impossible to enforce, leading to eventual consistency issues and difficult application logic management.

Use a flat structure and duplicate parent information in every child document.

Why it fails: This approach introduces data redundancy and makes updates difficult. If the parent information changes, you would need to update every child document, risking data inconsistency. This is known as the 'denormalization trap' and should be avoided in favor of more structured embedding or referencing patterns depending on scale.

All documents must have a predefined structure determined by the first document inserted.

Why it fails: The first document does not define a schema for the collection. Each document is independent and can contain any fields as needed. This allows for diverse data representations within the same collection, which is exactly how MongoDB provides the flexibility required for modern, agile application development and data modeling.

The database automatically flattens all nested documents upon insertion.

Why it fails: MongoDB preserves the nested structure of documents. It does not flatten them because hierarchical structures are a primary feature of the document model. Flattening would lose the semantic relationship between nested fields and defeat the purpose of storing data in a natural, object-oriented format within the database system.

Schema enforcement can only be achieved by using third-party database proxies.

Why it fails: MongoDB provides native schema validation features that can be configured at the collection level using JSON Schema. This allows developers to enforce rules when necessary, without requiring external tools. This feature balances the need for flexibility with the requirement for data integrity in production environments when explicitly requested.

It eliminates the need for any indexing on the collection.

Why it fails: Indexing remains necessary for performance in any pattern, including the Bucket Pattern. The pattern is about structuring documents, not about replacing indexes. Proper indexing is still required to ensure that queries can locate specific buckets quickly, preventing full collection scans that degrade database performance during peak load.

It forces data normalization across multiple sharded clusters.

Why it fails: The Bucket Pattern is a denormalization strategy, not a normalization one. Its goal is to group data together for performance, not to spread it across clusters to enforce relational integrity. Normalization is usually detrimental to read performance in MongoDB, which is why grouping patterns are generally preferred.

It automatically migrates old data to archival storage systems.

Why it fails: The Bucket Pattern is an application-level modeling technique, not an automated system management feature. It does not perform data lifecycle management or archival. Data archival needs to be handled by separate mechanisms like TTL indexes or manual scripts, which operate independently of the data document structure itself.

The total number of documents in the collection.

Why it fails: The total number of documents is less important than the access pattern. Even in a collection with millions of documents, embedding is efficient if the application retrieves the data in a single request. Scalability is handled by sharding, not by avoiding embedding based on the total row count.

The memory limit of the database server.

Why it fails: While memory is always a factor, the decision to embed or reference is primarily about query efficiency. Modern hardware can handle large documents, provided the access patterns are optimized. Making design decisions solely based on server memory without considering access behavior will often lead to suboptimal application performance.

The complexity of the data's object-oriented relationships.

Why it fails: The document model should be designed based on application usage, not just the object relationships in the code. Mirroring class hierarchies directly can lead to poor performance. Developers must balance logical object structure with the actual performance requirements of the queries that the application will execute most frequently.

Normalize product attributes into multiple separate collections linked by manual application references to enforce rigid schema constraints.

Why it fails: Splitting attributes into separate collections with manual references reintroduces the rigid relational modelling MongoDB was chosen to avoid, requiring application joins per product. That pattern fits highly volatile many-to-many data with independent lifecycles, not a catalogue read as whole documents.

Serialize all product attributes into a single large binary blob string stored in a single generic text field inside the main document.

Why it fails: A binary blob hides every attribute from MongoDB's query engine, index building and projection, so size or specification filters cannot be served without application-side parsing. Blobs suit opaque payloads such as images or serialised archives, not catalogues queried by attribute.

Enforce a strict static schema across all product documents using server-side validation rules that require every possible attribute key to be present.

Why it fails: Requiring every possible attribute key to be present defeats the purpose of a flexible document model. Sparse attributes would have to be populated with null or empty placeholder values, wasting storage and complicating application logic.

db.posts.updateOne({ _id: postId }, { $set: { comments: [{ author: "Alice", text: "updated text" }] } })

Why it fails: This update replaces the entire comments array with a new array containing only one comment. All other comments on the post would be lost. The scenario requires modifying only a specific comment's text while preserving the rest of the array. Using a direct assignment to the comments field overwrites the whole array, which is destructive and not the intended operation.

db.posts.updateOne({ _id: postId }, { $set: { "comments.$.text": "updated text" } })

Why it fails: This uses the positional $ operator without an array filter in the query. The $ operator requires the query to include a condition that matches an element of the array. Without specifying which comment to match, MongoDB cannot determine the correct array index, so the operation fails or updates an unintended element. The query must include a filter on the comments array, such as { "comments.author": "Alice" }, for the positional operator to work correctly.

db.posts.updateOne({ _id: postId }, { $push: { comments: { author: "Alice", text: "updated text" } } })

Why it fails: $push adds a new comment subdocument to the comments array rather than modifying an existing one. This would create a duplicate or incorrect entry, not update the text of a specific comment. The scenario requires modifying an existing comment's text, not adding a new one. Using $push would result in an additional comment and fail to change the intended comment, leaving the original text unchanged.

Timestamp

Why it fails: The BSON Timestamp type is a special internal type used primarily for replication and sharding metadata, such as the oplog. It is not intended for application-level date and time storage. While it stores seconds and an increment, it lacks the millisecond precision and calendar semantics needed for typical user activity timestamps like a last login.

ObjectId

Why it fails: ObjectId is a 12-byte unique identifier typically used for the `_id` field. It embeds a timestamp but is not designed to represent arbitrary date and time values. Using ObjectId for `lastLogin` would make it difficult to query by date ranges and would not provide the expected date-specific operators, leading to confusion and potential errors in date handling.

String

Why it fails: Storing the date and time as a string would require a consistent, sortable format such as ISO 8601, and range queries would rely on lexicographic comparison, which is less efficient and error-prone. MongoDB provides a dedicated Date type for temporal data, so using a string here would forgo built-in date operators and proper indexing behavior for time-based queries.

{ timestamp: 1, sensorId: 1 }

Why it fails: This index orders primarily by timestamp, which means queries filtering on a specific sensorId would need to scan many index entries across all timestamps. For retrieving the latest reading for a given sensor, the query would have to examine all timestamps for that sensor, making it inefficient. The sensorId should come first to allow direct lookup.

{ value: 1, sensorId: 1 }

Why it fails: Indexing on value first does not help with queries that filter by sensorId and sort by timestamp. The query pattern requires efficient retrieval by sensor and time, not by value. This index would only be useful for queries that filter or sort on value, which is not the primary access pattern described.

{ sensorId: 1, value: 1 }

Why it fails: While sensorId first is good, the second key is value, not timestamp. The query needs to sort by timestamp to get the latest reading. This index would not provide the correct sort order, forcing an in-memory sort after fetching all readings for the sensor, which is inefficient for large datasets.

The use of strict schema validation rules enforced at the collection level.

Why it fails: Schema validation rules enforce a specific structure and would prevent documents with different sets of optional fields from being inserted. This contradicts the requirement to store varying fields without a predefined schema, so it is not the correct feature for this scenario.

The ability to store data in a fixed tabular format with rows and columns.

Why it fails: MongoDB does not store data in a fixed tabular format like relational databases. The document model uses BSON documents, which are more flexible. A tabular format would require a fixed schema and cannot accommodate varying fields easily, so this option is incorrect.

The requirement to define all possible fields in advance using a schema definition language.

Why it fails: MongoDB does not require defining all fields in advance; that is a characteristic of relational databases. The document model allows fields to be added dynamically. Requiring a predefined schema would contradict the need for flexible storage of optional fields, making this option incorrect.

Store warehouse locations in a separate collection and reference them by ObjectId from the product document.

Why it fails: Using references requires an additional query to fetch the warehouse data, which increases the number of queries needed to retrieve all information for a product. While referencing can be useful for large or independently accessed data, it does not meet the requirement to minimize queries in this scenario.

Normalize the data into multiple collections: products, warehouses, and inventory, with foreign key relationships.

Why it fails: Normalizing into multiple collections with foreign keys is a relational approach that would require joins or multiple queries to assemble the complete product view. MongoDB does not support joins natively in the same way, and this design would increase query complexity and count, contrary to the goal.

Store each warehouse location as a separate document in the same collection as products.

Why it fails: Storing warehouse locations as separate documents in the product collection would mix different entity types and still require multiple queries to gather all locations for a product. This approach lacks a clear relationship and does not ensure a single query retrieves all related data, making it inefficient.