CRUD Operations practice questions

{ multi: true }

Why it fails: The multi parameter determines whether update operations modify all matching documents or only the first one encountered. It does not control document creation behavior when a filter fails to match any existing records in the target collection.

{ upsert: true }

Why it fails: Enabling the upsert flag allows the operation to create a new document when no existing document matches the specified query criteria, utilizing both the query filter and the update document components during the insertion process.

{ returnNewDocument: true }

Why it fails: This option modifies the return behavior of findOneAndUpdate operations to supply the updated document rather than the original pre-modification version. It has no impact on whether a missing document is inserted into the collection.

{ insertOne: { document: { sku: "A100", qty: 0 } } }

Why it fails: insertOne unconditionally adds a new document. If a document with the same sku already exists, this creates a duplicate rather than honoring the condition that insertion happen only when no matching document exists. It also lacks any uniqueness enforcement by itself, so it does not meet the conditional insert requirement.

{ replaceOne: { filter: { sku: "A100" }, replacement: { sku: "A100", qty: 5 } } }

Why it fails: replaceOne overwrites the entire matched document with the replacement, discarding all other fields and setting qty to a fixed value rather than incrementing it. It also does not insert when no document matches unless upsert is specified. This neither preserves existing data nor performs the required increment.

{ deleteOne: { filter: { sku: "A100" } } }

Why it fails: deleteOne removes a matching document, which is the opposite of inserting a missing item or incrementing an existing quantity. It cannot satisfy either requirement and would destroy inventory data. Including it in the batch would directly contradict the stated goal of maintaining the item and its quantity.

db.reservations.updateOne({ 'guests.name': 'M. Chen' }, { $set: { 'guests.$[elem].checkedIn': true } }, { arrayFilters: [{ 'elem.name': 'M. Chen' }] })

Why it fails: arrayFilters with the $[elem] identifier is a valid technique, but here it duplicates the query condition and adds complexity without changing the outcome for a single match. For this straightforward case the positional operator is sufficient, and the arrayFilters form is typically reserved when the query cannot express the element condition directly.

db.reservations.updateOne({ 'guests.name': 'M. Chen' }, { $set: { 'guests.checkedIn': true } })

Why it fails: Without the positional operator, 'guests.checkedIn' refers to a field named checkedIn directly on the array, which does not address any element. MongoDB would either create an unexpected field or fail, and it certainly would not mark the matching subdocument as checked in.

db.reservations.updateOne({ 'guests.name': 'M. Chen' }, { $set: { 'guests.$[].checkedIn': true } })

Why it fails: The all-positional $[] operator applies the update to every element of the guests array, so all guests would be marked checked in. That contradicts the requirement to modify only the subdocument belonging to M. Chen while leaving the others unchanged.

db.metrics.updateOne({ sensorId: 'S-42' }, { $setOnInsert: { lastSeen: new Date(), readings: 1 } })

Why it fails: Without upsert: true, updateOne does nothing when no document matches, so no new sensor document would ever be created. Even with upsert, $setOnInsert only applies on insert and would not increment readings on subsequent updates, so the counter requirement would be unmet.

db.metrics.replaceOne({ sensorId: 'S-42' }, { sensorId: 'S-42', lastSeen: new Date(), readings: 1 }, { upsert: true })

Why it fails: replaceOne substitutes the entire document, so the readings counter would be reset to 1 on every call rather than incremented. It does avoid duplicates through upsert, but it destroys the accumulating counter value, which is a core part of what the monitoring service needs to preserve.

db.metrics.insertOne({ sensorId: 'S-42', lastSeen: new Date(), readings: 1 })

Why it fails: insertOne always creates a new document and never checks for an existing sensorId, so repeated retries would produce duplicate metric documents. It also does not increment an existing counter, which the requirement explicitly demands. This approach fails both the deduplication and the increment conditions.

{ readings: 1, _id: 0 }

Why it fails: Inclusion projection simply returns the entire readings array as stored. It does not filter elements by value, so a sensor with readings [50, 150, 200] would return all three values. This satisfies neither the 'first matching element' requirement nor any element-level filtering.

{ readings: { $slice: 1 } }

Why it fails: $slice returns a fixed number of elements from the array based on position, not based on the query predicate. It would return the first element regardless of whether it exceeds 100, so a document whose first reading is 50 but whose third is 150 would return the wrong element. $slice cannot filter by a condition.

{ readings: { $filter: { input: '$readings', as: 'r', cond: { $gt: ['$$r', 100] } } } }

Why it fails: $filter is an aggregation expression usable in $project within an aggregation pipeline, not in a find projection. Passing it as a find projection causes an error. To use $filter the developer would need an aggregation stage, which is a different operation than the find projection described in the scenario.

