Scenario practice questions

What happens if a document grows beyond the 16MB limit due to an 'Embedding' design choice?

Trap 1: MongoDB automatically moves the overflow data to a new document.

MongoDB does not automatically move data between documents. If a write operation would push a document over 16MB, the entire write fails. The application is responsible for managing document size and ensuring that the schema is designed to prevent documents from reaching the hard limit defined by the BSON specification.

Trap 2: The engine automatically compresses the document to fit.

While WiredTiger uses compression for disk storage, the BSON limit applies to the uncompressed document in memory. Compression is a storage-level feature that does not allow you to bypass the 16MB limit, which is defined at the logical document level, not the physical disk storage level. You cannot exceed this limit.

Trap 3: The document is split into two, and the original ID is shared.

MongoDB does not have a native 'split' mechanism for documents. Every document must have a unique _id. If you need to break up data, you must implement the application logic to move data to a separate collection or a different document structure; the database will not do this for you.

A
MongoDB automatically moves the overflow data to a new document.
Why it fails: MongoDB does not automatically move data between documents. If a write operation would push a document over 16MB, the entire write fails. The application is responsible for managing document size and ensuring that the schema is designed to prevent documents from reaching the hard limit defined by the BSON specification.
B
The write operation will fail.
The 16MB limit is a hard architectural constraint. If an update causes a document to exceed this size, the database rejects the change and returns an error. This is why careful schema modeling, such as using the Subset pattern or Referencing, is essential for datasets that grow over time.
C
The engine automatically compresses the document to fit.
Why it fails: While WiredTiger uses compression for disk storage, the BSON limit applies to the uncompressed document in memory. Compression is a storage-level feature that does not allow you to bypass the 16MB limit, which is defined at the logical document level, not the physical disk storage level. You cannot exceed this limit.
D
The document is split into two, and the original ID is shared.
Why it fails: MongoDB does not have a native 'split' mechanism for documents. Every document must have a unique _id. If you need to break up data, you must implement the application logic to move data to a separate collection or a different document structure; the database will not do this for you.

Question 2mediummulti select

Which TWO of the following scenarios are best suited for using the 'Subset Pattern' in MongoDB?

Trap 1: A shopping cart collection where items are added and removed…

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.

Trap 2: A product catalog where you need to filter by over 100 different…

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.

Trap 3: An audit log collection where every action must be stored for…

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
A blog post collection where you display the last 5 comments on the main view.
This is the classic use case for the Subset Pattern. By embedding only the most recent five comments in the post document, you ensure fast page loads. The remaining comments are stored in a separate collection and retrieved only when the user explicitly requests to see the full comment history.
B
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.
C
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.
D
A user profile collection where you store their 'top 3' favorite movies.
Storing a user's 'top 3' favorites within the profile document is an ideal use case. It allows the UI to display relevant information immediately upon loading the user document. The user's entire watch history can be stored elsewhere, keeping the primary profile document lean for quick lookups.
E
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.

Question 3mediummulti select

Which TWO of the following scenarios are optimal for using the Embedding pattern instead of Referencing?

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

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.

Trap 2: A product catalog with millions of items linked to various…

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.

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

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.

A
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.
B
A user document containing the user's primary shipping address.
Addresses have a strong 'contains' relationship with the user and are rarely queried independently of the user profile. Embedding them allows the application to retrieve both the user identity and their shipping information in a single read operation, significantly reducing application-side latency and database server load.
C
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.
D
A movie document embedding the names of its three main cast members.
The number of main cast members is small and relatively static, fitting the one-to-few pattern perfectly. Embedding them allows the application to display core movie details immediately without needing secondary lookups, providing a much faster user experience for common read operations on the movie details page.
E
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.

Question 4mediummultiple choice

What is the primary benefit of using $unionWith to combine data from two collections in a single pipeline?

Trap 1: It automatically joins documents based on a common ID.

Joining documents based on an ID is the role of the $lookup operator. $unionWith simply concatenates result sets from different collections, effectively acting like a SQL UNION ALL. It does not perform any matching or merging logic between the documents from the different collections involved.

