Scenario practice questions

In a three-node replica set with default write concerns, what occurs when the primary node experiences a network partition and cannot communicate with the majority of the set?

Trap 1: The primary continues accepting writes until the partition is…

A primary node that cannot reach a majority of its voting members will automatically step down to secondary status. This behavior is a core safety mechanism in MongoDB to prevent stale reads and inconsistent writes in the event of a network failure or a total loss of cluster quorum.

Trap 2: The primary immediately crashes and shuts down the mongod process.

MongoDB does not shut down the mongod process when a partition occurs. Instead, it transitions the primary into a secondary state where it can no longer accept writes, preserving the existing data and allowing it to catch up on replication logs once network connectivity is restored to the set.

Trap 3: The secondary nodes force a rollback on the primary node.

Rollbacks only occur when a former primary rejoins the set and must revert uncommitted operations to match the current majority-confirmed data. The primary node stepping down during a partition is a graceful state transition, not an automatic rollback process, as the existing primary was simply unable to reach majority consensus.

A
The primary continues accepting writes until the partition is resolved.
Why it fails: A primary node that cannot reach a majority of its voting members will automatically step down to secondary status. This behavior is a core safety mechanism in MongoDB to prevent stale reads and inconsistent writes in the event of a network failure or a total loss of cluster quorum.
B
The primary immediately crashes and shuts down the mongod process.
Why it fails: MongoDB does not shut down the mongod process when a partition occurs. Instead, it transitions the primary into a secondary state where it can no longer accept writes, preserving the existing data and allowing it to catch up on replication logs once network connectivity is restored to the set.
C
The primary steps down to secondary status, and the set elects a new primary.
When a primary node detects that it can no longer see a majority of the voting members, it transitions to a secondary state. This is essential for cluster health because it allows the remaining nodes in the replica set to hold an election and select a new primary to handle operations.
D
The secondary nodes force a rollback on the primary node.
Why it fails: Rollbacks only occur when a former primary rejoins the set and must revert uncommitted operations to match the current majority-confirmed data. The primary node stepping down during a partition is a graceful state transition, not an automatic rollback process, as the existing primary was simply unable to reach majority consensus.

Question 2easymultiple choice

Which member type in a MongoDB replica set is best suited for a geographically distant data center to provide read-only access without influencing elections?

Trap 1: Arbiter

Arbiters do not store data; they only participate in elections. Using an arbiter in a remote data center would provide no benefit for read operations, as they are not designed to serve client queries. They exist solely to help the replica set achieve a majority vote for electing new primaries.

Trap 2: Hidden Member

While a hidden member does not receive traffic from the mongos or client drivers, it is not optimized for read performance. Furthermore, hidden members can still become primary if their priority is greater than zero, which could cause significant latency issues if a node in a remote region becomes the primary.

Trap 3: Delayed Secondary

A delayed secondary is primarily used for disaster recovery, keeping data that is intentionally behind the primary to protect against human error or accidental deletions. Its data is not current, making it unsuitable for applications that require low-latency access to the latest data in a remote geographic region.

A
Arbiter
Why it fails: Arbiters do not store data; they only participate in elections. Using an arbiter in a remote data center would provide no benefit for read operations, as they are not designed to serve client queries. They exist solely to help the replica set achieve a majority vote for electing new primaries.
B
Hidden Member
Why it fails: While a hidden member does not receive traffic from the mongos or client drivers, it is not optimized for read performance. Furthermore, hidden members can still become primary if their priority is greater than zero, which could cause significant latency issues if a node in a remote region becomes the primary.
C
Priority 0 Secondary
A priority 0 secondary cannot be elected primary, making it perfect for remote sites. It maintains a full copy of the data, which allows it to serve read requests locally. Because it cannot become primary, it eliminates the risk of a high-latency node taking control of the entire cluster's operations.
D
Delayed Secondary
Why it fails: A delayed secondary is primarily used for disaster recovery, keeping data that is intentionally behind the primary to protect against human error or accidental deletions. Its data is not current, making it unsuitable for applications that require low-latency access to the latest data in a remote geographic region.

