Select Two (Multi-Select) Questions

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.

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.

Requirement for strict normalization of all data.

Why it fails: Normalization is the hallmark of relational databases. In MongoDB, denormalization is often encouraged to optimize for performance. Requiring normalization would force developers to use multiple joins, which undermines the primary performance and simplicity benefits of the document model's design philosophy for high-concurrency, web-scale applications.

Guaranteed consistency through mandatory schema migrations.

Why it fails: Schema migrations are a significant pain point in relational databases. MongoDB's schema-less model eliminates the need for these migrations, which is a major benefit for developer productivity. Suggesting that mandatory migrations are a benefit is factually incorrect as they represent administrative overhead and potential downtime.

Automatic translation of SQL queries to BSON.

Why it fails: MongoDB does not automatically translate SQL to BSON. While some middleware tools exist, the database natively uses the MongoDB Query Language (MQL). This is not a benefit of the model itself; rather, it represents a fundamental difference in the query interfaces between the two database types.

A dedicated primary balancer coordinator node running outside the config server replica set to manage migrations.

Why it fails: A dedicated primary balancer coordinator node running outside the config server replica set to manage migrations. The balancing process is coordinated internally by the primary member of the config server replica set, eliminating the need for an external standalone balancer daemon.

An independent Apache ZooKeeper quorum cluster to coordinate distributed locking across all participating mongod nodes.

Why it fails: An independent Apache ZooKeeper quorum cluster to coordinate distributed locking across all participating mongod nodes. MongoDB uses its internal config servers and replica set consensus mechanisms rather than external orchestration tools like ZooKeeper for cluster coordination.

Strict, static schema enforcement at the storage layer.

Why it fails: MongoDB is intentionally designed to be schema-flexible, not schema-strict. Storing data without a fixed schema is a foundational design choice that allows for rapid iteration and agility. Enforcing strict static schemas at the storage layer would contradict the core philosophy of the document model and limit developer speed.

Global dependency on a single centralized primary node.

Why it fails: MongoDB is a distributed system designed for resilience. While replica sets have a primary node, the system is not dependent on a single global primary. It supports distributed deployments and geographic distribution to ensure that the system remains operational even in the face of widespread regional failures.

readAnyDatabase

Why it fails: The 'readAnyDatabase' role provides read access to every document in every collection across the entire server. This explicitly violates the requirement that the user should not be able to read actual document data, making it an inappropriate choice for a restricted monitoring or backup user.

dbAdmin

Why it fails: The 'dbAdmin' role allows for administrative tasks like index creation and collection deletion within a specific database. However, it does not inherently grant the cluster-wide monitoring permissions needed by many tools, and it also does not provide the specific privileges required to perform a full system backup.

hostManager

Why it fails: The 'hostManager' role provides more aggressive administrative capabilities, such as shutting down the server or managing services. This exceeds the requirements for a monitoring tool and introduces unnecessary risk, as a monitoring user should generally not have the power to alter the server's operational state.

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.

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.

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.

Upsert cannot be used with update operators that modify array elements, such as $push.

Why it fails: Upsert works with array update operators. For example, an upsert with $push on a non-matching filter inserts a new document containing the array with the pushed element. There is no general prohibition against array operators in upserts. This statement is incorrect and would unnecessarily limit the use of upsert in application code.

If multiple documents match the filter, upsert updates all of them and inserts no new document.

Why it fails: With updateOne and upsert, if multiple documents match, only one is updated and no insert occurs. With updateMany and upsert, all matching documents are updated and still no insert occurs. The statement is misleading because it implies a general rule, but the key point is that upsert only inserts when there are zero matches, not that it updates all matches.

Upsert always requires a unique index on the filter fields to avoid duplicate inserts.

Why it fails: A unique index is not required for upsert to function. However, without a unique index, concurrent upserts can both fail to match and both insert, producing duplicates. The unique index prevents that race condition but is not a prerequisite for the operation itself. The statement overstates the requirement.

Choose a shard key that is monotonically increasing, such as an auto-incrementing transaction ID, to simplify range queries.

Why it fails: A monotonically increasing shard key causes all new inserts to target the same chunk, creating a hot spot on one shard. This leads to write bottlenecks and uneven distribution. While range queries on the ID are efficient, the write scalability suffers, which is unacceptable for a high-throughput transaction collection.

Use a random shard key generated by the application to guarantee even distribution across shards.

