CRUD Operations practice questions

db.users.save({status: 'active', $inc: {login_count: 1}})

Why it fails: The save method is deprecated and treats the document as a full replacement, not an atomic increment. It would overwrite the entire document with the provided object, potentially losing other existing fields or failing to perform the intended mathematical increment operation on the database server side.

db.users.findAndModify({query: {status: 'active'}, update: {$inc: {login_count: 1}}})

Why it fails: While findAndModify works, it is technically an older legacy command. Modern MongoDB drivers and the shell prefer the updateOne method for standard updates. Using findAndModify is usually reserved for scenarios where returning the document state before or after the modification is strictly required by the business logic.

db.users.updateMany({status: 'active'}, {$set: {login_count: 1}})

Why it fails: This operation uses $set instead of $inc, which would force the value to 1 instead of incrementing it. Additionally, updateMany affects all matching documents, which might be dangerous if you only intend to update one specific user document based on a unique identifier like an ID.

Upsert operations are only available for the replaceOne method.

Why it fails: Upsert functionality is available for updateOne, updateMany, and replaceOne methods. Restricting it to replaceOne would ignore a vast majority of common use cases where partial updates are preferred over full document replacements. The option is globally supported across most standard update methods in the CRUD API.

Using upsert: true with updateMany will never create more than one document.

Why it fails: If updateMany is called with upsert: true and the filter matches no documents, MongoDB will perform exactly one insert operation. It does not iterate through the filter to create multiple documents. The behavior is consistent regardless of how many documents the filter would have matched if they existed.

Upserts can only be performed if the collection is empty.

Why it fails: Upserts are designed to function regardless of the current state of the collection. They are frequently used in populated collections to ensure specific records exist or are kept current. Limiting them to empty collections would negate their primary utility in maintaining data synchronization between systems and databases.

$merge combines two different collection documents into one array.

Why it fails: $merge is an aggregation pipeline stage, not an update operator for array fields. There is no such thing as a $merge operator for document updates. The statement is technically inaccurate, and attempting to use this in an update would result in a syntax error from the database.

$updateArray is the default operator for all array modifications.

Why it fails: $updateArray is not a valid MongoDB operator. All array modifications are performed using specific operators like $push, $pull, $pop, or $addToSet. Making up operator names is a common trap, and developers must rely on the official documentation for the correct syntax and naming conventions.

Returns documents with only the 'status' and 'name' fields.

Why it fails: The projection only includes the 'name' field. The 'status' field will not be returned unless explicitly set to 1 in the projection document. Relying on default inclusion behaviors often leads to unexpected data structures in the application, making explicit projection definitions a best practice for API stability.

Returns an error because 'name' and '_id' cannot be mixed.

Why it fails: Mixing inclusion of fields and exclusion of the _id field is valid syntax in MongoDB. The system is designed to handle this specific requirement, allowing developers to strip the _id field entirely from results while keeping specific application-level data points like names or timestamps intact.

Returns the entire document including all fields.

Why it fails: The projection document is valid and will be applied to the cursor. MongoDB will strictly follow the projection rules provided. If this were to return the full document, it would imply that the projection syntax was ignored, which does not happen with standard driver and shell implementations.

db.collection.removeOne()

Why it fails: There is no method named removeOne in the current MongoDB API. The correct method for single-document removal is deleteOne. Using non-existent methods will throw a TypeError in the shell or an exception in the application code, halting the execution of your data management scripts.

db.collection.removeAll()

Why it fails: The removeAll method does not exist in the current MongoDB API. To remove all documents matching a filter, use deleteMany({}). To remove all documents in a collection regardless of criteria, use the drop method. Using non-existent methods results in runtime errors during your application execution.

{ field: { $regex: /pattern/i } }

Why it fails: While this syntax is valid in some older shells, the official MongoDB query API requires the $options parameter for setting regex flags. Relying on deprecated or non-standard syntax can lead to compatibility issues across different driver versions and different language implementations of the MongoDB interface.

{ field: { $insensitive: 'pattern' } }

Why it fails: There is no operator named $insensitive in MongoDB. Using non-existent operators will lead to query errors. MongoDB relies on the standard $regex operator and its associated $options for handling complex text pattern matching requirements, ensuring consistency across all driver implementations and database environments.

