Select Two (Multi-Select) Questions

A shopping cart collection where items are added and removed constantly.

Why it fails: Shopping carts represent highly dynamic data that must always be accurate. Using the Subset Pattern here would create synchronization issues between the embedded subset and the total cart contents. A single document containing all cart items is usually preferred unless the cart size reaches extreme, unusual limits.

A product catalog where you need to filter by over 100 different categories.

Why it fails: Filtering across categories is a search problem, not a document size management problem. The Subset Pattern does not help with filtering performance across large datasets. Instead, you should use proper indexing strategies like multikey indexes or text indexes to handle categorical filtering for a product catalog effectively.

An audit log collection where every action must be stored for compliance.

Why it fails: Audit logs are usually append-only and do not typically benefit from the Subset Pattern. Because audit logs must maintain a complete historical record, you cannot simply subset the data. Storing these in a separate collection or using time-series collections is the standard approach for managing high-volume log data.

A blog post containing a list of comments that grows indefinitely.

Why it fails: Indefinitely growing lists lead to unbounded arrays, which eventually violate the 16MB document limit. This scenario is a classic example of when to use Referencing, where comments are stored in a separate collection linked by the parent document ID to ensure long-term scalability and document integrity.

A product catalog with millions of items linked to various categories.

Why it fails: In a many-to-many scenario, embedding would cause massive data duplication. If a category is renamed, you would need to update every single product document, leading to massive write amplification. Referencing is the superior choice here to maintain data consistency and reduce the overall storage footprint of the database.

A sensor data stream that stores millions of readings per hour.

Why it fails: Storing millions of sensor readings in a single document is physically impossible due to the 16MB limit. This requires high-frequency writes and time-series data modeling, which necessitates storing readings in separate documents or collections to ensure the database can handle the continuous volume of incoming sensor metrics.

Documents are stored in a human-readable JSON format on disk.

Why it fails: MongoDB stores documents in BSON (Binary JSON), a binary-encoded format that is more efficient for storage, traversal, and encoding than plain JSON. While BSON is JSON-like, it includes additional data types and is not human-readable on disk. This binary format enables faster parsing and supports data types not available in JSON.

Field names in a document can contain the null character.

Why it fails: BSON field names cannot contain the null character (\0) because it is used as a string terminator in the BSON specification. Allowing null characters would break parsing. Additionally, field names should not start with a dollar sign ($) in most contexts, as it is reserved for operators. Thus, this statement is incorrect.

Documents in the same collection must have the same set of fields.

Why it fails: MongoDB collections are schema-flexible; documents within a collection can have different fields. This flexibility allows for evolving data models without migrations. Requiring identical fields would contradict MongoDB's document model, which is designed to accommodate polymorphic data. Therefore, this statement is inaccurate.

Increase the transaction lifetime limit beyond 60 seconds to avoid all retries.

Why it fails: The transaction lifetime limit cannot be increased arbitrarily; it is a server-side cap. Changing it would not eliminate transient errors such as write conflicts or network issues. The scenario requires correct retry handling, not avoidance of retries, so this is not a valid practice.

Set the readConcern to 'snapshot' on every individual operation inside the transaction.

Why it fails: Read concern 'snapshot' is set at the transaction level, not per operation, and it is the default for transactions. Setting it on individual operations is invalid or ignored. It is not a retry mechanism and does not address transient errors or unknown commit results.

Disable write concern to make commits faster and reduce retries.

Why it fails: Write concern does not control transient error labels, and disabling durability is unsafe. It could increase the chance of unacknowledged writes and does not provide retry semantics. The driver still needs to inspect error labels and retry the transaction or commit as appropriate.

Use the Bucket Pattern to group products by category into buckets of 100 documents.

Why it fails: The Bucket Pattern is designed for time-series data or high-volume streams to reduce document count and index size, not for storing heterogeneous product data. Grouping products into buckets would complicate queries that need to filter on individual product attributes and would not provide efficient indexing for those attributes. It is not suitable for this scenario.