Question 3hardmultiple choice

A social media platform uses MongoDB to store user posts. Each post document contains an array of comments. The platform's engineers notice that some posts have tens of thousands of comments, causing documents to approach the 16 MB size limit and degrading read performance. They want to redesign the schema to handle this growth while preserving the ability to retrieve a post with its most recent comments efficiently. Which approach best aligns with MongoDB's schema design philosophy?

Trap 1: Store each comment as a separate document in the same collection…

Storing comments in the same collection as posts would mix different document types, complicating queries and indexing. While referencing is valid, it would require additional queries to fetch comments for a post, and the same collection would contain heterogeneous documents. This approach does not leverage embedding for the common case and can lead to inefficient queries, making it less aligned with MongoDB's design philosophy.

Trap 2: Increase the document size limit by configuring the storage engine…

The 16 MB document size limit is a hard limit in MongoDB and cannot be increased by configuration. Attempting to do so is not possible. This option is a distractor because it suggests a non-existent configuration change. The correct approach is to redesign the schema to work within the limit, not to try to bypass it, which is impossible.

Trap 3: Store all comments in a separate collection and use $lookup to join…

Using $lookup to join comments for every post retrieval introduces significant overhead, especially at scale. While it avoids document size limits, it contradicts the philosophy of storing data that is accessed together in the same document. Frequent $lookup operations can be slow and resource-intensive, and they do not provide the efficiency of embedded data for the common case of fetching a post with its comments.

A
Embed only the most recent comments in the post document and store older comments in a separate collection.
This hybrid approach, known as the outlier pattern or subset pattern, embeds a limited number of recent comments to keep the document small and fast to read, while storing the full set in a separate collection for archival or pagination. It aligns with MongoDB's philosophy by optimizing for the common access pattern (viewing recent comments) while avoiding unbounded document growth. This design balances performance and scalability.
B
Store each comment as a separate document in the same collection and use a parent reference to link them to the post.
Why it fails: Storing comments in the same collection as posts would mix different document types, complicating queries and indexing. While referencing is valid, it would require additional queries to fetch comments for a post, and the same collection would contain heterogeneous documents. This approach does not leverage embedding for the common case and can lead to inefficient queries, making it less aligned with MongoDB's design philosophy.
C
Increase the document size limit by configuring the storage engine to allow larger BSON documents.
Why it fails: The 16 MB document size limit is a hard limit in MongoDB and cannot be increased by configuration. Attempting to do so is not possible. This option is a distractor because it suggests a non-existent configuration change. The correct approach is to redesign the schema to work within the limit, not to try to bypass it, which is impossible.
D
Store all comments in a separate collection and use $lookup to join them when needed.
Why it fails: Using $lookup to join comments for every post retrieval introduces significant overhead, especially at scale. While it avoids document size limits, it contradicts the philosophy of storing data that is accessed together in the same document. Frequent $lookup operations can be slow and resource-intensive, and they do not provide the efficiency of embedded data for the common case of fetching a post with its comments.

Question 4easymultiple choice

Which read concern provides the strongest consistency guarantee by ensuring the data returned has been acknowledged by a majority of the replica set?

Trap 1: local

The 'local' read concern returns data from the node's local view without checking if the data has been acknowledged by a majority of the replica set. While it is the most performant option, it is susceptible to reading data that could be rolled back after a primary failure.

Trap 2: available

The 'available' read concern returns data with no consistency guarantees, even potentially returning orphaned data in sharded clusters. It is designed for maximum performance in read-heavy applications where consistency is not a priority, and it is entirely unsuitable for applications requiring strong data integrity or accurate reporting.

Trap 3: snapshot

The 'snapshot' read concern provides multi-document transaction consistency. While it is stronger than 'majority', it is only available within the context of a multi-document transaction. For a standalone read request, 'majority' is the highest standard of consistency available to ensure the data is durable and will not be rolled back.

