MongoDB Certified Associate Developer Exam Questions

Correct answer: A
MongoDB’s documentation states plainly: “A document is the basic unit of data in MongoDB. MongoDB stores data records as BSON documents. BSON is a binary representation of JSON documents, though it contains more data types than JSON.” This is exactly why a MongoDB document can hold types like Date and Decimal128 that don’t exist in the JSON specification — BSON extends JSON’s type system while keeping the same nested, document-oriented shape.

Why other options are incorrect
B. MongoDB does not store documents as plain text files with a custom parser — it uses the BSON binary format specifically because it’s more space- and scan-efficient than parsing text.
C. MongoDB has no XML conversion step; its native, on-disk representation is BSON, not XML.
D. MongoDB documents support strictly more types than JSON (e.g., Date, ObjectId, Decimal128, Binary data), not the same or fewer types, and Date is a distinct BSON type — not a string.

Source: Documents

Correct answer: B
MongoDB documents the BSON Date type as: “BSON Date is a 64-bit integer that represents the number of milliseconds since the Unix epoch (Jan 1, 1970).” This is the type meant for application-level dates and times. By contrast, the docs explicitly warn about a different, internal-only type: “BSON has a special timestamp type for internal MongoDB use and is not associated with the regular Date type… The BSON timestamp type is for internal MongoDB use. For most cases, in application development, use the BSON date type.”

Why other options are incorrect
A. Timestamp is reserved for MongoDB’s own internal operations (such as the oplog) and is explicitly documented as not intended for storing application dates.
C. Regular Expression stores a pattern for matching strings; it has no relationship to storing a point in time.
D. MinKey is a special type used only for comparison purposes (it always sorts before every other value); it does not store real data such as a creation date.

Source: BSON Types

Correct answer: A, C, and D
MongoDB’s BSON Types reference lists the full set of supported types, including Decimal128 (“128-bit decimal-based floating-point number”), ObjectId (the default type auto-generated for _id), and Binary data (a byte array used for things like files, UUIDs, and vector data). All three appear explicitly in MongoDB’s official BSON type table.

Why other options are incorrect
B. Enum is not a BSON type at all — it’s a modeling concept some languages provide at the application layer, but MongoDB’s BSON type list has no Enum type; an enumerated value would typically be stored as a String or Int32.

Source: BSON Types

Correct answer: C
This is exactly the scenario MongoDB’s Polymorphic Pattern documentation describes: “Polymorphic data is data in a single collection that varies in document fields or data types… The polymorphic pattern stores different document shapes in the same collection, which improves performance for queries that need to access all [items] regardless of [type].” The docs add: “MongoDB uses a flexible data model, which means documents in a single collection do not need to have the same structure” — so the book, ebook, and audiobook documents can live together in products and still be queried as a single set.

Why other options are incorrect
A. Requiring identical fields across every document describes a rigid, relational-table style schema — the opposite of MongoDB’s documented flexible data model.
B. Splitting each shape into its own sub-collection defeats the purpose of the Polymorphic Pattern, which is specifically to query differently-shaped documents together in one collection.
D. Schema validation is an optional, opt-in feature; its presence or absence doesn’t determine whether documents of different shapes can exist in a collection — MongoDB allows this by default regardless of validation.

Source: Store Polymorphic Data

Correct answer: D
The Node.js driver documentation is explicit about the contract for each method: “Use the insertOne() method when you want to insert a single document,” while “Use the insertMany() method when you want to insert multiple documents.” Passing an array (and one of plain strings, not documents) to insertOne() is an improperly formed insert — the correct, properly formed command for multiple documents is insertMany([{...}, {...}]).

Why other options are incorrect
A. insertOne() and insertMany() have distinct, non-interchangeable signatures — insertOne() does not accept an array.
B. Collection names have their own (much less restrictive) rules; “inventory” is a perfectly valid collection name and isn’t the problem here.
C. Omitting _id is not an error — MongoDB automatically generates an ObjectId for _id when a document is inserted without one. The real problem is the malformed call itself.

Source: insertOne() — Node.js Driver

Correct answer: A
MongoDB documents replaceOne() as replacing “the first matching document in the collection that matches the filter, using the replacement document.” Unlike updateOne() with $set, the replacement document is not merged into the existing document — it wholesale replaces it (the _id is carried over automatically if omitted from the replacement, or must match if included). Since customer and total aren’t part of the replacement document, they’re gone after the operation.

Why other options are incorrect
B. That behavior describes $set, not replaceOne() — replaceOne() discards fields that aren’t part of the replacement document.
C. replaceOne() doesn’t null out fields; unlisted fields are removed entirely, not retained with a null value.
D. replaceOne() does not require every original field to be present in the replacement — it simply replaces the document with whatever is given, even if that means dropping fields.

Source: db.collection.replaceOne()

Correct answer: B
MongoDB’s documentation on the $set operator is explicit: “If the field does not exist, $set adds a new field with the specified value if the new field does not violate a type constraint.” $set only touches the field(s) named in its document — every other existing field, like name, is left exactly as it was.