{ field: 'pattern' }

Why it fails: Simple string matches are case-sensitive by default in MongoDB. Using a plain string as a query value will fail to match variations in casing, which is insufficient for search features that require case-insensitive capabilities. You must use the $regex operator to specify case-insensitive matching logic.

db.collection.findOne({_id: 1})

Why it fails: Finding a single document is a read operation that does not require a write lock. Even in older MongoDB versions, read operations were highly concurrent, allowing many readers to access the data simultaneously without blocking each other, ensuring high availability for read-heavy workloads.

db.collection.find().limit(10)

Why it fails: This is a simple read query that does not hold a write lock on the collection. MongoDB's architecture is designed to handle multiple concurrent read operations efficiently, so this query will not impact other writes or block the overall performance of the database cluster.

$set

Why it fails: The $set operator replaces the existing value of a field with a new, static value. It does not perform mathematical arithmetic on the existing data, making it unsuitable for incrementing a counter unless you first retrieve the current value, perform the calculation in application code, and send the result back.

$push

Why it fails: The $push operator is designed to append an element to an existing array field within a document. It does not perform mathematical operations on numeric fields and will result in a write error if applied to a field that holds a number rather than an array type.

$add

Why it fails: The $add operator does not exist as a top-level field update operator in MongoDB's update document syntax. While it exists within the $project stage of an aggregation pipeline, using it in an updateOne call will cause the driver or shell to throw an unrecognized operator exception.

The find() method returns a Promise that resolves to an array of documents.

Why it fails: The find() method returns a Cursor object, not a Promise. Cursors are iterables used to manage result sets incrementally. While some driver methods like toArray() return a Promise, the find() call itself is synchronous in terms of object instantiation, requiring further interaction to retrieve data from the server.

The find() method automatically closes the cursor after the first document is retrieved.

Why it fails: Cursors remain open until the application iterates through all results, the client explicitly calls close(), the cursor times out due to inactivity, or the query is exhausted. It does not automatically close after returning one document, as this would prevent applications from processing large result sets in subsequent steps.

The find() method always returns the documents in the order they were inserted.

Why it fails: MongoDB does not guarantee insertion order for find operations without an explicit sort stage. Data is retrieved based on the natural order on disk or index traversal, which can change due to document updates, deletions, or data movement. Relying on implicit order leads to unpredictable application behavior across different deployments.

db.users.updateMany({email: 'user@example.com'}, {$set: {name: 'New Name'}}, {upsert: true})

Why it fails: updateMany with upsert: true will update all matching documents, but if no match is found, it will insert a single new document. However, if the email is unique, there can be at most one match. The main issue is that updateMany is intended for multiple documents; using it for a unique field is inefficient and semantically misleading. It does achieve the goal, but it is not the best choice.

db.users.insertOne({email: 'user@example.com', name: 'New Name'})

Why it fails: insertOne will always attempt to insert a new document. If a document with the same email already exists, the unique index will cause a duplicate key error, and the insert will fail. This does not update the existing document, so it does not meet the requirement of updating if the email exists.

db.users.findAndModify({query: {email: 'user@example.com'}, update: {$set: {name: 'New Name'}}, upsert: true})

Why it fails: findAndModify does support upsert, but it is deprecated in favor of findOneAndUpdate. While it could work, it is not the recommended method in modern MongoDB versions. The question asks for operations that achieve the goal; findAndModify is technically valid but less preferred, and often considered outdated. However, it does not inherently fail; the reason it is not correct here is that it is not one of the two best practices, but the exam expects knowledge of current methods.

db.orders.find({ $and: [{ status: "pending" }, { status: "shipped" }], archived: false })

Why it fails: Using $and with two conditions on the same field requires the field to equal both "pending" and "shipped" simultaneously, which is impossible. This query would return no documents. The intent is to match either value, so $in or $or should be used instead.

db.orders.find({ $or: [{ status: "pending" }, { status: "shipped" }], archived: { $ne: true } })