A
local
Why it fails: The 'local' read concern returns data from the node's local view without checking if the data has been acknowledged by a majority of the replica set. While it is the most performant option, it is susceptible to reading data that could be rolled back after a primary failure.
B
available
Why it fails: The 'available' read concern returns data with no consistency guarantees, even potentially returning orphaned data in sharded clusters. It is designed for maximum performance in read-heavy applications where consistency is not a priority, and it is entirely unsuitable for applications requiring strong data integrity or accurate reporting.
C
majority
The 'majority' read concern ensures that the returned data is committed to a majority of the replica set, preventing reads of data that could be rolled back. It is the best choice for ensuring strong consistency in a distributed system, even if it introduces slightly more latency than lower-consistency levels.
D
snapshot
Why it fails: The 'snapshot' read concern provides multi-document transaction consistency. While it is stronger than 'majority', it is only available within the context of a multi-document transaction. For a standalone read request, 'majority' is the highest standard of consistency available to ensure the data is durable and will not be rolled back.

Question 5hardmulti select

A logistics company is designing a MongoDB database for a real-time shipment tracking system. The operations team needs to frequently update shipment statuses and query the latest events. The development team is debating the trade-offs of embedding versus referencing for the shipment events. Which two considerations align with MongoDB's philosophy for this scenario? (Choose two.)

Trap 1: Embedding events is always preferred because it eliminates the need…

While embedding can reduce the need for multi-document transactions by keeping related data in one document, it is not always preferred. If events grow without bound, embedding can lead to document size issues and performance degradation. The decision should be based on access patterns, data growth, and atomicity requirements, not an absolute rule.

Trap 2: Referencing events requires using $lookup for every read, which is…

$lookup performs a left outer join, which is generally slower than reading an embedded document because it involves additional processing and potentially multiple shards. While $lookup is powerful, it does not match the performance of a single-document read. Therefore, referencing is not a direct substitute for embedding when read speed is critical.

Trap 3: Embedding events ensures that the shipment document remains small…

Embedding events actually increases the size of the shipment document as events are added. If events are frequently added, the document can grow large, leading to more expensive updates and potential fragmentation. To keep documents small, referencing events in a separate collection is a better strategy when event volume is high.

A
Embedding events within the shipment document ensures atomic updates and fast reads for the event history.
Embedding events in the shipment document allows the application to retrieve the entire event history with a single query, and updates to the shipment and its events can be atomic within a single document. This aligns with MongoDB's philosophy of storing data that is accessed together. However, it requires monitoring document growth to avoid hitting the 16 MB limit, especially if events are unbounded.
B
Embedding events is always preferred because it eliminates the need for multi-document transactions.
Why it fails: While embedding can reduce the need for multi-document transactions by keeping related data in one document, it is not always preferred. If events grow without bound, embedding can lead to document size issues and performance degradation. The decision should be based on access patterns, data growth, and atomicity requirements, not an absolute rule.
C
Referencing events requires using $lookup for every read, which is as fast as an embedded document read.
Why it fails: $lookup performs a left outer join, which is generally slower than reading an embedded document because it involves additional processing and potentially multiple shards. While $lookup is powerful, it does not match the performance of a single-document read. Therefore, referencing is not a direct substitute for embedding when read speed is critical.
D
Embedding events ensures that the shipment document remains small and efficient for writes.
Why it fails: Embedding events actually increases the size of the shipment document as events are added. If events are frequently added, the document can grow large, leading to more expensive updates and potential fragmentation. To keep documents small, referencing events in a separate collection is a better strategy when event volume is high.
E
Referencing events in a separate collection allows unlimited growth and avoids the 16 MB document size limit.
Referencing events in a separate collection prevents the shipment document from growing unbounded, which is crucial if events accumulate indefinitely. This approach avoids the 16 MB size limit and allows independent querying of events. However, it requires additional queries or $lookup to join data, which can impact performance. The choice depends on access patterns and growth expectations.