Trap 2: It is faster than $match because it avoids indexes.

Avoiding indexes is never a performance benefit. $unionWith is a processing-heavy stage that requires careful planning. Claiming that avoiding indexes makes a stage faster is fundamentally incorrect, as indexes are the primary tool for achieving efficient data access in any database operation, including aggregation.

Trap 3: It replaces the need for a $group stage entirely.

$unionWith is for combining data sets; it has no grouping functionality. To summarize the combined data, you would still need to follow the $unionWith stage with a $group or other aggregation stages. They serve distinct, complementary purposes in the aggregation framework pipeline.

A
It automatically joins documents based on a common ID.
Why it fails: Joining documents based on an ID is the role of the $lookup operator. $unionWith simply concatenates result sets from different collections, effectively acting like a SQL UNION ALL. It does not perform any matching or merging logic between the documents from the different collections involved.
B
It allows querying multiple collections in one pipeline.
$unionWith provides a clean, single-pipeline approach to aggregate data from multiple collections. This reduces the latency of network round-trips from the application layer to the database, as the entire data consolidation process is executed on the server, resulting in faster and more efficient query execution.
C
It is faster than $match because it avoids indexes.
Why it fails: Avoiding indexes is never a performance benefit. $unionWith is a processing-heavy stage that requires careful planning. Claiming that avoiding indexes makes a stage faster is fundamentally incorrect, as indexes are the primary tool for achieving efficient data access in any database operation, including aggregation.
D
It replaces the need for a $group stage entirely.
Why it fails: $unionWith is for combining data sets; it has no grouping functionality. To summarize the combined data, you would still need to follow the $unionWith stage with a $group or other aggregation stages. They serve distinct, complementary purposes in the aggregation framework pipeline.

Question 5mediummultiple choice

A developer is working with a MongoDB collection that stores sensor readings. Each document contains a timestamp, sensor ID, and a nested object 'readings' with fields like 'temperature', 'humidity', and 'pressure'. The developer needs to query for all documents where the temperature reading exceeds 30 degrees Celsius. Which query correctly retrieves these documents?

Trap 1: db.sensors.find( { $where: "this.readings.temperature > 30" } )

The $where operator allows JavaScript expressions, but it is inefficient, deprecated for most use cases, and can pose security risks. While it could technically work, it is not the recommended or correct approach for querying nested fields. The standard dot notation is preferred.

Trap 2: db.sensors.find( { readings: { temperature: { $gt: 30 } } } )

This query attempts to match an exact subdocument where the 'readings' field equals an object with a 'temperature' field containing a query operator. In MongoDB, this would look for a document where 'readings' is exactly that object, not a nested field comparison. It is incorrect for querying a nested value.

