Refer to the Exhibit Practice Questions

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.

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.

It forces data normalization for better storage efficiency.

Why it fails: This approach is the opposite of normalization. By embedding the array directly, the data is denormalized. While this can increase storage usage slightly, it significantly improves read performance by avoiding joins, which is a deliberate trade-off in MongoDB to favor application performance and data locality.

It enforces referential integrity between products and tags.

Why it fails: Referential integrity is not enforced for embedded data structures. MongoDB does not automatically validate the existence of tags or maintain links between collections. This responsibility is delegated to the application layer, which is a common trade-off for the performance gains achieved by avoiding cross-collection relational constraints.

It requires a multi-document transaction to update the tags.

Why it fails: Updating an array within a single document is an atomic operation performed on that document. No multi-document transaction is required. Because the update is scoped to one document, it is highly efficient and avoids the performance penalties associated with distributed transaction coordination across multiple collections or nodes.

It will always use both indexes simultaneously.

Why it fails: While index intersection is supported, it is not guaranteed. The MongoDB query optimizer evaluates the cost of intersection versus scanning a single index or collection. It will only perform an intersection if the estimated cost is lower than other available plans, which is not guaranteed for every query.

It will fail because compound indexes are required.

Why it fails: MongoDB does not strictly require a compound index for queries involving multiple fields. It is perfectly legal to have separate indexes on distinct fields. The query will execute successfully, either by using one of the indexes or potentially by performing an index intersection if the optimizer deems it optimal.

It will ignore all indexes and scan the collection.

Why it fails: The query will not automatically default to a collection scan unless the optimizer determines that using the available indexes is more expensive than reading the entire collection. Since indexes exist, they will be evaluated as potential candidates for the query execution plan, provided they match the filtering criteria.

It stores a copy of the data and can serve read queries.

Why it fails: Arbiters do not contain data files or the capacity to sync data from the primary. They are intentionally designed to be lightweight, meaning they cannot participate in read scaling or serve as a redundant data source. Their sole purpose is to contribute a vote to the replica set consensus.

It performs automatic failover by hosting a redundant copy of the oplog.

Why it fails: Arbiters do not maintain an oplog, nor do they process any data replication. They are strictly limited to the voting process. If the primary fails, the arbiter helps elect a new primary, but it does not participate in the actual data recovery or the synchronization of the new primary.

It acts as a load balancer for incoming read requests.

Why it fails: Arbiters are not part of the read-routing path. Incoming read requests are handled by the primary or secondaries depending on the read preference. Since an arbiter does not hold data, it cannot answer queries, nor does it have any networking components configured to proxy or balance traffic for clients.

Normalization for maximum data consistency.

Why it fails: Normalization involves splitting data into separate entities to reduce redundancy. This document is denormalized because the sensor readings are included within the sensor metadata, prioritizing performance and retrieval efficiency over the strict normalization found in traditional relational database management systems.

Enforcement of a rigid schema using array types.

Why it fails: MongoDB's philosophy centers on schema flexibility, not rigid enforcement. While the array type is used here, the database does not force other documents to contain an array of the same length or data type, highlighting the dynamic nature of the document model over strict relational schemas.

The use of an Oplog to track document changes.

Why it fails: The Oplog is an internal MongoDB mechanism for replication, not a feature represented by the document structure itself. While the document will trigger Oplog entries upon update, the structure shown is about data modeling philosophy, not the underlying replication mechanics of the replica set.

The query is fully optimized because it leverages an index scan for filtering records.

Why it fails: While the IXSCAN stage successfully filters records using the status index, the presence of an outer SORT stage indicates that the index could not order the results. This necessitates an in-memory sorting operation, which is suboptimal.

The query executed a full collection scan across all cluster nodes.

Why it fails: IXSCAN confirms an index was used, so no COLLSCAN occurred, and MongoDB sharded clusters distribute collections across shards rather than scanning every node for this plan. The option tempts when index selection fails, which would show COLLSCAN instead of IXSCAN in the explain output.

The storage engine automatically converted the query into a covered query.

Why it fails: A SORT stage above IXSCAN means the index supplied sort order was insufficient, so the engine sorts results in memory after fetching documents. Covered queries eliminate the FETCH stage instead, projecting all fields from the index itself; the plan shows no such projection, so no automatic conversion occurred.

MongoDB uses a proprietary, non-standard transport protocol.

Why it fails: MongoDB uses a standard wire protocol based on TCP/IP. This openness allows for the creation of drivers across many languages, which is a core philosophy of the platform. Using a proprietary protocol would limit adoption and force developers into specific, vendor-provided tools.

All clients must be authenticated via a central service.

Why it fails: While authentication is a critical security feature, the log entry shows the connection acceptance phase. The protocol itself is agnostic to the authentication mechanism, which is a separate layer. The connection is a technical prerequisite, not an authentication policy enforcement.

The database requires persistent, long-lived connections.

Why it fails: While connection pooling is a best practice, the log simply records the acceptance of a TCP connection. It does not mandate how long that connection stays open or whether it is persistent. The database treats connections as resources to be managed, regardless of their duration.