Why other options are incorrect
A. $set does not require the field to pre-exist — it creates it if absent, which is exactly what happens here.
C. $set modifies specific fields in place; it does not replace the whole document the way replaceOne() does, so name is not discarded.
D. The documentation directly contradicts this — $set explicitly adds new fields when they don’t already exist.

Source: $set

Correct answer: C
MongoDB’s documentation describes this precisely: “If upsert: true and no documents match the filter, db.collection.updateOne() creates a new document based on the filter criteria and update modifications.” The official example shows exactly this pattern — updating (or inserting, if missing) a restaurant document by name with { upsert: true }, producing a result with upsertedId and upsertedCount: 1 when a new document had to be created.

Why other options are incorrect
A. Manually checking existence with a separate query before updating introduces an unnecessary round trip and a race condition; upsert: true handles this atomically in a single call.
B. Deleting and unconditionally re-inserting is destructive and unnecessary — it would also generate a new _id and discard any fields not explicitly provided, unlike a targeted upsert.
D. Upsert is opt-in — by default updateOne() does nothing if the filter matches no documents; the upsert option must be explicitly set to true.

Source: db.collection.updateOne()

Correct answer: D
MongoDB documents $inc as an operator that “increments a field by a specified value” and accepts both positive and negative amounts, and it can be combined with updateMany() to apply that increment to every document matching a filter. updateMany({ region: "west" }, { $inc: { "metrics.orders": 1 } }) is exactly the correctly formed expression: it targets every matching document and increases the existing value by 1 rather than overwriting it.

Why other options are incorrect
A. updateOne() only updates the first matching document, not every document with region: "west" — the scenario explicitly requires updating all of them.
B. Omitting an update operator like $inc and passing a plain field-value document is not a valid update expression for updateMany() — MongoDB requires an update operator to modify specific fields.
C. $set would overwrite metrics.orders to the literal value 1 on every matching document, rather than incrementing whatever value is already there.

Source: $inc

Correct answer: A
MongoDB’s documentation states that “when modifying a single document, both findAndModify() and the updateOne() method atomically update the document.” This atomicity means another concurrent operation on that same document cannot interleave partway through the find-then-modify sequence — the read and the write for that one document happen as a single, indivisible unit, which is exactly why findAndModify() is preferred over running a separate find() and update(), where “other updates may have modified the document between your update and the document retrieval.”

Why other options are incorrect
B. Atomicity is a built-in guarantee of findAndModify() for the single matching document — no manual locking is required.
C. Concurrent single-document operations are still atomic and isolated per document, not applied in some undefined merged order.
D. The atomicity guarantee is scoped to the single matched document, not the entire collection — other unrelated documents remain fully accessible during the operation.

Source: db.collection.findAndModify()

Correct answer: B
MongoDB documents deleteOne() as removing “a single document from a collection” (specifically the first matching document), while deleteMany() is the method for removing every document that matches a given filter. Since the requirement is to remove all documents where level: "debug", deleteMany({ level: "debug" }) is the properly formed command.

Why other options are incorrect
A. deleteOne() removes only the first matching document, not every document with level: "debug" — it would leave the rest untouched.
C. Passing { justOne: true } explicitly limits the operation to a single document, which is the opposite of what’s needed, and directly contradicts the “remove every matching document” requirement.
D. drop() removes an entire collection (and doesn’t accept a filter argument at all) — it’s far more destructive than deleting a filtered subset of documents.

Source: db.collection.deleteOne()

Correct answer: C
MongoDB’s query documentation describes reading documents “by querying for equality matches or other query operators.” The simplest and most direct equality match in MongoDB’s query language is { field: value } — here, { age: 30 } — which matches documents whose age field is exactly 30, no operator required.

Why other options are incorrect
A. $exists checks whether a field is present at all (true/false), not whether it equals a specific value — passing 30 to $exists doesn’t perform an equality comparison.
B. $eq is a valid operator, but it must be nested under the field name ({ age: { $eq: 30 } }), not used as a top-level key wrapping the whole filter document.
D. MongoDB filter values are compared directly against the field’s actual data type; "= 30" is a literal string and would never match a numeric age field of 30.

Source: Query Documents

Correct answer: D
MongoDB’s documentation on querying arrays explains: “To query if the array field contains at least one element with the specified value, use the filter { : } where is the element value (not an array).” So { tags: "red" } returns all documents where the tags array contains "red" as one of its elements, regardless of the array’s other contents or order.

Why other options are incorrect
A. { tags: ["red"] } is an equality match against the entire array — it only matches a document whose tags array is exactly ["red"] (single element, exact order), not one that merely contains "red" among other elements.
B. $size matches based on the number of elements in an array (and expects a number, not a string like "red"), not on whether a particular value is present.
C. "tags.length" is not valid MongoDB array-length syntax (that’s a JavaScript-array concept, not a BSON field path), so this filter wouldn’t reliably match anything.

Source: Query an Array

Correct answer: A
MongoDB’s comparison query operators reference defines $gt as matching “values greater than a specified value” and $lte as matching “values less than or equal to a specified value.” Combining them on the same field — { price: { $gt: 50, $lte: 200 } } — correctly expresses “greater than 50 AND less than or equal to 200.”