Trap 3: db.sensors.find( { "readings": { $elemMatch: { temperature: { $gt:…

$elemMatch is used to match elements within an array, but 'readings' is a nested object, not an array. Using $elemMatch here would not correctly match the nested field and could lead to errors or no results. Thus, this query is incorrect for the given document structure.

A
db.sensors.find( { $where: "this.readings.temperature > 30" } )
Why it fails: The $where operator allows JavaScript expressions, but it is inefficient, deprecated for most use cases, and can pose security risks. While it could technically work, it is not the recommended or correct approach for querying nested fields. The standard dot notation is preferred.
B
db.sensors.find( { "readings.temperature": { $gt: 30 } } )
This query uses dot notation to access the nested field 'temperature' within the 'readings' object and applies the $gt operator to find values greater than 30. Dot notation is the correct way to query nested fields in MongoDB, making this the accurate query for the scenario.
C
db.sensors.find( { readings: { temperature: { $gt: 30 } } } )
Why it fails: This query attempts to match an exact subdocument where the 'readings' field equals an object with a 'temperature' field containing a query operator. In MongoDB, this would look for a document where 'readings' is exactly that object, not a nested field comparison. It is incorrect for querying a nested value.
D
db.sensors.find( { "readings": { $elemMatch: { temperature: { $gt: 30 } } } } )
Why it fails: $elemMatch is used to match elements within an array, but 'readings' is a nested object, not an array. Using $elemMatch here would not correctly match the nested field and could lead to errors or no results. Thus, this query is incorrect for the given document structure.

Question 6hardmultiple choice

A financial application stores transaction records in a MongoDB collection. Each transaction document includes a Decimal128 amount field and a Date field for the transaction time. A developer needs to query for transactions with amounts greater than 100.00 and times within the last 24 hours, and wants the queries to use indexes efficiently. Which statement about the document model and BSON types is correct for this scenario?

Trap 1: Range queries on Decimal128 fields are not supported; only equality…

MongoDB supports range queries on Decimal128 fields, and an index on such a field can be used for $gt, $gte, $lt, and $lte operations. Decimal128 values are compared numerically according to their decimal value. Restricting to equality only would be incorrect and would prevent efficient filtering, so this option misstates the capabilities of the index.

Trap 2: Decimal128 values are stored as strings, so range queries on the…

Decimal128 is a distinct BSON numeric type, not a string. It is stored in a binary format that preserves decimal precision, and MongoDB can index it and perform range comparisons directly. A text index would be inappropriate for numeric range queries and would not provide the expected behavior. This option incorrectly conflates Decimal128 with string storage.

Trap 3: Because Decimal128 and Date are both binary types, they cannot be…

Compound indexes can include fields of different BSON types, including Decimal128 and Date. There is no restriction that prevents combining them. The index key is built from the values in the specified fields, and the server can use the index for queries that filter on those fields. This statement is technically incorrect and would unnecessarily limit index design.

A
Range queries on Decimal128 fields are not supported; only equality queries can use an index on a Decimal128 field.
Why it fails: MongoDB supports range queries on Decimal128 fields, and an index on such a field can be used for $gt, $gte, $lt, and $lte operations. Decimal128 values are compared numerically according to their decimal value. Restricting to equality only would be incorrect and would prevent efficient filtering, so this option misstates the capabilities of the index.
B
Decimal128 values are stored as strings, so range queries on the amount field require a text index rather than a numeric index.
Why it fails: Decimal128 is a distinct BSON numeric type, not a string. It is stored in a binary format that preserves decimal precision, and MongoDB can index it and perform range comparisons directly. A text index would be inappropriate for numeric range queries and would not provide the expected behavior. This option incorrectly conflates Decimal128 with string storage.
C
Date values are stored as 64-bit integers representing milliseconds since the Unix epoch, and they can be indexed and compared with range operators.
BSON Date is a 64-bit signed integer counting milliseconds since the Unix epoch. It is a first-class type that supports comparison operators such as $gt and $lt, and it can be indexed. This allows efficient range queries on the transaction time field, which is exactly what the developer needs for finding transactions within the last 24 hours.
D
Because Decimal128 and Date are both binary types, they cannot be used together in a compound index on the same collection.
Why it fails: Compound indexes can include fields of different BSON types, including Decimal128 and Date. There is no restriction that prevents combining them. The index key is built from the values in the specified fields, and the server can use the index for queries that filter on those fields. This statement is technically incorrect and would unnecessarily limit index design.

Question 7mediummultiple choice

A developer is using the MongoDB Node.js driver to insert a document into a collection. The document includes a field `_id` set to a custom string value. After the insert, the developer checks the returned result and notices that the `insertedId` matches the custom string. What does this indicate about MongoDB's handling of the `_id` field?

Trap 1: The `_id` field is always an ObjectId and cannot be overridden with…

This is false because MongoDB allows the `_id` field to be of any BSON type other than an array. Developers can supply a custom string, integer, or even a subdocument as the `_id`. The ObjectId is the default, but it is not mandatory. The scenario demonstrates that a custom string was accepted, proving that overriding is possible.

Trap 2: The `_id` field is only unique per shard, not across the entire…

Uniqueness of the `_id` field is enforced across the entire collection, regardless of sharding. In a sharded cluster, the `_id` index is unique across all shards. MongoDB ensures that no two documents in the same collection can have the same `_id`. This is a core guarantee for the primary key, so this statement is incorrect.

Trap 3: MongoDB automatically indexes the `_id` field only if it is an…

MongoDB always creates a unique index on the `_id` field by default, regardless of its data type. Whether the `_id` is an ObjectId, string, or any other type, the index is automatically created. This ensures fast lookups by `_id` and enforces uniqueness. The index is not conditional on the type of the `_id` value.

A
MongoDB automatically generates an ObjectId for the `_id` field if it is not provided, but if provided, it must be unique within the collection.
In MongoDB, every document must have an `_id` field that acts as a primary key. If the `_id` is not specified, the driver generates an ObjectId. If a custom value is provided, it can be any BSON type except an array, but it must be unique within the collection. The insert succeeds only if the custom `_id` does not already exist, ensuring uniqueness.
B
The `_id` field is always an ObjectId and cannot be overridden with a custom value.
Why it fails: This is false because MongoDB allows the `_id` field to be of any BSON type other than an array. Developers can supply a custom string, integer, or even a subdocument as the `_id`. The ObjectId is the default, but it is not mandatory. The scenario demonstrates that a custom string was accepted, proving that overriding is possible.
C
The `_id` field is only unique per shard, not across the entire collection.
Why it fails: Uniqueness of the `_id` field is enforced across the entire collection, regardless of sharding. In a sharded cluster, the `_id` index is unique across all shards. MongoDB ensures that no two documents in the same collection can have the same `_id`. This is a core guarantee for the primary key, so this statement is incorrect.
D
MongoDB automatically indexes the `_id` field only if it is an ObjectId.
Why it fails: MongoDB always creates a unique index on the `_id` field by default, regardless of its data type. Whether the `_id` is an ObjectId, string, or any other type, the index is automatically created. This ensures fast lookups by `_id` and enforces uniqueness. The index is not conditional on the type of the `_id` value.

Question 8mediummulti select

A developer is designing a MongoDB collection to store blog posts. Each post document includes an array of comments, and each comment has fields such as 'author', 'text', and 'timestamp'. The developer wants to optimize for queries that retrieve posts along with their comments, and also wants to ensure that comments are stored efficiently. Which two of the following statements are true regarding the document model in this scenario? (Choose two.)

Trap 1: Storing comments in a separate collection and referencing them from…

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.

Trap 2: Embedding comments always improves write performance because it…

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.

Trap 3: Using the $slice operator in a query can limit the number of…

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.

A
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.
B
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.
C
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.
D
Embedding comments as an array within the post document allows retrieving the post and its comments in a single query.
Embedding comments in the post document stores all related data together, so a single query can fetch the post and all its comments. This is efficient for read operations that need the complete post with comments, and it leverages MongoDB's document model to avoid additional queries.
E
The 16MB document size limit may be a consideration if a post accumulates a very large number of comments.
MongoDB documents have a maximum size of 16MB. If a post has an extremely large number of comments, embedding them could cause the document to exceed this limit. Therefore, this is a valid consideration when deciding to embed comments, making this statement true.

Question 9mediummultiple choice

A developer is modeling a blog platform. Posts are read frequently, and each post has a small, bounded set of tags. The tags are always displayed with the post and are never queried independently across posts. The developer is deciding between embedding the tags as an array inside each post document versus storing them in a separate tags collection with references. Which design choice aligns with MongoDB document model guidance for this scenario?

Trap 1: Store tags both embedded in posts and in a separate collection,…

Duplicating tags in two places requires the application to keep both copies consistent, which adds write complexity and risks divergence. Since the scenario has no requirement for independent tag queries, the second copy provides no benefit. This violates the principle of modeling around actual access patterns rather than anticipating unused ones.

Trap 2: Store tags in a separate collection and use a $lookup aggregation…

$lookup is available for combining collections, but it is not the only mechanism and it introduces additional work per read. Using it for every post retrieval to fetch a small bounded tag list would add latency and complexity compared with embedding. The scenario does not require cross-post tag queries, so this approach does not match the access pattern.

Trap 3: Store tags in a separate collection and reference them from posts,…

Normalizing tags into a separate collection would require an additional lookup or $lookup stage to assemble each post for display. Because tags are bounded, always shown with the post, and never queried across posts independently, the extra collection adds join cost without benefit. The claim that normalization always improves read performance is not true in MongoDB's document model.

A
Embed the tags as an array within each post document, since they are bounded, accessed together with the post, and not queried independently.
Embedding is the recommended approach when the related data is bounded, is read together with the parent, and is not accessed on its own. An array of tags inside the post lets the application retrieve everything needed for rendering in a single read, avoiding a join. This matches the access pattern described and keeps the document model aligned with how the data is used.
B
Store tags both embedded in posts and in a separate collection, keeping them synchronized manually, to satisfy both read and write paths.
Why it fails: Duplicating tags in two places requires the application to keep both copies consistent, which adds write complexity and risks divergence. Since the scenario has no requirement for independent tag queries, the second copy provides no benefit. This violates the principle of modeling around actual access patterns rather than anticipating unused ones.
C
Store tags in a separate collection and use a $lookup aggregation in every read, because aggregation pipelines are the only way to combine related data.
Why it fails: $lookup is available for combining collections, but it is not the only mechanism and it introduces additional work per read. Using it for every post retrieval to fetch a small bounded tag list would add latency and complexity compared with embedding. The scenario does not require cross-post tag queries, so this approach does not match the access pattern.
D
Store tags in a separate collection and reference them from posts, because normalization always reduces duplication and improves read performance.
Why it fails: Normalizing tags into a separate collection would require an additional lookup or $lookup stage to assemble each post for display. Because tags are bounded, always shown with the post, and never queried across posts independently, the extra collection adds join cost without benefit. The claim that normalization always improves read performance is not true in MongoDB's document model.

Question 10easymultiple choice

A retail catalog team stores each product as a document. Products share core fields such as sku, name, and price, but electronics carry warrantyMonths while apparel carries sizeChart. The application queries all products uniformly by category and price. Which modeling approach best fits this requirement?

Trap 1: Store category-specific attributes in a separate attributes…

Moving attributes to a side collection adds a join for every product render and prevents indexing the varying fields for direct filtering. Since the attributes are read together with the product and are bounded in number, the join is pure overhead. It also complicates writes, which must now update two collections atomically or accept inconsistency.

Trap 2: Normalize the schema by storing all category-specific fields in a…

Forcing every product to carry every possible attribute wastes storage and creates documents full of nulls or placeholders, which is a relational habit that does not suit MongoDB. It also makes adding a new category require touching all documents or the application's fixed key list, so it is less flexible than simply allowing optional fields.

Trap 3: Create a separate collection per product category so each…

Separate collections force the application to know which collection to query for each category and make cross-category queries such as price-range searches across all products require multiple round trips or a manual union. The scenario states products are queried uniformly, so splitting collections adds routing complexity without any compensating benefit.

A
Store category-specific attributes in a separate attributes collection and $lookup them when rendering each product.
Why it fails: Moving attributes to a side collection adds a join for every product render and prevents indexing the varying fields for direct filtering. Since the attributes are read together with the product and are bounded in number, the join is pure overhead. It also complicates writes, which must now update two collections atomically or accept inconsistency.
B
Normalize the schema by storing all category-specific fields in a shared subdocument with a fixed set of keys for every product.
Why it fails: Forcing every product to carry every possible attribute wastes storage and creates documents full of nulls or placeholders, which is a relational habit that does not suit MongoDB. It also makes adding a new category require touching all documents or the application's fixed key list, so it is less flexible than simply allowing optional fields.
C
Store all products in one collection and allow documents to carry category-specific fields alongside the shared fields.
Keeping one collection with shared core fields plus optional category-specific fields lets a single indexed query on category and price serve every product. MongoDB does not require uniform document shape, so the polymorphic documents coexist cleanly, and the application handles optional fields only where relevant. This matches the uniform query requirement with the least complexity.
D
Create a separate collection per product category so each collection has a uniform schema.
Why it fails: Separate collections force the application to know which collection to query for each category and make cross-category queries such as price-range searches across all products require multiple round trips or a manual union. The scenario states products are queried uniformly, so splitting collections adds routing complexity without any compensating benefit.

Question 11mediummulti select

You are designing indexes for a MongoDB collection that stores user profiles. The collection has a field 'email' that must be unique, and a field 'username' that is also unique. You also need to support queries that find users by a combination of 'country' and 'city'. Which TWO of the following statements are correct regarding index creation and behavior in this scenario? (Choose two.)

Trap 1: A compound index on { country: 1, city: 1 } can support queries…

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.

Trap 2: Creating a unique index on username will automatically create a…

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.

Trap 3: Unique indexes in MongoDB enforce uniqueness across all fields in…

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
Creating a unique index on email will prevent insertion of documents with duplicate email values, but will allow multiple documents with missing email field only if the index is sparse or partial.
A unique index enforces uniqueness on the indexed field, but by default it treats missing fields as null and allows only one document without the field. To allow multiple documents missing the email field while still enforcing uniqueness when present, you must create the index with the sparse option or a partial filter expression. This is a common requirement for optional unique fields.
B
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.
C
A compound index on { country: 1, city: 1 } can be used for a query that filters on both country and city, and also for a query that filters on country alone.
A compound index supports queries that use a prefix of its fields. With { country: 1, city: 1 }, the index can be used for queries filtering on country, or on both country and city. The leading field country is the prefix, so country-only queries can use the index efficiently. Queries on city alone cannot use it as a prefix, but that is not part of this statement.
D
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.
E
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.

Question 12hardmultiple choice

A banking application must atomically transfer funds between two account documents in the 'accounts' collection. The transfer decreases the balance of the source account and increases the balance of the destination account, and both changes must succeed or neither should be applied. The deployment is a replica set. Which approach guarantees this atomicity?

Trap 1: Embed both account balances in a single document and use updateOne…

A single-document update is atomic, but the scenario specifies two separate account documents. Embedding balances into one document changes the data model and is not appropriate for independent accounts that can grow unbounded and be accessed separately. It does not satisfy the requirement as stated without a redesign.

Trap 2: Perform two sequential updateOne calls, first on the source and…

Two separate update operations are not atomic as a unit. If the first succeeds and the second fails, the balances become inconsistent, with funds debited but never credited. Checking results after the fact cannot undo the applied change, so this approach does not meet the all-or-nothing requirement.

Trap 3: Use updateMany with a filter matching both account _id values and…

updateMany applies the same update document to every matching document, so it cannot debit one account and credit another by different amounts. It also does not provide a way to apply different operations to different documents. The atomicity guarantee of a single update does not translate into the required transfer logic.

A
Embed both account balances in a single document and use updateOne with $inc on both fields.
Why it fails: A single-document update is atomic, but the scenario specifies two separate account documents. Embedding balances into one document changes the data model and is not appropriate for independent accounts that can grow unbounded and be accessed separately. It does not satisfy the requirement as stated without a redesign.
B
Use a session and start a transaction with session.startTransaction(), update both accounts within the session, then commitTransaction().
Multi-document transactions in MongoDB provide atomicity across operations in the same session. By starting a transaction, performing both updates with the session, and committing, either all changes are applied or the transaction aborts and none are. This is the supported mechanism for atomic cross-document updates on a replica set.
C
Perform two sequential updateOne calls, first on the source and then on the destination, and check the result of each.
Why it fails: Two separate update operations are not atomic as a unit. If the first succeeds and the second fails, the balances become inconsistent, with funds debited but never credited. Checking results after the fact cannot undo the applied change, so this approach does not meet the all-or-nothing requirement.
D
Use updateMany with a filter matching both account _id values and apply $inc to the balance field.
Why it fails: updateMany applies the same update document to every matching document, so it cannot debit one account and credit another by different amounts. It also does not provide a way to apply different operations to different documents. The atomicity guarantee of a single update does not translate into the required transfer logic.

Question 13hardmulti select

A developer is configuring an Atlas Search index on a collection of product documents. The index definition uses a dynamic mapping. Which two statements accurately describe the behavior or configuration of Atlas Search indexes in this scenario? (Choose two.)

Trap 1: Dynamic mappings index fields whose names begin with an underscore,…

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.

Trap 2: Atlas Search indexes can be created on any MongoDB deployment,…

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.

Trap 3: Setting dynamic to true requires also specifying analyzers for…

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.

A
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.
B
Atlas Search indexes are stored in a separate search process and are updated asynchronously from the primary replica set.
Atlas Search uses a dedicated search process that maintains its own index separate from the MongoDB data files. Changes from the replica set are replicated to the search process and applied asynchronously, so there can be a brief delay between a write and its visibility in $search results. This architecture keeps search workloads isolated from the primary's storage engine while still reflecting changes through the oplog.
C
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.
D
A dynamic mapping automatically indexes all dynamically indexable field types in each document, including strings, numbers, and dates.
Dynamic mapping in Atlas Search inspects each document and indexes fields whose types are supported for dynamic indexing, such as strings, numbers, booleans, and dates. This removes the need to enumerate every field in the index definition. It is the default behavior when no explicit field mappings are provided, and it is why a newly created dynamic index can immediately support $search queries across many fields without further configuration.
E
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.

Question 14hardmultiple choice

A blog platform stores posts in the 'posts' collection. Each document has an array field 'comments' containing subdocuments with fields 'author' and 'text'. You need to add a new comment to the 'comments' array of a specific post identified by its '_id'. The new comment should be appended to the end of the array. Which update operation should you use?

Trap 1: db.posts.updateOne({ _id: postId }, { $set: { comments: { author:…

$set replaces the entire 'comments' field with the new subdocument, turning the array into a single object. This would destroy all existing comments. It does not append; it overwrites. This is incorrect and would lead to data loss.

Trap 2: db.posts.updateOne({ _id: postId }, { $addToSet: { comments: {…

$addToSet adds an element to an array only if it does not already exist. If the same comment (exact match) is already present, it will not add it. The requirement is to add a new comment regardless of duplicates, as comments can be repeated. $addToSet would prevent duplicate comments with identical content, which is not desired.

Trap 3: db.posts.updateOne({ _id: postId }, { $concat: { comments: {…

$concat is not a valid update operator in MongoDB. It is an aggregation operator used for string concatenation in the aggregation pipeline. Using it in an update would cause an error. The correct operator for appending to an array is $push.

A
db.posts.updateOne({ _id: postId }, { $set: { comments: { author: 'user1', text: 'Great post!' } } })
Why it fails: $set replaces the entire 'comments' field with the new subdocument, turning the array into a single object. This would destroy all existing comments. It does not append; it overwrites. This is incorrect and would lead to data loss.
B
db.posts.updateOne({ _id: postId }, { $push: { comments: { author: 'user1', text: 'Great post!' } } })
The $push operator appends a specified value to an array. Here, it adds the new comment subdocument to the 'comments' array. This is the correct and efficient way to add an element to an array without needing to read and rewrite the entire document. It works atomically.
C
db.posts.updateOne({ _id: postId }, { $addToSet: { comments: { author: 'user1', text: 'Great post!' } } })
Why it fails: $addToSet adds an element to an array only if it does not already exist. If the same comment (exact match) is already present, it will not add it. The requirement is to add a new comment regardless of duplicates, as comments can be repeated. $addToSet would prevent duplicate comments with identical content, which is not desired.
D
db.posts.updateOne({ _id: postId }, { $concat: { comments: { author: 'user1', text: 'Great post!' } } })
Why it fails: $concat is not a valid update operator in MongoDB. It is an aggregation operator used for string concatenation in the aggregation pipeline. Using it in an update would cause an error. The correct operator for appending to an array is $push.

Question 15mediummultiple choice

What is the purpose of the $accumulator stage in the aggregation framework?

Trap 1: To replace $group.

The $accumulator stage is an operator used within the $group stage, not a standalone replacement for $group itself. It provides the logic for the accumulation process, while the $group stage provides the framework for organizing the input documents into buckets based on a key.

Trap 2: To improve performance over native operators.

$accumulator is actually slower than native operators because it involves executing JavaScript within the aggregation engine. Native operators are implemented in C++ and are highly optimized; therefore, custom JavaScript code will almost always have higher latency and resource consumption than native-equivalent operations.

Trap 3: To perform joins across collections.

$accumulator is for aggregation logic, not for data correlation or joining. The $lookup stage is dedicated to joining data between collections. Mixing these two concepts is incorrect, as $accumulator operates on the data within a single document stream during grouping, not across separate collections.

A
To replace $group.
Why it fails: The $accumulator stage is an operator used within the $group stage, not a standalone replacement for $group itself. It provides the logic for the accumulation process, while the $group stage provides the framework for organizing the input documents into buckets based on a key.
B
To define custom aggregation logic.
$accumulator allows for complex, user-defined logic that goes beyond standard operators. By providing an init, accumulate, and merge function, you gain full control over how documents are processed and aggregated, enabling custom calculations that are not supported by standard MongoDB aggregation operators.
C
To improve performance over native operators.
Why it fails: $accumulator is actually slower than native operators because it involves executing JavaScript within the aggregation engine. Native operators are implemented in C++ and are highly optimized; therefore, custom JavaScript code will almost always have higher latency and resource consumption than native-equivalent operations.
D
To perform joins across collections.
Why it fails: $accumulator is for aggregation logic, not for data correlation or joining. The $lookup stage is dedicated to joining data between collections. Mixing these two concepts is incorrect, as $accumulator operates on the data within a single document stream during grouping, not across separate collections.

Question 16mediummultiple choice

A support ticketing system stores documents in the 'tickets' collection. An operator wants to add a new field 'priority' set to 'high' only for tickets whose 'status' is 'open' and that do not already have a 'priority' field. The update must not create any new documents and must not modify tickets that already have a 'priority' field. Which update operation should be used?

Trap 1: db.tickets.updateMany({ status: 'open' }, { $set: { priority:…

This updates all open tickets regardless of whether priority already exists, overwriting any existing priority value. The upsert: true option also risks creating a new ticket document if no open ticket matches, which violates the requirement that no new documents be created. The filter is too broad and the upsert is inappropriate here.

Trap 2: db.tickets.replaceOne({ status: 'open', priority: { $exists: false…

replaceOne replaces the entire matched document with the provided replacement document, which would discard all other fields such as ticket subject, description, and timestamps. It also only affects a single document, not all matching open tickets. This is destructive and does not meet the requirement to simply add a field to multiple documents.

Trap 3: db.tickets.updateMany({ status: 'open', priority: { $exists: false…

The $setOnInsert operator only applies when an upsert results in a new document being inserted. Since no upsert is specified, this update will match the correct tickets but apply no changes at all, leaving them without a priority field. The operator is intended for insert-time defaults, not for updating existing matched documents.

A
db.tickets.updateMany({ status: 'open' }, { $set: { priority: 'high' } }, { upsert: true })
Why it fails: This updates all open tickets regardless of whether priority already exists, overwriting any existing priority value. The upsert: true option also risks creating a new ticket document if no open ticket matches, which violates the requirement that no new documents be created. The filter is too broad and the upsert is inappropriate here.
B
db.tickets.replaceOne({ status: 'open', priority: { $exists: false } }, { status: 'open', priority: 'high' })
Why it fails: replaceOne replaces the entire matched document with the provided replacement document, which would discard all other fields such as ticket subject, description, and timestamps. It also only affects a single document, not all matching open tickets. This is destructive and does not meet the requirement to simply add a field to multiple documents.
C
db.tickets.updateMany({ status: 'open', priority: { $exists: false } }, { $set: { priority: 'high' } })
This operation uses updateMany with a filter that matches only open tickets lacking a priority field, and $set adds the field without inserting new documents. Because the filter includes $exists: false, tickets that already have priority are untouched, and updateMany never performs an upsert unless explicitly requested, so no new documents are created.
D
db.tickets.updateMany({ status: 'open', priority: { $exists: false } }, { $setOnInsert: { priority: 'high' } })
Why it fails: The $setOnInsert operator only applies when an upsert results in a new document being inserted. Since no upsert is specified, this update will match the correct tickets but apply no changes at all, leaving them without a priority field. The operator is intended for insert-time defaults, not for updating existing matched documents.