Hard Difficulty Questions

BSON is human-readable and easier to debug than JSON.

Why it fails: BSON is a binary format and is not intended to be human-readable. While JSON is text-based and easy for humans to read, BSON is optimized for machine traversal and storage efficiency. Debugging BSON typically requires tools that translate the binary data into a readable format like JSON.

BSON supports fewer data types than standard JSON.

Why it fails: BSON is designed to support more data types than JSON. While JSON only supports basic types like strings, numbers, and booleans, BSON includes native support for Date, BinData, ObjectId, and Timestamp, which are essential for database operations and ensuring data integrity across distributed systems.

BSON is mandatory for communication with the shell only.

Why it fails: BSON is the primary storage and wire protocol format for MongoDB. It is used for disk storage, intra-node replication, and network communication between the driver and the server. It is not limited to the shell, as it is foundational to the entire operation of the MongoDB database engine.

Normalize data to the third normal form.

Why it fails: Third normal form is a relational database standard designed to eliminate redundancy. MongoDB often favors denormalization to improve read performance, as joining data across collections is more resource-intensive than retrieving an embedded document that already contains all required related information.

Always prioritize write consistency over read performance.

Why it fails: MongoDB allows developers to configure consistency levels (e.g., write concern and read concern). It does not force a 'write-first' philosophy at the expense of performance, but rather offers the flexibility to balance these trade-offs based on the specific needs of the application's use case.

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.

Execute the compact command on every individual collection containing fragmented indexes during peak operational hours.

Why it fails: Running the compact command requires an exclusive database lock and consumes significant CPU and disk input-output resources. Executing this maintenance task during peak hours will block incoming application reads and writes, leading to severe timeouts and application service outages.

Drop the fragmented index and recreate it using the background option in MongoDB versions prior to 4.2.

Why it fails: The background index build option was deprecated in modern server releases and removed entirely in version 4.4. Relying on legacy command arguments on modern database deployments causes syntax errors and fails to execute the required administrative maintenance procedure.

Rebuild indexes using the createIndexes command with unique naming strategies to replace the old structures.

Why it fails: Creating duplicate indexes with alternate names fails to clean up the existing fragmented B-tree structures. This approach merely consumes additional disk space and increases memory pressure on the WiredTiger cache without resolving the underlying performance degradation.

$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.

It will always use {a: 1, b: 1}.

Why it fails: The optimizer does not blindly pick the compound index. It evaluates the performance cost of both. If both indexes provide an equally efficient way to filter on 'a', the optimizer will generally prefer the smaller index to save memory and I/O resources during the traversal.

It will always use {a: 1}.

Why it fails: While likely, the optimizer's choice is not guaranteed to be 'always' the single-field index. Internal cost-based estimation (involving cache state and index size) dictates the choice. Under specific circumstances, it might select the compound index, especially if other query components favor it.

It will perform a collection scan.

Why it fails: A collection scan is the most expensive operation and is only chosen if no suitable indexes exist. Since both provided indexes can effectively filter on field 'a', the optimizer will certainly select one of them rather than defaulting to a full collection scan of the entire dataset.

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.

Run 'db.repairDatabase()' via the shell to free up space.

Why it fails: The repair command requires additional disk space to create temporary files for the restoration process. If the disk is already completely full, running repair will immediately fail and may further damage the data files. This command is not a solution for lack of available disk capacity.

Clear the 'journal' directory files to recover space.

Why it fails: Manually deleting journal files is extremely dangerous and will result in data corruption. These files are essential for ensuring the integrity of the data files after a restart. Deleting them compromises the ACID properties of the database and is never a recommended administrative recovery procedure.

Modify the 'storage.wiredTiger.engineConfig.cacheSizeGB' setting in the config file.

Why it fails: The WiredTiger cache size configures how much RAM the database uses, not the physical disk storage. Reducing the cache size will not free up disk space for data files or logs, and therefore will not resolve the 'No space left on device' error occurring at the filesystem level.

Immediately delete the /var/lib/mongodb directory.

Why it fails: Deleting the data directory before ensuring the node is fully decommissioned and the data is archived is risky. It is better to verify the node is fully removed and the remaining set is healthy before permanently destroying the local data files on the decommissioned server instance.

Force a primary election before removal.

Why it fails: Forcing an election is not a standard decommissioning step and can cause unnecessary downtime for the application. If the node to be removed is a secondary, it can be removed without affecting the primary. If it is a primary, it will step down automatically upon removal, ensuring smooth transitions.

The database automatically creates a temporary index.