Why other options are incorrect
B. $in/$nin test membership against a list of discrete values, not a continuous numeric range.
C. $exists/$type check field presence and BSON type respectively — neither compares numeric magnitude.
D. $elemMatch/$all are array-matching operators; price in this scenario is a plain numeric field, not an array.

Source: Comparison Query Operators

Correct answer: B
MongoDB documents $in as an operator that “selects the documents where the value of a field equals any value in the specified array.” { rated: { $in: ["G", "TV-G"] } } returns every document whose rated field matches at least one of the listed values — exactly the “either G or TV-G” requirement.

Why other options are incorrect
A. { rated: ["G", "TV-G"] } is an equality match against an entire array value, not an “is one of these values” test — it would only match a document whose rated field is literally the array ["G", "TV-G"].
C. $all is used to test that an array field contains all of the listed values simultaneously; it’s designed for array fields, not for matching one of several possible scalar values.
D. $and is a logical operator that joins separate query clauses, not a way to list multiple acceptable values for a single field — this isn’t valid syntax for that purpose.

Source: $in

Correct answer: C
MongoDB documents $elemMatch as an operator that “matches documents that contain an array field with at least one element that matches all the specified query criteria.” Using db.scores.find({ results: { $elemMatch: { $gte: 80, $lt: 85 } } }) correctly requires a single array element to satisfy both bounds simultaneously — matching this document because 82 alone meets both conditions.

Why other options are incorrect
A. $or combines separate top-level query clauses; without $elemMatch, separate $gte/$lt conditions on an array field can each be satisfied by different array elements, which isn’t the same requirement as one element satisfying both.
B. $exists only tests whether a field is present, not the numeric value of any array element.
D. $type tests a field’s BSON type, not the specific values contained within an array.

Source: $elemMatch

Correct answer: A, B, and D
MongoDB’s logical operators reference defines: $and — “Joins query clauses with a logical AND and returns documents that match the conditions of all clauses”; $or — “Joins query clauses with a logical OR and returns all documents that match at least one clause”; and $nor — “Joins query clauses with a logical NOR and returns all documents that fail to match all clauses.” All three take an array of query clauses to combine.

Why other options are incorrect
C. $not is also a logical operator, but the documentation describes it differently: it “inverts the effect of a query predicate and returns documents that do not match the query predicate” — it wraps and negates a single expression rather than joining multiple separate query clauses together.

Source: Logical Query Operators

Correct answer: D
MongoDB’s documentation on limit() specifically warns: “If using limit() with sort(), be sure to include at least one field in your sort that contains unique values, before passing results to limit(). Sorting on fields that contain duplicate values may return an inconsistent sort order for those duplicate fields over multiple executions… The easiest way to guarantee sort consistency is to include the _id field in your sort query.” Adding _id: 1 as a tiebreaker after createdAt: -1 guarantees a stable, repeatable order even when timestamps collide.

Why other options are incorrect
A. limit() should be applied together with sort() as part of building the cursor before iterating; more importantly, this option still lacks a unique tiebreaker field, so ties in createdAt can be returned inconsistently across runs.
B. Sorting only by createdAt with no unique tiebreaker is exactly the inconsistency the documentation warns about when multiple documents share the same timestamp.
C. limit is not a filter field — passing { limit: 10 } inside find()’s query document does nothing to bound the result set; limit() must be called as its own cursor method.

Source: cursor.limit()

Correct answer: A
MongoDB’s documentation is explicit: “A projection cannot contain both include and exclude specifications, with the exception of the _id field: In projections that explicitly include fields, the _id field is the only field that you can explicitly exclude.” Since name: 1 and email: 1 are inclusions and password: 0 is an exclusion on a non-_id field, this projection is invalid and MongoDB will reject it.

Why other options are incorrect
B. MongoDB does not silently resolve a mixed inclusion/exclusion projection — it’s an invalid projection document and the query fails rather than falling back to including everything.
C. Projections absolutely can exclude fields — an exclusion-only projection (e.g., { password: 0 }) is perfectly valid; the issue here is mixing inclusion and exclusion, not exclusion itself.
D. There’s no fixed two-field limit on projections; the restriction is about not combining inclusion and exclusion styles, not about field count.

Source: db.collection.find()

Correct answer: B
MongoDB documents toArray() directly for this purpose: “In mongosh, use the toArray() method to iterate the cursor and return the documents in an array,” further noting that “the toArray() method loads all documents returned by the cursor into RAM and exhausts the cursor.” This is precisely the “single in-memory array” behavior the scenario asks for (as opposed to forEach() or a for...of loop, which process documents one at a time without necessarily materializing a full array).

Why other options are incorrect
A. explain() returns information about the query plan MongoDB chose, not the matching documents themselves.
C. count() (or countDocuments()) returns a number representing how many documents match, not the documents themselves.
D. close() terminates the cursor’s server-side resources; it does not retrieve or return any documents.

Source: Iterate a Cursor