db.shipments.updateOne({ _id: id, 'events.status': { $ne: status } }, { $push: { events: newEvent } })

Why it fails: This filter checks only that no event anywhere in the array has the given status, ignoring the timestamp. It also applies the update only if the whole document matches, so a document with an event of the same status but different timestamp would block the legitimate append. The uniqueness condition is not correctly expressed.

db.shipments.updateOne({ _id: id }, { $push: { events: newEvent } })

Why it fails: $push always appends the element, regardless of whether an identical subdocument is already present. During retries this would create duplicate events, which is precisely what the scenario wants to prevent. It does not compare existing array elements, so it cannot enforce the uniqueness condition described.

db.shipments.updateOne({ _id: id }, { $set: { 'events.$[elem]': newEvent } }, { arrayFilters: [{ 'elem.status': status }] })

Why it fails: The $set with arrayFilters replaces existing array elements that match the filter rather than appending a new one. If no element matches, nothing is updated and no event is added. This overwrites history instead of conditionally adding a distinct event, so it fails the requirement to append only when absent.

db.logs.find({ timestamp: { $gte: ISODate("2023-01-01T00:00:00Z"), $lte: ISODate("2023-12-31T23:59:59Z") } })

Why it fails: This query attempts to cover the year by using an upper bound of 23:59:59 on December 31. However, it misses any timestamps with fractional seconds after 23:59:59, and it is less precise than using the start of the next year with $lt. It is not the recommended approach.

db.logs.find({ timestamp: { $year: 2023 } })

Why it fails: There is no $year query operator in MongoDB. $year is an aggregation operator that must be used within an aggregation pipeline or $expr. Using it directly in a find filter will result in an error or unexpected behavior.

db.logs.find({ timestamp: { $gte: ISODate("2023-01-01"), $lte: ISODate("2023-12-31") } })

Why it fails: This query uses $lte with the date 2023-12-31, which is midnight at the start of that day. It would exclude any timestamps later in the day on December 31, 2023. To include the entire day, the upper bound should be the start of the next day with $lt.

db.profiles.replaceMany({}, { $unset: { legacyScore: '' } })

Why it fails: replaceMany is not a valid MongoDB collection method. Replacement in MongoDB is performed with replaceOne, which replaces the entire document rather than removing a single field. There is no replaceMany method, so this operation cannot run and does not satisfy the requirement.

db.profiles.updateMany({}, { $rename: { legacyScore: null } })

Why it fails: $rename moves a field to a new name and requires a string target, not null. It cannot delete a field; it would either error or rename the field to a different name, leaving data behind. Removing a field is the domain of $unset, so this option does not achieve the goal.

db.profiles.updateMany({}, { $pull: { legacyScore: { $exists: true } } })

Why it fails: $pull is designed to remove elements from an array, not to delete a top-level document field. Applied to a non-array field it has no effect, so legacyScore would remain. The operator is simply the wrong tool for removing a scalar or embedded document field from each document.

db.profiles.insertOne({ username: 'alice', ... })

Why it fails: insertOne will attempt to insert the document and will fail if a unique index on 'username' exists and the value is a duplicate. However, it does not provide a way to conditionally insert only if not exists without relying on the unique index. The question asks for a method that ensures the insert only happens if the username does not exist; insertOne alone does not guarantee that unless a unique index is present, but the scenario implies you need a method that inherently checks existence. The typical method for this is updateOne with upsert.

db.profiles.findAndModify({ query: { username: 'alice' }, update: { $setOnInsert: { username: 'alice', ... } }, upsert: true, new: true })

Why it fails: findAndModify with upsert:true is similar to updateOne with upsert, but it is a lower-level command. It can achieve the same conditional insert, but it is more complex and typically used when you need to return the document. The question asks for a method, and updateOne is the standard high-level method. However, findAndModify is not wrong per se, but it is not the best answer because it is not the typical method used for this purpose.

db.profiles.replaceOne({ username: 'alice' }, { username: 'alice', ... }, { upsert: true })

Why it fails: replaceOne with upsert:true will replace an existing document or insert a new one if none matches. However, it replaces the entire document, which could inadvertently remove other fields if the replacement document is not complete. It does not conditionally insert only if not exists; it will overwrite if exists, which is not the desired behavior.

Setting the { writeConcern: { w: 'majority' } } option during the update operation.

Why it fails: Write concern defines the acknowledgment level required from the replica set before returning success. It dictates durability guarantees rather than controlling whether missing documents are inserted or how document fields are constructed during update operations.

Setting the { returnDocument: 'after' } option in the findOneAndUpdate method.