Question 6mediummultiple choice

You are the DBA for a three-member MongoDB replica set. The primary becomes unreachable due to a network partition, and two secondaries remain in communication. After the election timeout, one secondary is elected primary. What is the required condition for a new primary to be elected?

Trap 1: Any secondary with the highest priority automatically becomes…

Priority influences which eligible secondary is elected, but it does not bypass the majority requirement. Without a majority of voting members, no election can succeed regardless of priority. If a majority is not available, the remaining members remain secondaries, and the replica set cannot accept writes.

Trap 2: The arbiter, if present, must vote and can be the sole voter to…

An arbiter can vote but cannot become primary and does not store data. However, an arbiter alone cannot elect a primary; a majority of all voting members (including arbiters) must still participate. In a three-member set with one arbiter, the arbiter plus one data-bearing member can form a majority, but the arbiter alone cannot.

Trap 3: The secondary with the most recent oplog entry is elected primary…

The most recent oplog entry helps determine the best candidate, but a single member cannot elect itself. MongoDB requires a majority of voting members to be present. Even if a secondary has the most recent oplog, it cannot become primary alone, preventing a situation where a minority partition elects a primary and causes divergent data.

A
Any secondary with the highest priority automatically becomes primary without needing a majority.
Why it fails: Priority influences which eligible secondary is elected, but it does not bypass the majority requirement. Without a majority of voting members, no election can succeed regardless of priority. If a majority is not available, the remaining members remain secondaries, and the replica set cannot accept writes.
B
The arbiter, if present, must vote and can be the sole voter to elect a primary.
Why it fails: An arbiter can vote but cannot become primary and does not store data. However, an arbiter alone cannot elect a primary; a majority of all voting members (including arbiters) must still participate. In a three-member set with one arbiter, the arbiter plus one data-bearing member can form a majority, but the arbiter alone cannot.
C
The secondary with the most recent oplog entry is elected primary even if it is the only member available.
Why it fails: The most recent oplog entry helps determine the best candidate, but a single member cannot elect itself. MongoDB requires a majority of voting members to be present. Even if a secondary has the most recent oplog, it cannot become primary alone, preventing a situation where a minority partition elects a primary and causes divergent data.
D
A majority of voting members must be available and able to communicate.
In MongoDB, a new primary is elected only if a majority of voting members are available and can communicate. In a three-member replica set, two voting members must be reachable. This ensures that the replica set does not split-brain and that the elected primary has the most recent data, as it must have the highest optime among the majority.

Question 7mediummultiple choice

What happens to the replica set if a majority of voting members are permanently lost?

Trap 1: The set automatically switches to a single-node mode to remain…

MongoDB does not automatically degrade to single-node mode when a majority is lost, as this would violate the consistency requirements for write operations. The set remains in a read-only state to prevent inconsistent data from being written while the cluster lacks a quorum for confirming those operations.

Trap 2: The secondary nodes elect a new primary regardless of the missing…

The voting protocol strictly requires a majority. A node cannot become primary without receiving votes from more than half of the configured voting members. This is the core mechanism that guarantees durability and consistency in the face of network partitions or hardware failures within the replica set infrastructure.

Trap 3: The primary node continues to accept writes for a short period.

If the primary itself is part of the minority, it will immediately step down and stop accepting writes. The entire goal of the consensus protocol is to ensure that no writes occur unless a majority can guarantee the operation. Once a majority is lost, all write activity effectively ceases.