Correct answer: C
MongoDB’s documentation states that countDocuments() “returns an integer for the number of documents that match the query” and, unlike the older count() method, “does not use the metadata to return the count. Instead, it performs an aggregation of the document to return an accurate count, even after an unclean shutdown or in the presence of orphaned documents in a sharded cluster.” This makes it the correct choice when accuracy under those conditions matters, and it accepts a query filter like { status: "pending" }.

Why other options are incorrect
A. Loading every matching document into an array just to read its length works but is wasteful and doesn’t scale — it pulls full documents across the wire purely to count them, when countDocuments() does this server-side and efficiently.
B. estimatedDocumentCount() does not accept a query filter — it returns an estimate of the entire collection’s document count using collection metadata, not a scoped, guaranteed-accurate count for a filtered subset.
D. getIndexes() returns information about a collection’s indexes; it has no relationship to counting documents.

Source: db.collection.countDocuments()

Correct answer: D
Atlas documentation describes a MongoDB Search index as: “a data structure that maps documents from your Atlas cluster to the terms that are extracted from those documents. MongoDB Search indexes enable efficient full-text searches of your database with MongoDB Search queries.” It further explains these indexes “using the Atlas UI or one of our supported clients,” including mongosh, the Atlas CLI, Compass, and MongoDB drivers (via createSearchIndex()). Without a Search index defined on the target fields, $search queries have nothing to query against.

Why other options are incorrect
A. A capped collection is a fixed-size collection type used for things like logs; it has no relationship to enabling full-text search.
B. The Atlas Data API is a separate HTTPS-based way to access Atlas data; it does not enable or replace the need for a Search index.
C. Zone sharding controls the geographic/physical placement of sharded data; it’s unrelated to enabling full-text search on specific fields.

Source: Create a MongoDB Search Index

Correct answer: A
MongoDB Atlas documentation describes $search as an aggregation stage that “conducts full-text searches and returns an ordered list of documents along with additional search metadata. Use $search to retrieve matching documents with or without facets.” The documentation frames it as the entry point into a MongoDB Search aggregation pipeline, used at the start of the pipeline before any subsequent shaping stages like $project or $limit.

Why other options are incorrect
B. $out writes aggregation results to a collection and must be the last stage in a pipeline — it performs no searching at all.
C. $merge also writes results into a collection (with more flexible merge behavior than $out); it isn’t a search mechanism.
D. $unset removes fields from documents passing through the pipeline; it has nothing to do with full-text search.

Source: MongoDB Search Aggregation Pipeline Stages

Correct answer: B
This maps directly onto MongoDB’s own documented example: db.movies.aggregate([{ $match: { "year": { $lt: 1910 } } }, { $group: { _id: "$year", totalRuntime: { $sum: "$runtime" }, averageRuntime: { $avg: "$runtime" } } }]). The docs describe $group as combining “multiple documents with the same field, fields, or expression into a single document according to a group key,” using _id to set that group key (here, $year), while $sum “returns a sum of numerical values” and $avg “returns an average of numerical values” for each group.

Why other options are incorrect
A. $project reshapes fields and doesn’t filter by value the way $match does; $unwind deconstructs array fields, which runtime (a single numeric value) is not.
C. $group collapses documents into per-group summaries, discarding the original per-document year field structure needed for an ordinary $match filter afterward — filtering should happen before grouping to avoid grouping documents that should have been excluded.
D. $sort and $limit alone don’t compute any totals or averages — they only reorder and truncate the result set.

Source: $group (aggregation)

Correct answer: C
MongoDB documents $lookup as an aggregation stage that “performs a left outer join to a collection in the same database to filter in documents from the foreign collection for processing. The $lookup stage adds a new array field to each input document. The new array field contains the matching documents from the foreign collection.” Using { $lookup: { from: "comments", localField: "_id", foreignField: "movie_id", as: "movie_comments" } } produces exactly the described movie_comments array on each movie document.

Why other options are incorrect
A. $merge writes aggregation output into a target collection (with configurable merge behavior); it doesn’t join in documents from another collection as an array field.
B. $facet runs multiple aggregation sub-pipelines in parallel on the same input documents; it isn’t a mechanism for joining a different collection’s documents into each input document.
D. $redact restricts document content based on field-level access logic; it has nothing to do with combining data from another collection.

Source: $lookup (aggregation)

Correct answer: D
MongoDB’s documentation describes $out as a stage that “takes the documents returned by the aggregation pipeline and writes them to a specified collection,” and states plainly that “the $out stage must be the last stage in the pipeline.” It also warns: “If the collection specified by the $out operation already exists, then the $out stage atomically replaces the existing collection with the new results collection upon completion of the aggregation.”

Why other options are incorrect
A. $match filters documents flowing through the pipeline; it doesn’t write results anywhere and is typically used early in a pipeline, not last.
B. $skip bypasses a specified number of documents; it has no role in persisting output to a collection.
C. $count returns a single document with a count of the documents at that point in the pipeline; it doesn’t write a full result set to a collection.

Source: $out (aggregation)