Why it fails: MongoDB does not dynamically create indexes to support queries at runtime. Index creation is a deliberate administrative action. Relying on the database to automatically optimize its own index structure during a query would lead to unpredictable performance and resource exhaustion in production environments.

It defaults to a disk-based sort automatically.

Why it fails: MongoDB does not automatically spill to disk for sorting operations. If the memory limit for the sort is exceeded, the operation is simply aborted with an error. Developers must ensure that their queries use indexes to satisfy sort orders or use aggregation pipelines with 'allowDiskUse' if necessary.

The sort is performed by the client driver.

Why it fails: Sorting is a server-side operation performed by the MongoDB engine. The client driver simply receives the final result set after the server has processed the query, including any sorting requirements. The server is responsible for the computational complexity of the sort operation, not the client.

The write operation will be faster than with 'w: 1'.

Why it fails: Majority write concern is slower than 'w: 1' because it requires multiple nodes to acknowledge the write before the client proceeds. The additional network round-trips and disk I/O required for secondary nodes to process the write naturally increase the latency compared to waiting only for the primary's acknowledgement.

It forces the data to be written directly to the disk cache.

Why it fails: The 'w' parameter in write concern relates to replication acknowledgment, not disk-level caching. The 'j' (journaling) parameter controls whether the write is flushed to disk. A majority write concern ensures consensus among nodes, but it does not dictate the low-level behavior of the storage engine's write cache.

It automatically enables read-your-writes consistency for all reads.

Why it fails: Majority write concern alone does not guarantee read-your-writes consistency. For that, you also need to use an appropriate read concern, such as 'majority' or 'snapshot', to ensure the client reads the data that was written. Write concern only governs the acknowledgement of the write operation itself by the cluster.

2dsphere indexes do not support $near queries.

Why it fails: 2dsphere indexes are specifically designed to support geospatial queries, including $near and $geoWithin. The problem is not index type incompatibility, but rather the complexity of the query or the underlying data distribution, which can make geospatial search operations computationally expensive even when the correct index is present.

Geospatial indexes require a compound index on all fields.

Why it fails: Geospatial indexes are designed to work on specific coordinate fields and do not require compound indexing with other data fields to function. The performance issue in geospatial queries is almost always related to the radius of the query or the density of the documents within the queried area.

The coordinates are stored in the wrong order (latitude/longitude).

Why it fails: While coordinate order is critical (GeoJSON uses longitude/latitude), an error here would typically result in incorrect results or a query error rather than underperformance. Performance issues in this context are usually tied to the volume of data being scanned to find points within the specified distance threshold.

Use the .toArray() method on every query result to ensure data is accessible.

Why it fails: The .toArray() method loads the entire result set into the application's RAM at once. For large collections, this will likely lead to an OutOfMemory error on the application server, making it a poor choice for high-volume data retrieval tasks.

Increase the batch size to the maximum allowed by the driver.

Why it fails: Increasing the batch size to the maximum will cause a sudden spike in memory consumption on both the database server and the application server. This negates the benefits of batching and increases the risk of performance degradation or system crashes during high-traffic periods.

Store the result set in a global variable for reuse by other threads.

Why it fails: Storing large result sets in global variables creates memory leaks and concurrency issues. Since MongoDB cursors are ephemeral and tied to a session, global storage leads to stale data and prevents effective garbage collection, ultimately destabilizing the application's performance and stability.

Node 2

Why it fails: Node 2 has a priority of 0, which explicitly prevents it from becoming a primary. It can serve reads, but it will never be a candidate for an election. Therefore, it is impossible for Node 2 to win this election, regardless of the health of the other nodes in the set.

Both Node 1 and Node 2 will share the primary role.

Why it fails: A MongoDB replica set always maintains exactly one primary at any given time. The consensus protocol is designed to ensure there is no split-brain scenario where two nodes believe they are the primary. If multiple nodes could become primary, it would lead to data divergence and severe corruption.

The cluster will remain without a primary until Node 0 is repaired.

Why it fails: The replica set is designed for high availability. As long as a majority of nodes remain online, the set will automatically elect a new primary. Since two out of three nodes are still functional, the majority requirement is satisfied, and the set will proceed with an automatic election.

Temporarily stop all incoming application write operations across all mongod instances to prevent race conditions during chunk allocation.

Why it fails: Temporarily stop all incoming application write operations across all mongod instances to prevent race conditions during chunk allocation. Shard collection operations run concurrently with live application traffic without requiring cluster-wide write maintenance windows or downtime.

Run the compact command on every underlying data file to defrag storage before shard boundary calculations execute.