Why it fails: returnDocument controls whether the returned document reflects pre- or post-update state; it does not create a document when none matches. It is tempting because it is commonly paired with upsert-style updates, and would be correct when you need the modified document returned after a successful findOneAndUpdate.

Setting the { multi: true } option to force updates across multiple matching records.

Why it fails: The multi option controls how many matching documents an update affects, not insert-on-miss behaviour. It is tempting because it is the standard parameter for bulk updates, and would be correct when a single update must modify every document matching the filter rather than just the first.

{ tags: { $in: ['electronics', 'sale'] } }

Why it fails: The $in operator matches documents where the field value equals any value within the specified array. For array fields, it matches if the array contains at least one of the target values, failing the requirement to contain both.

{ tags: ['$electronics', '$sale'] }

Why it fails: This syntax is invalid: '$electronics' and '$sale' are parsed as field references, not string literals, and a bare array matches exact array equality including order and length. It is tempting because array literals resemble an 'in' list; it would be correct only when matching a document whose tags array equals exactly those two values.

{ tags: { $elemMatch: { $eq: 'electronics', $eq: 'sale' } } }

Why it fails: $elemMatch matches a single array element satisfying all its criteria, so two $eq keys on the same field collapse to one condition, matching only 'sale'. It is tempting because $elemMatch is designed for arrays of subdocuments; it would be correct when each element is an object needing multiple field conditions.

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.

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.

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.

db.shipments.updateOne({ _id: 42 }, { $pullAll: { packages: ["TRK-9981"] } })

Why it fails: $pullAll removes all instances of the exact values listed from an array. Here the array holds embedded documents, not bare strings, so specifying the string "TRK-9981" matches nothing and the update changes no data. It cannot match on a field inside the subdocument, so it does not satisfy the scenario.

db.shipments.updateOne({ _id: 42, "packages.trackingCode": "TRK-9981" }, { $unset: { "packages.$": "" } })

Why it fails: $unset with the positional operator sets the matched array element to null rather than deleting it, leaving a null placeholder inside the array. The document would still contain a packages entry, which violates the requirement to remove the subdocument entirely. It also depends on the positional operator matching the array element via the query predicate.

db.shipments.updateOne({ _id: 42 }, { $pop: { packages: 1 } })

Why it fails: $pop removes either the first or last element of an array by position, not by matching a field value. With a value of 1 it deletes the final element of the packages array, which could be any package, not necessarily the one with trackingCode TRK-9981. It cannot express a value-based removal, so it fails the requirement.

db.sensors.createIndex({ active: 1 }, { sparse: true })

Why it fails: A sparse index omits documents that lack the indexed field entirely. Since every sensor document contains an 'active' boolean, the sparse option excludes nothing and provides no advantage over a normal index here. It still indexes true and false values, so it does not reduce the index size or change the access path for this scenario.

db.sensors.createIndex({ _id: 1, active: 1 })

Why it fails: A compound index whose leading field is _id cannot be used efficiently to filter on 'active' alone. The query planner can only use an index prefix, so with _id first and no _id predicate in the query, the 'active' portion is not usable as an access path. The query would still scan or fall back to a full collection scan.

db.sensors.createIndex({ active: "text" })

Why it fails: A text index is designed for full-text search over string content and tokenizes fields for word matching. It cannot serve an equality filter on a boolean field, and a boolean value is not valid text-index content in the way this query requires. The planner would not use this index for the active = true predicate.

db.shipments.updateOne({ status: 'in_transit', carrier: 'FastShip' }, { $set: { deliveredAt: new Date() } })

Why it fails: updateOne stops after modifying the first matching document, so any other in_transit FastShip shipments would keep a stale or missing deliveredAt value. The requirement demands every qualifying shipment be updated, so the single-document behavior of updateOne leaves the collection partially updated and the task incomplete.

db.shipments.replaceMany({ status: 'in_transit', carrier: 'FastShip' }, { deliveredAt: new Date() })

Why it fails: There is no replaceMany method in the MongoDB shell; replaceOne is the only replace helper, and it accepts a full replacement document. Even if such a method existed, a replacement document would discard the original fields such as status and carrier, which is not what the scenario asks for.

db.shipments.findAndModify({ query: { status: 'in_transit', carrier: 'FastShip' }, update: { $set: { deliveredAt: new Date() } }, multi: true })

Why it fails: findAndModify does not support a multi option; it is designed to atomically modify one document and return it, so passing multi is ignored or rejected. It could be looped manually, but that is not a single command that updates all matching shipments as the requirement specifies.

$inc is not atomic on a replica set, so two nodes can apply the increment independently and produce a divergent count value.

Why it fails: $inc is an atomic single-document update operator regardless of topology. On a replica set the operation is applied once on the primary and then replicated through the oplog to secondaries, so nodes do not independently compute the increment. This option misstates how replication and atomic updates interact, and it is not the reason a count appears lost.

