Sample questions
Mongodb OperationsDifficulty 1
What does the mongodump utility produce by default when you run it against a database?
- aA single compressed SQL file that
mysql-style tools can replay - bA set of BSON files (one per collection) plus metadata, representing a logical backup✓
- cA raw, byte-for-byte copy of the underlying WiredTiger data files on disk, only taken while the server is fully stopped
- dA point-in-time filesystem snapshot managed entirely by the storage engine
Explanation:mongodump reads documents through the normal query path and writes them out as BSON files per collection, along with metadata (indexes, options) — this is a logical backup, not a raw copy of on-disk storage files.
Mongodb OperationsDifficulty 1
Which command loads data produced by mongodump back into a MongoDB server?
- a
mongoimport, since it is the general-purpose data-loading tool - b
mongosh --load, run against the dump directory - c
mongorestore, pointed at the dump directory✓ - d
mongod --restore, started with the dump path as an argument
Explanation:mongorestore is the counterpart to mongodump: it reads the BSON/metadata files a dump produced and inserts them back into a running mongod/mongos. mongoimport is for JSON/CSV, not mongodump output.
Mongodb OperationsDifficulty 2
Why does mongodump --oplog matter for backing up a replica set member that is under active writes?
- aIt also captures oplog entries during the dump so the backup can be replayed to a single consistent point in time✓
- bIt compresses the dump using the oplog's binary format, producing a smaller file
- cIt disables writes on the member for the duration of the dump, guaranteeing consistency
- dIt dumps only the oplog collection instead of the actual data, for replication debugging
Explanation:Without --oplog, a dump taken while writes continue can end up inconsistent across collections (different collections reflect different points in time). --oplog records the oplog during the dump so mongorestore --oplogReplay can bring everything to one consistent point-in-time.
Mongodb OperationsDifficulty 2
A team backs up MongoDB by taking a filesystem-level snapshot (e.g. LVM or cloud disk snapshot) of the data directory instead of using mongodump. What must be true for this snapshot to be usable?
- aThe snapshot tool must understand the BSON document format to avoid corrupting collections
- b
mongodump must still be run once beforehand as well, since filesystem snapshots on their own cannot be restored standalone - cThe database must be running the in-memory storage engine, not WiredTiger
- dThe snapshot must capture all data files at a single, consistent instant (crash-consistent)✓
Explanation:A filesystem/block-level snapshot works because WiredTiger is designed to recover from a crash-consistent image the same way it recovers after a power loss — but the snapshot has to capture the whole data directory atomically at one instant, otherwise it can mix files from different points in time and corrupt the data on restore.
Mongodb OperationsDifficulty 2
What is db.currentOp() used for in MongoDB?
- aListing the operations recorded in the last profiler window
- bShowing the operations currently in progress on the server, including their duration and query shape✓
- cReplaying the most recent oplog entry for debugging replication lag
- dReturning the current replica set configuration document
Explanation:db.currentOp() returns a snapshot of in-progress operations on the server (queries, writes, index builds, etc.), which is the main tool for spotting a long-running or blocking operation right now.
Mongodb OperationsDifficulty 2
With no profiler filter and sampleRate set to 1.0, what does enabling the database profiler at level 1 with a slowms threshold do?
- aLogs every single operation, regardless of duration, into
system.profile - bDisables profiling entirely but keeps recording server-wide CPU usage
- cRecords operations whose
workingMillis exceeds slowms into the system.profile collection✓ - dBlocks any operation exceeding
slowms from completing, to protect the server
Explanation:With no filter and sampleRate: 1.0, profiler level 1 records operations whose workingMillis exceeds slowms; workingMillis measures time MongoDB spends working on the operation rather than total wall-clock time. A lower sampleRate samples qualifying operations, while a configured filter replaces the slowms/sampleRate criteria. Level 2 records all operations.