Why it fails: Run the compact command on every underlying data file to defrag storage before shard boundary calculations execute. Compacting data files is an unnecessary maintenance task that does not influence shard key validation or initial chunk boundary determination mechanisms.

Convert all ObjectId fields inside the target collection into standard string representations to satisfy BSON sharding constraints.

Why it fails: Convert all ObjectId fields inside the target collection into standard string representations to satisfy BSON sharding constraints. MongoDB natively supports ObjectId values as valid shard key components without requiring costly document transformations or type conversions.

The balancer requires every individual shard in the cluster to be configured as a standalone mongod instance for optimal migration speed.

Why it fails: The balancer requires every individual shard in the cluster to be configured as a standalone mongod instance for optimal migration speed. Shards in production must be configured as replica sets to ensure high availability; standalone shards are unsupported for production environments.

Disabling the balancer permanently deletes all existing chunk distribution boundaries and collapses the collection into a single unsharded file.

Why it fails: Disabling the balancer permanently deletes all existing chunk distribution boundaries and collapses the collection into a single unsharded file. Disabling the balancer merely stops automated chunk migrations; it preserves all existing chunk boundaries and data locations across the cluster shards.

Hardcoding the shard primary in the application connection string.

Why it fails: Applications should always connect via mongos instances, which abstract the cluster details. Hardcoding shard information is a dangerous practice that prevents the cluster from rebalancing data or handling failover, and it makes the application fragile and difficult to maintain as the cluster scales.

Disabling the balancer during all business hours.

Why it fails: Disabling the balancer prevents the cluster from redistributing data, which leads to hotspots. While it can be scheduled for off-peak hours, disabling it indefinitely causes severe performance issues as the data distribution becomes increasingly skewed, ultimately bottlenecking the entire database architecture.

Using the same shard key for every collection in the database.

Why it fails: Choosing the best shard key depends on the access patterns and data distribution of each individual collection. Forcing a single key for all collections can lead to suboptimal performance for specific queries and does not account for the varying requirements of different application datasets.

The ability to store binary data as BSON.

Why it fails: Many key-value stores also support binary data blobs. Storing binary data is a feature of many databases and does not uniquely distinguish MongoDB's document model. The differentiator is the ability to query inside the structure, rather than just storing opaque data blobs.

The use of a primary key for document retrieval.

Why it fails: Key-value stores use primary keys for retrieval as their core operation. Relying on the `_id` field as a primary key is standard across many databases, including both MongoDB and key-value stores, and therefore does not serve as a distinguishing feature between these technologies.

The support for horizontal scaling across clusters.

Why it fails: Many key-value stores are explicitly built for massive horizontal scale, often exceeding the capabilities of relational databases. Horizontal scaling is a common trait in modern distributed systems, and is not exclusive to document databases like MongoDB.

The target database has not been enabled for sharding using the enableSharding administrative command.

Why it fails: Sharding a collection requires the database to be sharded first; without enableSharding, shardCollection returns the error shown. It is tempting because enableSharding is genuinely required, but the stem's error points to the collection already existing as unsharded, so the missing step is a different prerequisite.

The specified shard key contains an unsupported array field that violates BSON multi-key index constraints.

Why it fails: The specified shard key contains an unsupported array field that violates BSON multi-key index constraints. While array fields can cause sharding restrictions, this specific error code explicitly points to the complete absence of a matching index prefix.

The config server replica set is currently undergoing an election and cannot process metadata write operations.

Why it fails: Election of the config server replica set does not block shardCollection; metadata writes continue through the primary. It is tempting because elections disrupt availability, but the actual cause is that sharding requires the collection to be empty or indexed on the shard key, which the error indicates.

The chunk migration threshold was set too low, causing frequent balancing cycles across shards.

Why it fails: Chunk balancing affects data distribution and migration overhead across cluster nodes, but it does not cause targeted queries to transform into scatter-gather operations. Routing behavior depends strictly on the presence of the shard key in the query predicate.

The collection was created as unhashed, preventing the mongos router from hashing query inputs.

Why it fails: Whether a shard key uses hashed or ranged distribution, omitting the shard key from the query filter always results in a scatter-gather query. The choice of sharding strategy alone does not dictate query routing behavior when predicates lack key fields.

The balancer process was paused, leaving uneven document distribution across cluster shards.

Why it fails: An unbalanced cluster may cause some shards to handle heavier workloads than others, but queries that explicitly include the shard key will still route directly to the appropriate shard rather than executing cluster-wide scatter-gather requests.