Why it fails: A random shard key can distribute writes evenly, but it prevents targeted queries because the application cannot predict which shard holds a given account's transactions. Queries by 'accountId' would become scatter-gather across all shards, which contradicts the requirement to minimize such queries and support efficient access by account.

Use a hashed shard key on 'accountId' to ensure even distribution, even though it prevents efficient range queries on 'transactionDate'.

Why it fails: Hashed sharding on 'accountId' distributes data evenly but sacrifices the ability to perform targeted range queries on 'transactionDate' because hashing destroys order. Queries that filter on both fields would still need to target all shards for the date range, causing scatter-gather and defeating the goal of minimizing such queries.

{ metadata: 1 }

Why it fails: Indexing the embedded document metadata as a whole is rarely useful for these queries, as they do not filter on metadata. Such an index would not support the common query patterns and would add unnecessary overhead.

{ user_id: 1, action: 1, timestamp: -1 }

Why it fails: This compound index could support query (1) if action is not used, but the index prefix user_id is equality and then action is not in the query, so the sort on timestamp would not be supported because action is missing. For query (2), it is not optimal because action is not the leading field. Thus it is less effective than the two chosen indexes.

{ timestamp: 1 }

Why it fails: A single-field index on timestamp alone can help with time-range queries but does not include action, so query (2) would still need to filter action after scanning the index. It also does not help query (1) because user_id is not indexed, leading to inefficient filtering.

Set its votes to 0.

Why it fails: Setting votes to 0 makes the member non-voting in elections, but it does not prevent it from becoming primary if it has a non-zero priority and is not hidden. Also, a non-voting member can still be visible to clients. This setting is not required for a hidden member.

Set its slaveDelay to a large value.

Why it fails: slaveDelay (now called secondaryDelaySecs) delays replication, but it does not affect visibility to clients or prevent the member from becoming primary. A delayed member can still be elected primary if its priority is greater than 0 and it is not hidden. This setting is unrelated to the requirements.

Set its buildIndexes to false.

Why it fails: buildIndexes false prevents the member from building non-_id indexes, which is useful for reducing overhead. However, it does not affect visibility or election eligibility. A member with buildIndexes false can still become primary if priority > 0 and not hidden. This setting is not required here.

Add a hint forcing the query to use the _id index.

Why it fails: The _id index only supports lookups by _id. Forcing it with hint on an equality-plus-range query against other fields causes a full index scan of _id entries followed by document fetches and in-memory filtering, which increases work rather than reducing documents examined. It is a misapplication of hint for this predicate shape.

Set the query's read concern to 'majority' to reduce examined documents.

Why it fails: Read concern controls the consistency and durability guarantees of the data returned, not the access path or the number of documents examined. Setting majority read concern can actually add latency because it waits for replicated acknowledgement. It has no effect on how many keys or documents the query plan inspects.

Increase the index's fill factor using collMod to leave more space on pages.

Why it fails: MongoDB's WiredTiger storage engine does not expose a fill factor setting for indexes in the way some relational systems do, and collMod does not tune index page fill. Even if it did, page packing affects write and split behavior, not the number of index keys or documents a query must examine for a given predicate.

Mandatory multi-document ACID transactions for every insert

Why it fails: Mandatory multi-document ACID transactions for every insert would add significant overhead and reduce write throughput. While MongoDB supports multi-document transactions, they are not required for single-document inserts and are not the mechanism for scaling writes. This option contradicts the goal of high-throughput ingestion.

Strict table-level locking for all write operations

Why it fails: Strict table-level locking would serialize writes and severely limit throughput, which is the opposite of what a high-ingest IoT platform needs. MongoDB uses document-level concurrency control, not table-level locking, to allow many concurrent writes. This option would create bottlenecks and is not a feature that supports high write throughput.

Automatic sharding based on the first field alphabetically

Why it fails: MongoDB does not automatically shard based on the first field alphabetically. The shard key must be chosen explicitly, and a poor choice can lead to uneven distribution. This option describes a non-existent automatic behavior and would not reliably support horizontal scaling or high write throughput for IoT data.

Write concern "w: 1"

Why it fails: Write concern "w: 1" acknowledges a write after it is written to the primary only. While this provides low latency, it does not ensure durability across multiple data centers and can lead to data loss if the primary fails before replication. For critical financial transactions requiring strong consistency and high availability, this write concern is insufficient and does not align with the company's requirements.

Read preference "nearest"