Embed all possible category-specific attributes in every product document, using null for missing attributes.

Why it fails: Embedding all possible attributes in every document wastes storage and creates sparse indexes that are inefficient. It also requires schema changes whenever a new attribute is introduced, reducing flexibility. This approach contradicts the goal of a flexible schema and can lead to large documents and poor query performance due to many unused fields.

Create a separate collection for each product category with its own schema and indexes.

Why it fails: Creating separate collections per category leads to a proliferation of collections and complicates application logic, especially when querying across categories. It also makes it difficult to maintain a unified product catalog. While it allows tailored indexes, it sacrifices the flexibility and simplicity of a single collection, which is a core strength of MongoDB. This approach is generally not recommended for this use case.

The cursor loads all matching documents into client memory immediately when find is called.

Why it fails: find does not eagerly load all matches. The driver retrieves documents in batches on demand, which is why a cursor can iterate millions of documents without exhausting client memory. Only conversion methods such as list() or to_list() load everything into memory at once.

The cursor returns documents in an order guaranteed by the storage engine, so no explicit sort is needed.

Why it fails: Without an explicit sort, MongoDB does not guarantee result order; documents may be returned in natural order, which can change with updates and index choices. Relying on natural order produces nondeterministic results. Applications that need a specific order must call sort() on the cursor.

The cursor is invalidated and re-executed automatically whenever the underlying collection is modified by another client.

Why it fails: Cursors are not re-executed on writes by other clients. A cursor represents a snapshot of query results as they are fetched in batches, and concurrent writes are generally not reflected in an already-open cursor. There is no automatic invalidation and re-execution mechanism for ordinary find cursors.

Store each message as its own document in the conversations collection using a message-specific discriminator field.

Why it fails: Mixing messages and conversation documents in one collection with a discriminator would make conversation-level queries scan past many message documents unless carefully indexed, and it complicates the natural one-to-many relationship. It also provides no inherent benefit over a dedicated messages collection, and the discriminator adds overhead without solving the growth or recent-message access requirements.

Embed messages in the conversation document and rely on the 16MB limit to naturally cap growth.

Why it fails: Relying on the 16MB limit as a cap is not a design decision; it is a failure mode. Once the embedded array approaches the limit, writes to that conversation begin to fail, and the application has no clean way to continue appending messages. This option neither preserves full history nor guarantees fast access to recent messages.

Store all messages in a single capped collection so older messages are automatically overwritten.

Why it fails: A capped collection would automatically discard older messages, directly violating the requirement to retain full history. While capped collections offer predictable performance for recent data, they are unsuitable when historical retention is mandatory. The application would lose messages permanently and could not satisfy audits or user requests to scroll back through a conversation.

Storing comments in a separate collection and referencing them from the post document reduces data duplication.

Why it fails: Referencing comments in a separate collection can reduce duplication if comments are shared, but in this scenario comments are specific to a post. However, the statement is not universally true; duplication may not be a primary concern. More importantly, it would require additional queries to retrieve comments, which is not optimal for the stated goal.

Embedding comments always improves write performance because it requires only a single document update.

Why it fails: Embedding comments can improve write performance for adding a comment because it is a single document update. However, the word 'always' makes this false; if the document grows large, updates may become slower due to document rewrites. Additionally, concurrent updates to the same document can cause contention. So this statement is not universally true.

Using the $slice operator in a query can limit the number of comments returned from an embedded array.

Why it fails: The $slice operator is used in projections to limit the number of array elements returned. While it can be used to return a subset of comments, it is not a statement about the document model design itself. The question asks for true statements regarding the document model, and this is a query technique, not a modeling consideration.

The unique compound index will also enforce uniqueness on `tenantId` alone, because the first field of a compound index is treated as a separate unique key.

Why it fails: A compound unique index enforces uniqueness only on the full combination of indexed fields. It does not enforce uniqueness on any prefix field alone. The first field `tenantId` can repeat across documents as long as the full `{ tenantId, username }` pair is unique. Treating prefixes as separate unique keys is not how MongoDB compound indexes work.