Correct answer: A
MongoDB documents bulkWrite() as a method that “performs multiple write operations on one collection, with controls for order of execution,” and its worked example shows exactly this mix: two insertOne operations, an updateOne, a deleteOne, and a replaceOne, all passed as an array of operation documents to a single bulkWrite() call.

Why other options are incorrect
B. Four separate calls would work functionally but is exactly what the scenario is asking to avoid — multiple round trips instead of one controlled batch of operations.
C. $merge is an aggregation output stage for writing pipeline results into a collection; it isn’t designed for issuing an arbitrary mix of inserts, updates, and deletes.
D. watch() opens a change stream to observe changes happening to a collection in real time — it doesn’t perform writes itself.

Source: db.collection.bulkWrite()

Correct answer: B
MongoDB documents $project as a stage that “passes along the documents with the requested fields to the next stage in the pipeline. The specified fields can be existing fields from the input documents or newly computed fields.” The documented example — { $project: { title: 1, rated: 1 } } — returns only _id, title, and rated, and $project can equally compute and add new fields via expressions.

Why other options are incorrect
A. $facet runs multiple aggregation sub-pipelines on the same input in parallel; it doesn’t reshape a single stream of documents down to specific fields.
C. $bucket groups documents into ranges based on a specified expression and boundaries; it doesn’t select which fields to keep.
D. $sample randomly selects a specified number of documents from its input; it has no field-shaping behavior.

Source: $project (aggregation)

Correct answer: C
MongoDB documents $unwind as a stage that “deconstructs an array field from the input documents to output a document for each element. Each output document is the input document with the value of the array field replaced by the element.” For an input of { _id: 1, item: "ABC1", sizes: ["S","M","L"] }, the documented result is three separate documents — { ..., sizes: "S" }, { ..., sizes: "M" }, { ..., sizes: "L" } — one per array element, with every other field preserved.

Why other options are incorrect
A. $unwind does not concatenate array elements into a joined string — that would require a separate string-manipulation expression, not $unwind.
B. Returning the array’s length is the behavior of an operator like $size, not $unwind, which deconstructs the array rather than measuring it.
D. $unwind operates on array fields specifically (not numeric fields), and it does produce output documents — one per element — rather than none.

Source: $unwind (aggregation)

Correct answer: D
For atomicity across two separate documents like this, MongoDB supports transactions: “For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports distributed transactions, including transactions on replica sets and sharded clusters.” Transactions are used through a session (session.startTransaction() / commitTransaction() or the callback-based withTransaction()), and “transactions are associated with a session… you can have at most one open transaction at a time for a session.” At the same time, MongoDB is explicit that transactions aren’t the default answer to every multi-document scenario: “In MongoDB, an operation on a single document is atomic… multi-document transactions are not necessary for many practical use cases,” and “in most cases, a distributed transaction incurs a greater performance cost over single document writes, and the availability of distributed transactions should not be a replacement for effective schema design.”

Why other options are incorrect
A. MongoDB does not guarantee atomicity across separate documents by default — only a single document’s writes are inherently atomic; two independent updateOne() calls with no transaction could leave the wallets in an inconsistent state (e.g., the debit succeeds but the credit fails).
B. Capped collections are a fixed-size collection type for high-throughput, insertion-order data; they have no cross-document rollback behavior.
C. Change streams notify an application about data changes as they happen; they don’t provide atomicity guarantees or automatically retry a failed write to keep two documents in sync.

Source: Transactions

Correct answer: A
MongoDB documents single field indexes directly: “Single field indexes store information from a single field in a collection… If your application repeatedly runs queries on the same field, you can create an index on that field to improve performance.” Since the query filters specifically on customerEmail, db.customers.createIndex({ customerEmail: 1 }) lets MongoDB use an efficient index scan instead of examining every document.

Why other options are incorrect
B. A geospatial index supports location-based queries; it does nothing for an equality filter on an email field.
C. Indexing an unrelated field (description) provides no benefit to a query that filters on customerEmail — the index has to cover the field(s) actually being queried.
D. While more RAM can help overall performance, the documented, targeted fix for a collection scan on a specific query field is to add an index supporting that field — not simply add hardware.

Source: Single Field Indexes

Correct answer: B
MongoDB’s documentation states: “You do not need to explicitly specify an index as multikey. If you create an index on a field that contains an array value, MongoDB automatically creates the index as a multikey index,” and “for each distinct value in the array, MongoDB creates a separate entry in the index, and each entry points back to the same document.” This lets MongoDB efficiently support the equality-on-array-element query in the scenario using an index scan instead of a collection scan.

Why other options are incorrect
A. MongoDB doesn’t automatically hash array fields when indexing them — the default behavior for an array-valued field is a multikey index, not a hashed one, and the documentation notes “hashed indexes cannot be multikey.”
C. Storing the whole array as a single opaque index entry would prevent efficient lookups on individual elements — the opposite of how multikey indexes actually work.
D. MongoDB fully supports indexing array fields; this is exactly what a multikey index exists for.

Source: Multikey Indexes