The update used an equality filter on 'metric', so the query planner could not use an index and the write was silently skipped under load.

Why it fails: A missing index affects query performance, not whether a write is applied. The update would still execute and modify the matching document even with a collection scan. There is no mechanism by which an unindexed equality filter causes a write to be silently skipped, so this does not explain the lost increment.

Because the collection has no unique index on 'metric', the increment was applied to multiple documents and the count became ambiguous.

Why it fails: updateOne modifies at most one matching document, so the absence of a unique index cannot cause multiple counters to be incremented by this statement. Even if several documents shared the metric value, only one would be updated. This option misattributes the symptom to indexing rather than to replication acknowledgement semantics.

db.reviews.find({}, { author: true, rating: true })

Why it fails: This projection includes author and rating but leaves _id in the results, because _id is returned by default unless explicitly excluded. The developer asked for the _id field to be omitted, so this query returns more data than requested even though the field selection is otherwise correct.

db.reviews.aggregate([{ $project: { author: 0, rating: 0, _id: 0 } }])

Why it fails: A $project stage with values of 0 is an exclusion projection, so this pipeline removes author and rating while keeping every other field, the reverse of what was requested. It also returns a cursor from aggregate rather than the simple find result the developer expected.

db.reviews.find({ author: 1, rating: 1, _id: 0 })

Why it fails: Here the field document is passed as the query filter, not the projection, so MongoDB interprets it as a match condition. It would look for documents whose author equals 1 and rating equals 1, returning almost nothing instead of projecting fields, which is the opposite of the intended behavior.

db.shipments.updateMany({ carrier: 'DHL' }, { $pop: { tracking_history: { status: 'cancelled' } } })

Why it fails: $pop removes either the first or last element of an array based on a value of -1 or 1, and it does not evaluate a field condition such as status: 'cancelled'. Passing an object to $pop is invalid. It cannot target specific array elements by their contents, so it fails the requirement.

db.shipments.deleteMany({ carrier: 'DHL', 'tracking_history.status': 'cancelled' })

Why it fails: deleteMany removes whole documents that match the filter, which would erase any DHL shipment containing at least one cancelled entry. The task explicitly requires keeping documents and removing only the array element. This operation destroys shipment records and is therefore incorrect.

db.shipments.updateMany({ carrier: 'DHL' }, { $unset: { 'tracking_history.status': 'cancelled' } })

Why it fails: $unset removes a field entirely rather than an array element, and it does not accept a value condition like 'cancelled'. Using it on tracking_history.status would either delete the status field from every element or fail, leaving cancelled entries present. It cannot selectively remove only the cancelled array elements.

The driver performs an upsert automatically, so if a document with the same sku exists it replaces it.

Why it fails: insert_one() never performs an upsert. It always attempts a plain insert, and if a unique index on sku already contains 'A100', the operation fails with a duplicate key error rather than replacing the existing document. Upsert semantics belong to update operations using the upsert option, not to insert_one.

The server rejects the insert because the document lacks an explicit _id field, requiring the application to supply one.

Why it fails: MongoDB does not require the application to supply an _id. If the document passed to insert_one() omits _id, the driver generates an ObjectId client-side and includes it in the insert command. The server only rejects a write when an _id value violates uniqueness constraints, not when it is absent.

The document is written only to the driver's local buffer and flushed to the server when the client closes the connection.

Why it fails: The MongoDB driver does not buffer individual inserts for later flushing on connection close. insert_one() writes to the server within the operation and, under default write concern, waits for acknowledgment. Relying on connection close to persist data would make durability unpredictable and is not how the driver works.

db.sensor_readings.createIndex({ recordedAt: -1, deviceId: 1 })

Why it fails: This compound index places the sort field first and the equality filter field second. While it can support sorting on recordedAt alone, the equality predicate on deviceId cannot be efficiently served as a prefix, so the planner will not use it to satisfy both the filter and the sort in one scan. The query would still need to examine extra index entries and may not fully avoid the sort stage.

db.sensor_readings.createIndex({ deviceId: 1 })

Why it fails: An index on deviceId alone helps the equality filter, but it does not include recordedAt, so the sort cannot be satisfied by the index. MongoDB would have to perform an in-memory sort of all matching readings, which is exactly the behavior causing the high memory usage and the reason a compound index is required.

db.sensor_readings.createIndex({ recordedAt: 1 })

Why it fails: A single-field index on recordedAt supports sorting in ascending order only; a descending sort can be served by scanning the index in reverse, so sorting is possible, but the deviceId filter is not covered. The planner would still need to fetch and filter many documents, and with millions of readings this remains inefficient and does not address the filtering cost.