A
The set automatically switches to a single-node mode to remain functional.
Why it fails: MongoDB does not automatically degrade to single-node mode when a majority is lost, as this would violate the consistency requirements for write operations. The set remains in a read-only state to prevent inconsistent data from being written while the cluster lacks a quorum for confirming those operations.
B
The set stops accepting writes to maintain consistency.
Without a majority, the remaining nodes cannot achieve consensus for write operations. To prevent split-brain and maintain consistent data, the replica set stops accepting writes. This ensures that no data is committed until the cluster can confirm that a quorum of nodes has successfully processed the operation.
C
The secondary nodes elect a new primary regardless of the missing majority.
Why it fails: The voting protocol strictly requires a majority. A node cannot become primary without receiving votes from more than half of the configured voting members. This is the core mechanism that guarantees durability and consistency in the face of network partitions or hardware failures within the replica set infrastructure.
D
The primary node continues to accept writes for a short period.
Why it fails: If the primary itself is part of the minority, it will immediately step down and stop accepting writes. The entire goal of the consensus protocol is to ensure that no writes occur unless a majority can guarantee the operation. Once a majority is lost, all write activity effectively ceases.

Question 8hardmultiple choice

Refer to the exhibit. An administrator attempts to recover a corrupted standalone mongod instance using the --repair flag. Based on the error log output, what is the most appropriate next step for the administrator?

Network Topology

Trap 1: Run the --repair command again with the --wiredTigerEngineConfig…

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.

Trap 2: Delete the mongod.lock file and restart the server normally.

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.

Trap 3: Manually edit the WiredTiger.wt file to fix the offset error.

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.

A
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.
B
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.
C
Restore the data files from the most recent known-good backup.
Since the --repair process failed with a critical WiredTiger read error, the data files are too corrupted for the built-in tools to salvage. The most reliable and standard administrative response is to wipe the corrupted directory and restore the database from a verified backup to ensure consistency.
D
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.

Question 9easymultiple choice

Which feature of MongoDB allows it to maintain data consistency during primary node failure?

Trap 1: Manual shard intervention by the administrator.

Manual intervention is not the primary way MongoDB ensures consistency. Replica sets are designed to be self-healing, utilizing automated elections to restore service. Requiring manual intervention would negate the benefits of a distributed system designed for high availability and minimal operational downtime during outages.

Trap 2: The use of a secondary index for read-only access.

While secondary nodes can handle read-only traffic, this is a performance feature, not a mechanism for maintaining consistency during failover. Consistency is maintained through the replication protocol, which synchronizes data across all nodes, not through the act of querying the secondary nodes.

Trap 3: The mongos router forcing a global write lock.

The mongos router does not enforce global locks during failover. MongoDB uses granular, document-level concurrency control in the WiredTiger engine. Global locks were eliminated in early versions to improve performance, and mongos is strictly a routing component for sharded clusters, not a lock manager.

A
Manual shard intervention by the administrator.
Why it fails: Manual intervention is not the primary way MongoDB ensures consistency. Replica sets are designed to be self-healing, utilizing automated elections to restore service. Requiring manual intervention would negate the benefits of a distributed system designed for high availability and minimal operational downtime during outages.
B
Automatic failover via replica set elections.
Replica set elections are the core mechanism for handling failures. When a primary node fails, the secondary nodes automatically initiate an election to select a new primary. This ensures that the system continues to accept writes with minimal disruption, maintaining consistency across the distributed environment.
C
The use of a secondary index for read-only access.
Why it fails: While secondary nodes can handle read-only traffic, this is a performance feature, not a mechanism for maintaining consistency during failover. Consistency is maintained through the replication protocol, which synchronizes data across all nodes, not through the act of querying the secondary nodes.
D
The mongos router forcing a global write lock.
Why it fails: The mongos router does not enforce global locks during failover. MongoDB uses granular, document-level concurrency control in the WiredTiger engine. Global locks were eliminated in early versions to improve performance, and mongos is strictly a routing component for sharded clusters, not a lock manager.

Question 10hardmulti select

Which TWO of the following scenarios are best handled by a Hashed Index?

Trap 1: Range-based queries on numeric fields.

Hashed indexes are completely ineffective for range queries because the hash function loses the natural order of the data. Values that are numerically close in the collection will be mapped to entirely different hash buckets, making it impossible to perform efficient range scans using a hashed index.