Creating the unique compound index requires the `collMod` command to be run first on the collection to enable unique constraints.

Why it fails: Unique constraints are enabled by creating an index with the `unique: true` option, not by running `collMod`. The `collMod` command is used to modify collection options such as TTL or validator settings, but it does not enable unique index behavior. The correct approach is `db.collection.createIndex({ tenantId: 1, username: 1 }, { unique: true })`.

A unique compound index automatically becomes a sparse index, so documents missing either `tenantId` or `username` are excluded from the uniqueness constraint.

Why it fails: Unique indexes are not sparse by default. A unique compound index includes documents even if some indexed fields are missing, treating missing fields as null. To exclude documents missing fields, the index must be explicitly created with the `sparse` option or a partial filter expression. Automatic sparseness does not occur.

Enable majority read concern on the order collection, which by itself guarantees that line-item updates are applied atomically.

Why it fails: Read concern controls the durability and isolation of reads on a replica set, but it does not create atomicity across separate documents. A majority read still sees whatever committed state exists, and if line items were updated in a separate operation, a partially applied state could be observed. Atomicity must come from modeling or transactions.

Store line items in a separate collection and rely on the order's '_id' reference to enforce atomic updates across documents.

Why it fails: A reference field is just data; it does not make writes across documents atomic. Updating the order and its items separately can leave them inconsistent if one write fails, and readers can observe partial states. Atomicity across documents requires a transaction or a change in modeling, not a reference.

Use a capped collection for line items so older writes are overwritten and consistency is maintained.

Why it fails: Capped collections impose insertion order and size limits and do not provide atomicity between an order and its items. Older documents are evicted, which is unsuitable for order history. This does not address the no-partial-read requirement and would risk data loss for line items.

The index can support a sort on price descending even if the query does not include any condition on category, because the index stores price in descending order when traversed in reverse.

Why it fails: This is incorrect because the index is not globally sorted by price. It is sorted by category first, then price. Without an equality condition on category, the index cannot provide a global sort on price descending. Scanning in reverse would yield a global order by category descending and price descending within each category, which is not the same as a global price descending sort. An in-memory sort would still be required.

The index can support a sort on price ascending if the query includes a range condition on category, such as { category: { $gt: 'A' } }.

Why it fails: This is false because a range condition on category does not fix the category to a single value. The index entries will be ordered by category first, and within each category by price. For a range of categories, the overall order is not by price globally. Therefore, the index cannot provide a sort on price ascending without an in-memory sort, even though it can be used for filtering on the category range.

The index can support a sort on price ascending even if the query does not include any condition on category.

Why it fails: This is false because without a condition on category, the index is ordered first by category and then by price within each category. A global sort on price would require merging results from multiple categories, which the index cannot provide directly. MongoDB would need an in-memory sort to order all documents by price across all categories, so the index alone cannot support the sort.

$limit

Why it fails: $limit restricts the number of documents passed to the next stage, but it does not contribute to grouping or calculating metrics. It could be used to limit the final result set, but it is not essential for the aggregation logic. The requirement does not specify a limit on the number of results, so $limit is not needed.

$project

Why it fails: $project can reshape documents by including or excluding fields or computing new ones, but it does not perform grouping or aggregation across documents. While it could be used after grouping to format the output, it is not essential for the core requirement of grouping and calculating metrics. The grouping and calculations are handled by $group, not $project.

$sort

Why it fails: $sort is used to order the results, which is required for the final output, but it is not essential for the grouping and calculation of metrics. The question asks for stages essential to achieve grouping and calculation, not the final sorting. While sorting is part of the overall requirement, it is not one of the two stages that perform the core aggregation and filtering.

A compound index on { country: 1, city: 1 } can support queries that filter on city alone, because MongoDB can use the index prefix from the right side.