Correct answer: C
MongoDB documents compound indexes as indexes that “collect and sort data from multiple field values from each document in a collection,” noting that “the order of fields in a compound index is very important” and that the index’s own sorted B-tree structure can satisfy a matching sort. A compound index on { lastName: 1, firstName: 1 } lets MongoDB return results already sorted in exactly the order the query needs, avoiding both the collection scan and the separate in-memory sort step.

Why other options are incorrect
A. Two separate single field indexes cannot, together, support an efficient multi-field sort the way one compound index built with both fields in the right order can — MongoDB can generally only use one index per query for the main scan.
B. A partial index restricts which documents get indexed based on a filter condition; it doesn’t address the need to support sorting by two fields.
D. A hashed index scrambles values for even distribution (typically used for sharding); hashed indexes don’t preserve field order and can’t support a sort operation.

Source: Compound Indexes

Correct answer: D
MongoDB’s documentation on getIndexes() describes it as returning “an array that holds a list of documents that identify and describe the existing indexes on the collection,” and the documented example output shows a default entry with "key": { "_id": 1 } and "name": "_id_" present even before any custom index has been added. This default _id index is automatic and cannot be removed.

Why other options are incorrect
A. Collections are never truly index-free — the _id index is created automatically for every standard collection, without any explicit action from the developer.
B. The number of indexes is unrelated to document count; a brand-new, empty collection still has the default _id index.
C. getIndexes() returns the collection’s logical index definitions, not one entry per physical shard — sharding doesn’t multiply the count of index definitions returned by this method.

Source: db.collection.getIndexes()

Correct answer: A
MongoDB’s documentation is direct about this trade-off: “Indexes support efficient execution of queries in MongoDB… Although indexes improve query performance, adding an index has negative performance impact for write operations. For collections with a high write-to-read ratio, indexes are expensive because each insert must also update any indexes.” This is exactly the trade-off a developer needs to weigh before adding several new indexes to a write-heavy collection.

Why other options are incorrect
B. The documentation explicitly states indexes do affect write performance — every insert, update, or delete that touches an indexed field must also update that index.
C. More indexes do not universally improve performance — they help reads that use them but add ongoing overhead to every write, which is precisely the trade-off being tested here.
D. The write-time maintenance cost of an index is ongoing, not a one-time cost paid only at creation — every subsequent write must keep the index up to date.

Source: Indexes

Correct answer: B
MongoDB’s documentation on dropping indexes warns: “If you drop an index that’s actively used in production, you may experience performance degradation. Before you drop an index, consider hiding the index to evaluate the potential impact of the drop.” Correctness isn’t affected — MongoDB simply falls back to a less efficient plan (potentially a collection scan) for queries that relied on the dropped index, but the documented recommendation is to hide it first as a safe way to test the impact.

Why other options are incorrect
A. Dropping an index affects query performance, not correctness — the query planner just has fewer options and may need to scan more data, but results remain accurate.
C. Dropping an index does not trigger any automatic recreation — the index is simply gone until a developer explicitly creates it again.
D. MongoDB’s query planner actively prefers indexes over collection scans whenever a suitable index exists — the documentation’s own warning about “performance degradation” after a drop confirms indexes are very much relied upon.

Source: Drop an Index

Correct answer: C
MongoDB’s documentation on explain results states: “If the query planner selects a collection scan, the explain result includes a COLLSCAN stage,” while “if the query planner selects an index, the explain result includes an IXSCAN stage.” The relevant field is winningPlan.stage — seeing "COLLSCAN" there confirms MongoDB scanned every document rather than using an index.

Why other options are incorrect
A. IXSCAN indicates the opposite — that an index was used to retrieve matching entries, not a full collection scan.
B. nReturned reports how many documents the query returned, which says nothing by itself about whether an index or a collection scan was used to find them.
D. queryPlanner.namespace just identifies which collection was queried; it’s always present regardless of whether the winning plan used an index.

Source: Explain Results

Correct answer: D
MongoDB’s documentation on single field indexes states plainly: “You can create an index on any field in a document, including top-level fields, embedded fields, or fields inside embedded documents.” A developer can create this index with db.customers.createIndex({ "address.zip": 1 }), using dot notation to reach into the embedded address sub-document.

Why other options are incorrect
A. MongoDB explicitly supports indexing embedded/nested fields, not just top-level ones — this is one of the documented capabilities of single field indexes.
B. There’s no need to flatten embedded documents into a separate collection just to index a nested field — dotted-path indexing works directly on the existing embedded structure.
C. No renaming is required; MongoDB’s dot notation ("address.zip") already provides a way to reference and index a nested field by its existing path.

Source: Single Field Indexes

Correct answer: A
MongoDB’s documentation on modeling one-to-many relationships recommends embedding for cases like this one: “Use embedded documents for one-to-many relationships. Embedding connected data in a single document reduces the number of read operations required to retrieve data,” and explicitly lists “Author to books” as one of the documented example relationships suited to this embedded model. Reviews, by contrast, are unbounded and accessed separately — a better fit for their own collection rather than embedding, consistent with the general guidance to avoid unbounded, ever-growing arrays inside a single document.