Trap 2: Sorting results by the indexed field.

Because hashed indexes scramble the order of the values, they cannot be used to satisfy sort requirements. If a query requires a sort on a hashed field, MongoDB will have to perform an in-memory sort or use a different index, resulting in performance overhead.

Trap 3: Text search on long strings.

Text searching requires specialized text indexes that support tokenization and linguistic analysis. Hashed indexes simply hash the entire string, which would only support exact equality matching on the entire field content, not the complex sub-string or keyword searching required for typical text-based document searches.

A
Range-based queries on numeric fields.
Why it fails: Hashed indexes are completely ineffective for range queries because the hash function loses the natural order of the data. Values that are numerically close in the collection will be mapped to entirely different hash buckets, making it impossible to perform efficient range scans using a hashed index.
B
Sharding a collection on a high-cardinality key.
Hashed indexes are the industry standard for sharding keys to ensure an even distribution of data across shards. By hashing the shard key, you prevent the 'hot shard' problem, ensuring that writes are spread out across all nodes in the cluster, which is vital for scalability.
C
Equality lookups on unique values.
Hashed indexes are very performant for single-value equality lookups. Since the hash value maps directly to the location of the document, the lookup is highly efficient. This makes them an excellent choice for fields used to fetch individual records frequently, provided range queries are not needed.
D
Sorting results by the indexed field.
Why it fails: Because hashed indexes scramble the order of the values, they cannot be used to satisfy sort requirements. If a query requires a sort on a hashed field, MongoDB will have to perform an in-memory sort or use a different index, resulting in performance overhead.
E
Text search on long strings.
Why it fails: Text searching requires specialized text indexes that support tokenization and linguistic analysis. Hashed indexes simply hash the entire string, which would only support exact equality matching on the entire field content, not the complex sub-string or keyword searching required for typical text-based document searches.

Question 11mediummultiple choice

What is the primary purpose of an Arbiter in a MongoDB replica set?

Trap 1: To serve as a standby node for automatic failover.

Arbiters cannot become primary nodes because they do not contain any data. They do not act as standby nodes for failover in the sense of taking over write traffic; they only exist to contribute a vote during an election, helping the set reach the required majority to elect a primary.

Trap 2: To provide read-only access to the database.

Arbiters do not store data, so they cannot serve read requests. Any attempt by a client driver to route read operations to an arbiter will fail because there is no collection data for the arbiter to query, making it strictly a voting participant in the replica set infrastructure.

Trap 3: To replicate data from the primary to secondary nodes.

Arbiters are not part of the data replication stream. They do not receive or store oplog entries. The replication process happens between the primary and the data-bearing secondary nodes. The arbiter is strictly involved in the cluster's membership and health-management logic, specifically regarding the election of a new primary node.

A
To serve as a standby node for automatic failover.
Why it fails: Arbiters cannot become primary nodes because they do not contain any data. They do not act as standby nodes for failover in the sense of taking over write traffic; they only exist to contribute a vote during an election, helping the set reach the required majority to elect a primary.
B
To participate in elections and help achieve a majority.
The arbiter exists strictly to vote in elections. In a replica set, elections require a majority of voting members to succeed. By adding an arbiter, you increase the number of voting members, which can help reach that majority quorum without the cost or storage requirements of a full-data node.
C
To provide read-only access to the database.
Why it fails: Arbiters do not store data, so they cannot serve read requests. Any attempt by a client driver to route read operations to an arbiter will fail because there is no collection data for the arbiter to query, making it strictly a voting participant in the replica set infrastructure.
D
To replicate data from the primary to secondary nodes.
Why it fails: Arbiters are not part of the data replication stream. They do not receive or store oplog entries. The replication process happens between the primary and the data-bearing secondary nodes. The arbiter is strictly involved in the cluster's membership and health-management logic, specifically regarding the election of a new primary node.