Why it fails: MongoDB compound indexes support queries that use a prefix of the index fields, starting from the leftmost field. An index on { country: 1, city: 1 } can support queries on country alone or on both country and city, but not on city alone. To support city-only queries, you would need a separate index with city as the leading field. This statement incorrectly describes index prefix usage.

Creating a unique index on username will automatically create a unique index on email if both are specified in the same createIndex command using a compound key pattern.

Why it fails: A compound unique index on { username: 1, email: 1 } enforces uniqueness across the combination of username and email, not on each field individually. Two documents could have the same username with different emails, or the same email with different usernames, and still satisfy the compound uniqueness. Separate unique indexes are required to enforce uniqueness independently on each field.

Unique indexes in MongoDB enforce uniqueness across all fields in the document, not just the indexed field, to prevent duplicate documents.

Why it fails: Unique indexes enforce uniqueness only on the specified key pattern. They do not compare entire documents. For example, a unique index on email only prevents two documents from having the same email value; other fields can be identical. To prevent duplicate documents entirely, you would need a unique index on all fields or a different mechanism, which is not how unique indexes work.

A projection cannot exclude the _id field under any circumstance because it is mandatory in every query result.

Why it fails: _id is returned by default but is not mandatory. Setting _id: 0 removes it from results, which is common when returning aggregated or summarized data. Claiming it can never be excluded contradicts documented projection behaviour and the special-casing of _id in inclusion projections.

A projection may freely mix inclusion and exclusion fields as long as at least one field is set to 1 and at least one is set to 0.

Why it fails: Mixing inclusion and exclusion is not allowed except for _id. Attempting to include one field and exclude another, such as returning name but not age, produces an error. The server requires a consistent projection direction to avoid ambiguous intent.

Projection reduces the size of documents written to disk, so it permanently shrinks the stored data for the collection.

Why it fails: Projection affects only the documents returned by a query; it does not modify stored data. Documents remain unchanged on disk and in subsequent queries. Confusing read-time shaping with storage optimization is a frequent misunderstanding, since only updates or compaction change stored sizes.

Modeling order lines as a separate collection joined by orderId avoids any duplication and is always the best choice for order reads.

Why it fails: A separate order-lines collection still requires a join or a second query to assemble the order, and the claim that it is always best is false. It also does not by itself provide product names and prices, so it fails to optimize the specific query that retrieves an order with product details.

Storing only the product ObjectId in each order line and resolving names and prices at read time with $lookup keeps data fully normalized.

Why it fails: A $lookup resolves product details at read time, which guarantees fresh data but adds a join stage to every order retrieval. For a frequent order-rendering query this extra work is unnecessary when the needed fields are few and rarely change, so it is less optimal than embedding the small subset.

Duplicating the entire product document into each order line ensures the order always reflects product details.

Why it fails: Copying the full product document inflates each order and duplicates data that the order view never uses, such as long descriptions or images. This wastes storage, increases write cost on product updates, and goes beyond the small subset of fields the common query actually needs.

Place a `$project` stage that includes only `customerId` and `total` before the `$group` stage.

Why it fails: While a `$project` can reduce document size, adding it before `$group` does not replace the need for `$match` to filter by `total`. Without the `$match`, the pipeline would group all orders, not just those above 100, producing incorrect counts. It also does not leverage the index on `total` for filtering.

Place a `$sort` stage on `total` as the first stage to speed up the filter.

Why it fails: A `$sort` as the first stage forces the pipeline to sort the entire collection before filtering, which is expensive and does not improve the filter's performance. The index on `total` is already used by `$match` for range queries; sorting first adds overhead without benefit and may hit memory limits for large collections.

Place a `$limit` stage of 100 before the `$group` stage to reduce the number of documents processed.

Why it fails: A `$limit` before `$group` would arbitrarily restrict the input to 100 documents, producing incorrect counts because not all matching orders would be included. The scenario requires counting all orders with `total` greater than 100, so limiting early changes the result set and is not a valid optimization here.

Field order within a BSON document is not preserved, so queries that depend on field order will not work consistently.