Why other options are incorrect
B. Embedding an unbounded, ever-growing array of reviews directly in the author document risks the document growing very large and degrading performance — exactly the situation MongoDB’s guidance steers developers away from for high-volume, independently-accessed data.
C. Collapsing authors, books, and reviews into one undifferentiated document type ignores the very different access patterns and growth characteristics of each, making the model harder to query and maintain.
D. Splitting authors and books into separate databases with no relationship between them makes it impossible to efficiently retrieve an author’s books together, defeating the goal of serving the common “author with their books” page in as few reads as possible.

Source: Model One-to-Many Relationships with Embedded Documents

Correct answer: B
MongoDB’s documentation on this exact anti-pattern states: “The $lookup operator joins information from multiple collections into a single document. While the $lookup operation is useful when used infrequently, it can be slow and resource-intensive compared to operations that only query a single collection. If you often use $lookup operations, consider restructuring your schema to store related data in a single collection.” Its worked fix uses the Subset Pattern: “You can use the subset schema design pattern to embed a subset of product details in the orders collection. This lets you query a single collection to return the required results,” while less frequently needed product details remain in the separate products collection.

Why other options are incorrect
A. Adding more $lookup stages makes the performance problem worse, not better — it’s the opposite of the documented fix.
C. Capped collections are a fixed-size collection type meant for high-throughput sequential data (like logs); converting products into one has nothing to do with reducing $lookup usage.
D. Removing indexes from products would make any remaining lookups or queries against that collection slower, not faster — it doesn’t address the root cause of frequent cross-collection joins.

Source: Reduce $lookup Operations

Correct answer: C
Atlas documentation describes exactly this workflow: “MongoDB provides sample data you can load into your deployments. You can use this data to quickly get started experimenting with data in MongoDB and using tools such as the Atlas UI.” Loading sample data is done “from the Atlas CLI or the Atlas UI,” and once loaded, a developer can use Data Explorer in the Atlas UI to browse the resulting databases, collections, and individual documents — for example, to find a specific first document in a collection.

Why other options are incorrect
A. Manually authoring thousands of documents is exactly the friction the Sample Datasets feature exists to avoid — it’s not the documented quick-start path.
B. Encryption at rest is a data-at-rest security feature; it has no relationship to loading or generating sample data.
D. Creating an Atlas organization does not automatically populate any project’s clusters with sample data — sample datasets must be explicitly loaded into a specific cluster.

Source: Sample Datasets

Correct answer: D
MongoDB’s official Node.js driver documentation describes it as the supported way to “connect to and interact with data stored in MongoDB by using JavaScript or TypeScript with the Node.js driver.” A MongoClient instance manages its own connection pool per server, so the documented, efficient pattern is to instantiate and reuse a single MongoClient across the application’s lifetime, letting the driver’s internal connection pooling handle concurrent requests — not to create and tear down a client on every operation.

Why other options are incorrect
A. MongoDB drivers already implement the wire protocol for you; there’s no need (or benefit) to hand-roll a raw socket implementation in application code.
B. Creating a brand-new MongoClient for every operation discards the benefit of connection pooling and adds unnecessary connection-setup overhead on every call — it’s the opposite of the driver’s intended usage pattern.
C. MongoDB’s primary wire protocol is not plain REST/HTTP; the official drivers speak MongoDB’s own binary wire protocol, which is why a dedicated driver (not a generic HTTP client) is required.

Source: MongoDB Node.js Driver

Correct answer: A
MongoDB’s connection string documentation describes the username:password@ portion as: “Optional. Authentication credentials. If specified, the client will attempt to authenticate the user to the authSource. If authSource is unspecified, the client will attempt to authenticate the user to the defaultauthdb.” It also notes that special characters in either the username or password must be percent-encoded. In this URI, appuser is the username and S3cret is the password used to authenticate the connection.