It forces the update to occur only on the primary node.

Why it fails: Write concern defines the acknowledgment level, not the node selection. Updates are always directed to the primary node in a replica set. The 'majority' setting ensures the primary has successfully replicated the change to a sufficient number of secondary nodes before confirming success to the client application.

It only updates documents that have a majority of fields set.

Why it fails: Write concern is a configuration for acknowledgment, not a filter for the documents being updated. It has no impact on which documents match the query criteria. The update will apply to all documents where 'active' is false, regardless of how many fields are present in the documents.

It makes the update operation read-only.

Why it fails: Write concern is strictly for write operations. It has nothing to do with read permissions or the type of operation being performed. The operation is a valid update, and the write concern simply specifies the durability guarantee level for the confirmation of that write to the client application.

The query is fully covered by an index.

Why it fails: A covered query would show an IXSCAN in the plan summary and totalDocsExamined would be zero. Because this query shows a COLLSCAN and totalDocsExamined equals nReturned, the system is reading every document in the collection, which is the least efficient way to retrieve data in MongoDB.

The query is performing well because nReturned equals totalDocsExamined.

Why it fails: While it is good that the database isn't examining documents it doesn't return, a COLLSCAN on a large collection is still highly inefficient compared to an index scan. It implies that the database must perform full disk I/O to check every document, which does not scale well with collection growth.

The index is being used, but it is not selective enough.

Why it fails: The plan summary explicitly states COLLSCAN, meaning no index was used at all. If an index were used but lacked selectivity, the plan summary would show IXSCAN, and totalDocsExamined would be significantly higher than nReturned, indicating that the index narrowed the result set but still required document inspection.

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.

Run the --repair command again with the --wiredTigerEngineConfig option.

Why it fails: Running the repair command a second time with different engine configurations will not resolve a 'Short read' error, which indicates that the underlying data blocks are physically missing or inaccessible. Additional flags cannot reconstruct data that the storage engine cannot physically read from the disk subsystem.

Delete the mongod.lock file and restart the server normally.

Why it fails: Deleting the lock file and attempting a normal restart is dangerous and will likely fail if the data files are corrupted. The 'Short read' error already proves that the data files are in an inconsistent state, and bypassing the repair process could lead to further data loss or silent corruption.

Manually edit the WiredTiger.wt file to fix the offset error.

Why it fails: The internal structure of WiredTiger data files is complex and binary. Attempting to manually edit these files with a hex editor or other tools is not supported and is virtually certain to cause total data loss. Administrators should never attempt to modify MongoDB data files directly outside of official tools.

The query is hitting the primary index limit.

Why it fails: There is no such thing as a 'primary index limit' in MongoDB. The performance issue here is caused by the absence of an appropriate index for the query filter, which forces the engine to perform a full collection scan rather than looking up the specific document via an index entry.

The query is being blocked by a write lock.

Why it fails: Write locks prevent other operations from accessing the collection, but they do not manifest as a 'COLLSCAN' in the explain output. The explain output describes how the query is executed, and a scan indicates a query planning issue related to indexing, not a concurrency contention issue within the database.

The database is out of memory.

Why it fails: While memory pressure can slow down queries, the execution plan shows that the engine specifically chose a full collection scan. If memory were the issue, you might see disk spill errors or high cache eviction rates, but the query plan itself would reflect an index scan if a proper index existed.

Increase the RAM allocated to the mongod process configuration.

Why it fails: The 100MB limit for aggregation stages is a hardcoded constraint in MongoDB. Increasing the overall RAM available to the mongod process does not change this limit, meaning the error will persist regardless of the available system memory unless allowDiskUse is used.

Remove the $group stage and perform the grouping in application code.

Why it fails: Moving the grouping logic to the application is highly inefficient as it requires transferring massive amounts of raw data over the network. This increases latency and consumes application memory, which is exactly what the database aggregation framework is designed to avoid.

Reduce the batch size in the cursor options.

Why it fails: Batch size affects the data transfer rate between the server and client, but it has no impact on the internal memory usage of the aggregation pipeline stages. Reducing it will not prevent the $group memory limit error, which is an internal server-side processing constraint.

{ tags: 'hashed' }

Why it fails: Hashed indexes are intended for equality lookups of single values and do not support range queries or array contents. Using a hashed index on an array field would not allow for the efficient retrieval of multiple elements, rendering the query inefficient and likely forcing a collection scan.

{ tags: 1, _id: 1 }

Why it fails: While this compound index is valid, it adds unnecessary overhead to the index size by including the _id field. Since the query only filters on 'tags', a simple single-field multikey index is more space-efficient and provides the same query performance, avoiding unnecessary storage consumption.

No index is required for array fields.

Why it fails: Failing to index array fields will result in full collection scans, which are extremely performance-intensive as the dataset grows. To maintain high performance for queries involving array elements, an index is essential to avoid scanning every document in the collection to check the contents of the tags array.