Why it fails: Read preference "nearest" directs reads to the replica set member with the lowest network latency, which can improve performance but does not guarantee strong consistency. It may return stale data if the nearest member is a secondary that has not yet replicated the latest writes. This option contradicts the need for strong consistency in critical transactions, making it unsuitable for the scenario.

Read concern "local"

Why it fails: Read concern "local" returns data from the instance without guaranteeing that it has been replicated to a majority of members. It can expose uncommitted or rolled-back data, which is unacceptable for critical transactions. This option prioritizes performance over consistency and is not suitable for the financial services scenario that demands strong consistency and reliability across data centers.

Disable authentication on the replica set to simplify the restart process.

Why it fails: Disabling authentication is a security risk and does not help maintain write availability during rolling maintenance. Authentication settings are configured at startup and should not be changed during maintenance. The replica set can be maintained without altering authentication, and doing so could expose data. This action is irrelevant to the goal of keeping the set writable.

Set the priority of the primary to 0 to prevent it from being re-elected during the maintenance.

Why it fails: Setting the primary's priority to 0 would make it ineligible to be primary, causing it to step down and triggering an election. This would disrupt writes and is not necessary for rolling maintenance on secondaries. The primary should remain primary to continue accepting writes while secondaries are restarted. Changing priority is not part of the procedure.

Use rs.stepDown() to force the primary to step down before restarting any secondary.

Why it fails: Forcing the primary to step down before restarting a secondary is unnecessary and could cause an election, potentially leading to a brief write outage. The goal is to keep the primary up and maintain majority. Stepping down the primary would temporarily leave the set without a primary until a new one is elected, which is not required for rolling maintenance on secondaries.

It immediately becomes the primary to speed up the process.

Why it fails: A node undergoing initial sync is in the 'STARTUP2' state and cannot become primary. It must first complete the data transfer and catch up to the primary's current state. Forcing a node to become primary during sync would be dangerous as it would not have the full dataset required for operations.

It automatically purges all data from the primary node.

Why it fails: Initial sync only affects the node joining the cluster. It never modifies or deletes data on the primary or any other existing members. Modifying the primary's data during a sync process would be catastrophic and would violate the core principles of data integrity and consistency in a distributed system.

$and_not

Why it fails: $and_not is not a valid MongoDB query operator. MongoDB uses $not as a logical negation operator, or simply uses $ne for inequality. The existence of non-existent operators like $and_not is a common distractor to test the candidate's actual familiarity with the official MongoDB operator list.

$is_null

Why it fails: $is_null does not exist in MongoDB. To query for null values, you match against the null value directly (e.g., {field: null}). This will return documents where the field is null or where the field does not exist at all. This is a common point of confusion for new developers.

Automatic failover and high availability for the entire cluster.

Why it fails: While each shard is typically a replica set that provides high availability, sharding itself is focused on horizontal scaling and data distribution. High availability is a property of the replica set architecture used within the shards, rather than a benefit introduced specifically by the sharding layer of the cluster.

Simplified backup and recovery processes for large datasets.

Why it fails: Sharding actually increases the complexity of backup and recovery operations. Backing up a sharded cluster requires coordinating snapshots across all shards and config servers to ensure point-in-time consistency. This is generally more difficult and resource-intensive than managing a single standalone replica set or a single node.

Reduced latency for all queries regardless of the shard key used.

Why it fails: Sharding only reduces latency for queries that can be targeted to specific shards using the shard key. Queries that do not include the shard key must be broadcast to all shards, which often results in higher latency and increased resource consumption compared to a non-sharded environment.

getmore

Why it fails: The 'getmore' metric tracks the number of operations that retrieve additional data from a cursor, typically used in large read queries or tailing the oplog. While important for read performance, it does not provide direct insight into the volume or pressure of write operations on the database server.

vsize

Why it fails: The 'vsize' metric indicates the total virtual memory size used by the mongod process. While it is a useful indicator of overall memory usage, it is not a specific measure of write activity or write-related bottlenecks, as virtual memory includes mapped files and other overhead unrelated to current operation throughput.

The total number of documents in the largest collection.

Why it fails: The election process is independent of the dataset size or the document count. It relies on the exchange of metadata and configuration information between members. While large datasets can affect initial sync time, they have no bearing on how quickly nodes can negotiate and elect a new primary.

The amount of free RAM available on the primary node.

Why it fails: Memory availability on the primary does not influence election timing. The election is a protocol-level event managed by the set members. While a healthy primary node is essential for performance, the election mechanism itself is entirely decoupled from the hardware-level resource utilization of the nodes involved in the voting.