Why other options are incorrect
B. The database name (myapp here) is a separate component that appears after the host, not embedded in the credentials portion of the URI.
C. Connection strings don’t encode a “cluster region” inside the credentials segment — region/topology information comes from DNS (for mongodb+srv://) or the explicit host list.
D. Credentials in a connection string are not a comment — they are actively parsed and used by the driver to authenticate the connection.

Source: Connection String Formats

Correct answer: B
The Node.js driver documentation defines this directly: “A connection pool is a cache of open database connections maintained by Node.js driver. When your application requests a connection to MongoDB, Node.js driver seamlessly gets a connection from the pool, performs operations, and returns the connection to the pool for reuse.” It adds that “connection pools help reduce application latency and the number of times new connections are created by Node.js driver” — exactly the benefit that supports many concurrent operations efficiently from a single MongoClient.

Why other options are incorrect
A. A pool maintains up to maxPoolSize connections (not just one) precisely so multiple operations can run concurrently rather than being serialized through a single connection.
C. Creating and destroying a new connection per operation is exactly what connection pooling avoids — the pool’s whole purpose is to reuse already-open connections instead of paying that setup cost repeatedly.
D. The documented benefit is explicitly about performance — reduced latency and fewer new connections — not access control or security.

Source: Connection Pools — Node.js Driver

Correct answer: C
The Node.js driver documentation states: “Use the insertOne() method when you want to insert a single document,” which “returns an InsertOneResult instance representing the _id of the new document,” and “Use the insertMany() method when you want to insert multiple documents… it returns an InsertManyResult instance representing the number of documents inserted and the _id of the new document[s].” A single document goes to insertOne(doc); an array of documents goes to insertMany([...]).

Why other options are incorrect
A. This reverses the correct method-to-argument pairing — insertMany() expects an array, not a single document, and insertOne() expects a single document, not an array.
B. insertOne() expects a single document object as its argument, not an array wrapping one document — passing [doc] is not the documented, correct form.
D. The Node.js driver’s supported CRUD API is insertOne()/insertMany(); there’s no single insert() method in current driver documentation that auto-detects the argument shape.

Source: insertOne() — Node.js Driver

Correct answer: D
The Node.js driver’s documented examples show exactly this pairing: an updateOne() call with a filter like { _id: 465 } and an update document { $set: { quantity: 5 } } to update the value of a single matched document’s field, and an updateMany() call with a filter like { rated: "G" } and { $set: { random_review: ... } } to apply the same change to every matching movie, logging result.modifiedCount afterward.

Why other options are incorrect
A. This reverses the two methods — updateMany() should be used for “every matching movie,” and updateOne() for the single targeted document; swapping them doesn’t satisfy either requirement.
B. Omitting an update operator like $set and passing a bare field-value document is not valid update syntax for updateOne()/updateMany() in the driver.
C. replaceOne() expects a full replacement document, not an update-operator document like { $set: {...} } — mixing the two is not how replaceOne() is documented to work.

Source: updateMany() — Node.js Driver

Correct answer: A
The Node.js driver documentation states: “If you want to remove existing documents from a collection, you can use deleteOne() to remove one document or deleteMany() for one or more documents,” and shows accessing the deleted count as: “you can print the number of documents deleted by the operation by accessing the deletedCount field of the result.” Its documented examples check result.deletedCount === 1 for a single deletion and log result.deletedCount for a bulk deletion.

Why other options are incorrect
B. This swaps the two methods — deleteMany() should handle the regular-expression match against potentially many documents, and deleteOne() the single targeted document.
C. deleteOne() is a fully supported, documented method in the current Node.js driver; there’s no need to fall back to a legacy remove()-with-justOne style call.
D. The delete methods return a result object with a deletedCount property — they don’t return something with a .count() method to call afterward.

Source: deleteMany() — Node.js Driver

Correct answer: B
The Node.js driver documentation is explicit: “The findOne() method returns a Promise instance, which you can resolve to access either the matching document or a null value if there are no matches,” while “The find() method returns a Cursor instance from which you can access the matched documents” — commonly iterated with for await (const doc of findResult) { ... }.

Why other options are incorrect
A. This reverses the documented return types — find() returns a cursor for potentially many documents, and findOne() resolves to at most one document (or null).
C. Neither method automatically materializes a full array — find() returns a cursor (an array would require an explicit toArray() call), and findOne() returns a single document or null, never an array.
D. find() does not throw when multiple documents match — returning multiple results via a cursor is its normal, expected behavior.

Source: find() — Node.js Driver

Correct answer: C
The Node.js driver documentation describes aggregation as built around aggregate(): “Aggregation operations process data in your MongoDB collections and return computed results. The MongoDB Aggregation framework is modeled on the concept of data processing pipelines.” It contrasts the two APIs directly — find operations can “select certain documents to return… select which fields to return… sort… limit… count,” while aggregation operations can do all of that plus “group the results, rename fields, compute new fields, summarize data, [and] connect and merge data sets” — capabilities find() alone doesn’t provide.

Why other options are incorrect
A. find() takes a query filter document (and optional projection), not a multi-stage aggregation pipeline array — it has a fundamentally different argument shape and capability set from aggregate().
B. count() returns a single number of matching documents; it isn’t a general-purpose mechanism for running arbitrary multi-stage transformations like grouping or computed fields.
D. MongoDB provides a dedicated, server-side aggregation method specifically so this kind of processing doesn’t have to be reimplemented in application code after fetching raw documents.

Source: Aggregation — Node.js Driver

Correct answer: D
The Node.js driver documentation explains that write concern “specif[ies] how the driver waits for acknowledgment of write operations on a replica set” and can be set at multiple levels — client, transaction, database, and collection — with the client level acting as “the default for all operation executions unless overridden.” Its documented example sets this at the client level: const clientOptions = { writeConcern: { w: 2 } }; const client = new MongoClient(uri, clientOptions); — exactly matching the scenario’s “default for all operations through that client” requirement.

Why other options are incorrect
A. Write concern is a driver/application-level configuration exposed through client, database, collection, transaction, and per-operation options — it doesn’t require editing server configuration files.
B. While write concern can be overridden per operation, it does not have to be repeated everywhere — setting it once at the client level (as shown above) provides the shared default the scenario asks for.
C. Write concern has no such time-based locking behavior; it’s a per-connection/per-operation configuration setting, not a rate-limited one.

Source: Configure CRUD Operations — Node.js Driver