Why it fails: While this query would also return the correct documents, it is not the best choice because it uses $or with two separate conditions instead of $in. The $ne: true condition would also match documents where archived is missing or null, which might not be desired. The requirement is to exclude orders where archived is true, but the semantics of $ne: true include documents without the field, potentially returning unwanted results.

db.orders.find({ status: { $or: ["pending", "shipped"] }, archived: false })

Why it fails: $or is a top-level query operator and cannot be used as a field-level operator inside a field condition like status: { $or: [...] }. This syntax is invalid and would cause an error. The correct way to specify multiple possible values for a field is with $in, not $or.

db.inventory.updateMany({quantity: {$lt: 10}}, {$set: {lastUpdated: new Date()}})

Why it fails: updateMany would update all documents with quantity less than 10, not just one. The requirement is to update a document (singular), implying one document. If multiple documents match, updateMany would modify all of them, which may not be desired. Thus it does not precisely meet the requirement.

db.inventory.update({quantity: {$lt: 10}}, {$set: {lastUpdated: new Date()}})

Why it fails: The update method is deprecated in modern MongoDB drivers and shell. It is not recommended for new applications. While it might work, it is not the correct method to use in current best practices. The DBA should use updateOne or updateMany instead.

db.inventory.replaceOne({quantity: {$lt: 10}}, {lastUpdated: new Date()})

Why it fails: replaceOne would replace the entire matched document with a new document containing only the lastUpdated field. This would remove all other fields such as item name, quantity, etc. This is destructive and not intended. Additionally, it does not use $set to add a field; it replaces the whole document.

The write concern guarantees that the write will be visible to all secondary members immediately after acknowledgement.

Why it fails: Majority write concern only ensures that a majority of voting members have acknowledged the write. It does not guarantee that all secondaries have replicated it. Some secondaries might still be catching up. Visibility to all members is not guaranteed.

The write concern will cause the insert to fail if the replica set has fewer than three members.

Why it fails: The write concern w: "majority" calculates the majority based on the number of voting members. If the replica set has an even number of members, majority is half plus one. It does not require three members; a two-member replica set would have a majority of two, but in practice, a two-member replica set can have issues with elections. However, it is not strictly required to have three members.

The write will be acknowledged after it is written to the primary's journal only.

Why it fails: This describes w: 1 with j: true, not w: "majority". With w: "majority", the write must be acknowledged by a majority of voting members, not just the primary. The primary alone is insufficient to satisfy the majority write concern.

Use `db.accounts.bulkWrite([...], { ordered: false })` to allow the server to reorder operations for performance.

Why it fails: With `ordered: false`, MongoDB may execute operations in parallel and in any order. While this can improve throughput, it does not guarantee sequential execution and could lead to inconsistent results if operations depend on each other. The scenario explicitly requires ordered execution, so this setting is inappropriate.

Use `db.accounts.initializeOrderedBulkOp()` to create an ordered bulk operation.

Why it fails: `initializeOrderedBulkOp()` is part of the legacy bulk operation API, which is deprecated in modern MongoDB drivers. The preferred and supported method for bulk writes is `bulkWrite()`. Using the legacy API may not be available in all drivers and is not the correct approach for MongoDB 6.0.

Set the `writeConcern` to `{ w: 0 }` to ensure the operations are applied in order.

Why it fails: `writeConcern` controls the acknowledgment level of write operations, not their ordering. Setting `w: 0` requests no acknowledgment, which can improve performance but does not affect execution order. Ordering is controlled by the `ordered` option, not by write concern.

Use `db.users.updateMany( { lastLogin: { $lt: new Date(Date.now() - 90*24*60*60*1000) } }, { $set: { status: "inactive", deactivatedAt: new Date() } } )`.

Why it fails: While `updateMany` will update all matching documents, it performs the entire operation in a single transaction-like batch, which can cause significant performance impact on a large collection. It may hold locks and generate a large oplog entry, potentially affecting production. For millions of documents, a batched approach is safer.

Use `db.users.replaceMany( { lastLogin: { $lt: ... } }, { ... } )` to replace entire documents.

Why it fails: `replaceMany` is not a valid MongoDB method. Even if it were, replacing entire documents would require fetching and rewriting all fields, which is more resource-intensive and risks losing fields not included in the replacement. The `$set` operator is the correct way to update specific fields.