Why it fails: BSON preserves field order as written. The order is significant for some operations, such as when comparing documents for equality or when using the $natural sort on a capped collection. Saying field order is not preserved is incorrect; the server maintains the order in which fields appear in the document.

BSON documents are stored as plain text JSON on disk to simplify backup and restore operations.

Why it fails: BSON is a binary format, not plain text JSON. It is designed for efficient parsing, traversal, and storage. Tools like mongodump and mongorestore work with BSON, and the mongo shell or mongosh displays documents in a JSON-like format for readability, but the on-disk representation is binary. This statement mischaracterizes how MongoDB stores data.

A MongoDB document can contain fields with duplicate names, and the server preserves both values when the document is stored.

Why it fails: BSON does not support duplicate field names in a document. If a document is inserted with duplicate keys, the driver or server may reject it or the last value may overwrite earlier ones, depending on context. The server does not preserve both values, so this statement is incorrect and could lead to data loss if a developer relies on it.

Store likes in a capped collection and read the count with countDocuments.

Why it fails: Capped collections are fixed-size and overwrite old entries, so they would silently drop likes once full, corrupting the count. They are intended for high-throughput logs, not authoritative like data. Counting a capped collection would also not reflect removed likes accurately.

Keep the full likes array on the post and add an index on the array field.

Why it fails: Multikey indexes accelerate queries against arrays but do not shrink the post document, so the unbounded array still risks the 16MB limit and large-document read cost. The scenario explicitly wants small post documents. Indexing the array addresses query speed, not document size.

Embed only the first 100 likes in the post and discard the rest.

Why it fails: Discarding likes loses data and makes the total count incorrect, which breaks the requirement to know how many likes a post has. Truncating the embedded array does not preserve the authoritative record. This trades correctness for size, which is not acceptable here.

Move the memory-intensive stage to the end of the pipeline.

Why it fails: Reordering stages does not reduce the volume of data a blocking stage must buffer, because the stage still processes whatever reaches it. If anything, deferring filtering lets more documents accumulate, making the memory problem worse rather than resolving it, and it offers no mechanism to spill to disk.

Disable the memory limit by restarting mongod with a larger wiredTigerCacheSizeGB value.

Why it fails: The wiredTiger cache controls storage-engine memory, not the aggregation pipeline's per-stage buffering threshold, so raising it does not lift the aggregation limit. This also requires a server restart and configuration change, both of which the scenario prohibits, making it doubly unsuitable.

Set the internalQueryMaxBlockingSortMemoryUsageBytes parameter to a larger value.

Why it fails: That parameter is a server-wide configuration change, which the scenario explicitly rules out. It also affects blocking sort memory globally rather than scoping the increase to this pipeline, so it violates the constraint even though it might technically permit a larger in-memory sort.

Dynamic mappings index fields whose names begin with an underscore, such as _id, by default.

Why it fails: Atlas Search dynamic mappings do not index the _id field by default, nor do they generally index fields starting with an underscore. The _id field is excluded from dynamic indexing to avoid unnecessary index bloat and because it is not typically a search target. If a developer needs to search on such a field, an explicit field mapping is required, which contradicts the assumption that dynamic mapping covers it automatically.

Atlas Search indexes can be created on any MongoDB deployment, including self-managed community servers.

Why it fails: Atlas Search is a feature of MongoDB Atlas and is not available on self-managed community servers or on-premises deployments. Attempting to create a search index outside Atlas is not supported by the tooling. The developer must be working within an Atlas cluster, and in some cases a dedicated search node tier, for Atlas Search indexes to be created and queried.

Setting dynamic to true requires also specifying analyzers for every string field in the collection.

Why it fails: Dynamic mapping does not require per-field analyzer declarations. When dynamic is true, Atlas Search applies default analyzers to string fields unless an explicit mapping overrides them. Requiring analyzers for every string field would defeat the purpose of dynamic mapping, which is to index fields automatically. The developer can still add custom analyzers, but they are optional, not mandatory, under a dynamic configuration.