Use `db.users.updateMany()` with `{ multi: true }` option to ensure all documents are updated.

Why it fails: `updateMany()` already updates all matching documents; the `multi` option is only relevant for the legacy `update()` method. Adding `{ multi: true }` to `updateMany()` is unnecessary and may be ignored. This does not address the performance concern of updating millions of documents at once.

.offset()

Why it fails: While some SQL databases use OFFSET, MongoDB uses the skip() cursor modifier. The offset() method does not exist in the standard MongoDB shell or drivers. Attempting to use it will result in a TypeError, as the cursor object does not contain an offset function for pagination purposes.

.limit()

Why it fails: The limit() modifier controls the maximum number of documents returned by the query, not the starting point. Using limit() alone will always start from the first document in the result set. It is often paired with skip() but serves a completely different role in the query pipeline.

.next()

Why it fails: The next() method is used to iterate through the cursor and retrieve the next available document one by one. It is not designed to skip multiple documents efficiently or support standard pagination logic. Using it in a loop to skip documents would be highly inefficient and slow.

All documents with 'electronics' tag sorted by price ascending.

Why it fails: The query includes a limit(5) clause, meaning it will return at most five documents. Returning all documents would ignore the limit modifier, which is crucial for controlling memory usage and network overhead when dealing with large collections of data in a production environment.

Any 5 products with price less than 500, regardless of tags.

Why it fails: The query includes a filter on the 'tags' field. MongoDB only considers documents where the 'tags' array contains the specific string 'electronics'. Ignoring the filter condition would return incorrect data for the application's business requirement, which specifically targets electronics within a certain price range.

The 5 most expensive products tagged 'electronics' that cost less than 500.

Why it fails: The sort order is specified as {price: 1}, which corresponds to ascending order (cheapest to most expensive). To get the most expensive products, the sort would need to be {price: -1}. The current order will return the lowest prices first, not the highest prices.

$remove

Why it fails: $remove is not a valid update operator in MongoDB. Users often confuse it with the remove() method used for deleting entire documents. Attempting to use $remove in an update statement will cause a command error, as the server does not recognize this as a valid modification instruction.

$pop

Why it fails: $pop only removes the first or last element of an array. It does not support removing specific elements based on their value or a matching condition. If you need to remove a specific item from the middle of an array, $pop is not the appropriate operator.

$unset

Why it fails: $unset is used to remove an entire field from a document, not specific elements within an array. Using $unset on an array field would delete the entire array field from the document, which is likely not the desired behavior when only a single item needs to be removed.

The inclusion takes precedence over the exclusion.

Why it fails: MongoDB does not prioritize one projection type over the other. Instead, it treats the presence of both as an invalid operation. If you need both, you must either only include the fields you need or only exclude the fields you do not want, unless you are specifically handling the _id.

The exclusion takes precedence over the inclusion.

Why it fails: There is no precedence order between inclusion and exclusion. The server rejects the query entirely because the logical state of the requested document is undefined. The developer must refactor the projection to use only one type, except for the special handling afforded to the _id field.

It returns the intersection of both fields.

Why it fails: The database engine does not attempt to calculate an intersection or union of the projection rules. It is a hard architectural constraint that prevents the query from executing. Providing a clean, consistent projection is a requirement for successful data retrieval in the MongoDB query language.

To filter which documents are returned.

Why it fails: The filtering of documents is handled by the query document (the first argument to find). The projection is the second argument and specifically controls which fields are present in the returned documents, not which documents are selected from the collection based on their content.

To sort the returned documents.

Why it fails: Sorting is handled by the sort() cursor modifier, not the projection parameter. Projections are strictly for field selection within a document, whereas sorting dictates the order in which the set of documents is returned based on field values, which are distinct operations in the query pipeline.

To limit the number of documents returned.

Why it fails: Limiting the number of documents is performed by the limit() cursor modifier. Projection concerns itself exclusively with the internal structure of the documents being retrieved, not the total count or quantity of the documents themselves. Using them interchangeably would show a misunderstanding of the MongoDB API.