MongoDB Certified DBA Associate (C100DBA) — Questions 1–75

A covered query is one where all the fields in the query projection exist within the index itself. Because the database can retrieve all necessary data directly from the index tree without needing to fetch the actual document from disk, it drastically reduces I/O. This is one of the most effective ways to optimize read performance for high-frequency queries in large collections.

A good shard key needs high cardinality to allow for a large number of chunks. If a shard key only has three possible values, the cluster can have at most three chunks for that collection. This limits the total number of shards that can participate in storing and processing the data, leading to scalability bottlenecks and imbalance.

The write concern {w: 'majority'} ensures that the operation is only acknowledged after it has been written to a majority of the replica set members. This is essential for data durability and preventing data loss in the event of a primary node failover. It provides a stronger guarantee than the default 'w: 1' by ensuring that data is replicated before the application proceeds.

The compound shard key with 'accountId' first supports targeted queries on account and range queries on date, while also providing high cardinality and low frequency. This combination reduces scatter-gather and avoids hot spots. Hashed or random keys improve distribution but break query targeting, and a monotonically increasing key creates write hot spots.

Zone sharding allows administrators to associate specific shard key ranges with defined sets of shards called zones. By tagging European servers into an 'EU' zone and associating the region shard key range with that zone, MongoDB guarantees that EU customer data stays exclusively on those designated physical shards. This is critical for regulatory compliance and data sovereignty requirements.

The 'w: majority' write concern ensures that a write operation is acknowledged only after it has been replicated to a majority of nodes in the replica set. This philosophy prioritizes data durability and consistency over the absolute lowest latency. By requiring a majority, MongoDB ensures that even if a primary node fails immediately after a write, the data persists on other nodes, minimizing the window for data loss during failover.

A replica set requires a majority of its voting members to be online to elect a new primary and perform write operations with majority concern. If the majority is lost, the remaining nodes enter a read-only state, as they cannot reach consensus. This is a critical failure scenario that requires immediate administrative intervention, such as reconfiguring the set or restoring the failed nodes.

MongoDB is schema-flexible, meaning it will create the field if it is missing during an update operation. The $set operator is intelligent enough to add the field with the specified value, which simplifies code by eliminating the need for pre-checks or initialization logic. This is a core strength of the document model that allows for evolving data requirements without requiring explicit database migrations.

With a monotonically increasing shard key, new inserts always target the chunk with the highest key range. Because chunks are assigned to shards, that highest chunk lives on one shard at a time, making it a write hotspot. The balancer will eventually migrate chunks, but the stream of new inserts keeps hitting the newest chunk, so the imbalance persists.

The 'majority' read concern guarantees that the data returned has been acknowledged by a majority of the replica set members. This ensures that the data is durable and will not be rolled back in the event of a primary failover. It provides a higher level of consistency for read operations, which is critical for applications that require strict data integrity and visibility.

Security administration involves protecting data at rest, in transit, and in logs. Log redaction is a feature that prevents sensitive information, like the contents of a 'find' filter or an 'insert' document, from appearing in the server logs. This is essential for compliance with regulations like GDPR, HIPAA, or PCI-DSS.

The error indicates that the group operation is exceeding the 100MB RAM limit. By setting 'allowDiskUse: true', you permit the MongoDB server to use temporary files for the aggregation process. This is a common requirement for complex analytics where the data working set is larger than the available RAM, ensuring that long-running operations can complete successfully without crashing due to memory exhaustion.

Rollback happens when a node was previously a primary, performed writes that were never replicated to the majority, and then rejoined the set after a new primary was elected. To maintain consistency, the old primary must discard those unacknowledged writes to match the new primary's state. These discarded writes are saved to a local BSON file for manual inspection and potential recovery by administrators.

The rs.printSecondaryReplicationInfo() command provides a convenient summary of how far behind each secondary is compared to the primary. This is a vital tool for monitoring the health of the replica set and identifying nodes that may be having trouble keeping up with the write volume, which could signal underlying network or hardware performance bottlenecks.

A 'COLLSCAN' indicates that the database is performing a full collection scan, reading every document to satisfy the query. The high number of docs examined relative to the returned documents suggests that the query is inefficient. In a production environment, this is a major performance bottleneck, as the database engine must load entire documents into memory to evaluate the filter, leading to high I/O and latency.

The correct considerations are that embedding provides atomic updates and fast reads for the event history, while referencing allows unlimited growth and avoids the 16 MB limit. These reflect MongoDB's flexible modeling philosophy: choose embedding when data is accessed together and atomicity is needed, but opt for referencing when data grows unbounded or is accessed independently. The decision hinges on access patterns and data lifecycle.

The positional `$` operator updates the first array element that matches the query condition. Pairing `"inventory.sku": "B2"` in the filter with `"inventory.$.qty"` in the update ensures only the subdocument with that SKU is modified. Using `$inc` performs the required arithmetic and preserves the numeric field type, which is essential for inventory counts.

A unique index on sku is what enforces the duplicate constraint. A plain insertOne is sufficient: if the sku already exists, the server returns a duplicate key error. The ordered option is only relevant for multi-document inserts, upsert would update instead of fail, and bypassDocumentValidation only affects schema validation, not unique indexes.

The $addToSet operator is the standard MongoDB tool for array manipulation when uniqueness is required. It ensures that the specified value is added to the array only if it is not currently present. This prevents duplicate entries without requiring the application to perform a read-then-write check, making it an atomic and highly performant operation for managing sets within document-based data structures.

$pull is the array update operator that removes all elements matching a value or condition. Filtering on documents where tags contains "obsolete" and applying $pull deletes every such occurrence while leaving other tags intact. $unset removes whole fields, $pop removes positional elements, and $set replaces values rather than selectively removing matches.

The index { category: 1, price: 1 } supports efficient filtering when the query has an equality predicate on category and a range predicate on price. MongoDB can use index bounds to seek to the correct category and scan only the relevant price range, minimizing the number of documents fetched. This makes the index scan efficient despite examining many index entries.

Hashed sharding applies an MD5 hash function to the specified field value before routing documents. This transforms sequential or correlated inputs into pseudo-random hash values, ensuring that writes scatter uniformly across all available cluster shards. Understanding hashed sharding mechanisms enables administrators to design resilient write-heavy architectures that prevent the single-shard bottlenecks common with monotonic keys.

When backing up a live database, data changes while the backup is running. The '--oplog' flag tells mongodump to capture all operations that occur during the dump process. This allows the DBA to restore the database to a consistent state by replaying those operations during the 'mongorestore' process, ensuring data integrity.

Config servers store the metadata and configuration settings for the entire sharded cluster. They are deployed as a replica set to ensure high availability. If the replica set loses its majority, it can no longer process writes to the metadata, which has significant implications for administrative tasks and the dynamic behavior of the cluster.

The $all operator is used to find documents where the field contains all the specified elements. When indexing an array field, MongoDB creates a multikey index. A simple index on 'tags' is sufficient here because the multikey index structure inherently supports finding documents that contain specific array elements, enabling the query engine to efficiently narrow down the result set without scanning all documents in the collection.

The replicaSet parameter is essential for drivers to identify the cluster name and initiate the discovery process. When this parameter is specified, the driver uses the provided seed list to perform a 'isMaster' command against the nodes, allowing it to map the entire topology. Understanding this mechanism is vital for ensuring high availability, as the driver needs to dynamically redirect operations to the new primary during automated failover events.

The skip() method is the standard cursor modifier used to bypass a set number of initial documents in a result set. It is essential for implementing pagination in applications, often used in conjunction with limit() to fetch specific pages of data. Understanding its impact on performance is vital, as skipping large numbers of documents can be expensive for the database engine to process.

When a query does not include the shard key, the mongos router cannot determine which shard contains the requested data. As a result, it must broadcast the query to every shard in the cluster. This 'scatter-gather' operation increases resource consumption across all nodes and can lead to significant latency and scalability issues as the cluster grows.

During initial sync, the node first clones all databases from the primary, then applies all changes recorded in the oplog that occurred during the cloning phase, and finally builds all necessary indexes for the collections. This multi-stage process ensures the new member reaches a consistent state with the primary without requiring an outage or downtime for the existing cluster members.

Multikey indexes are used when you need to index a field that contains an array. MongoDB creates an index entry for each element in the array, allowing you to efficiently query for documents containing specific array values. This is essential for applications managing tags, inventory lists, or user attributes stored as arrays, ensuring that queries filtering by these elements perform with high efficiency rather than scanning the entire collection.

A large discrepancy between 'keysExamined' and 'nReturned' suggests that the index is not very selective or is being used inefficiently. The engine is scanning many index entries that do not match the query criteria, which is a major performance drain. Investigating the selectivity of the index and potentially adding more fields to the compound index can help narrow down the search and improve efficiency.

Partial indexes allow you to index only a subset of documents that meet a specific filter condition. This reduces index size and the overhead of maintaining the index during writes, as only updates to documents matching the filter trigger an index update. This is highly effective for reducing memory usage when you only need to index documents with specific statuses, such as 'active' or 'pending', rather than the entire collection.

A compound index can provide both the equality match and the sort when the equality fields form the prefix and the sort field follows. With { tenantId: 1, createdAt: -1 }, the query's equality on tenantId and sort on createdAt should be served without an in-memory sort. A blocking SORT in explain therefore points to a mismatch such as collation, type, or query shape rather than a missing index.

If a secondary's last oplog entry is no longer in the primary's oplog, the secondary cannot catch up incrementally. A full resync is required, which means deleting the secondary's data files and restarting it to perform an initial sync. This process copies all data from the primary or another sync source.

MinKey and MaxKey represent lower and upper boundary markers in MongoDB that evaluate smaller or larger than any other BSON data type. In this compound chunk range, they ensure that all documents matching the 'EMEA' region regardless of their account_id value fall within this specific chunk. Understanding BSON boundary types is essential for troubleshooting custom chunk splits and zone sharding configurations.

$addToSet is designed to add a value to an array only if it is not already present, making it the correct operator for ensuring uniqueness. It performs this check atomically, so concurrent updates will not introduce duplicates. $push would append duplicates, $set would replace the array, and $addToSet with $each is overkill for a single value.

Embedding related data such as comments and tags within the article document allows the application to retrieve everything in one query. This reduces round trips and latency, directly supporting the team's goal of a single database call to render an article page.

MongoDB’s flexible schema design allows developers to store heterogeneous data types within the same collection. Unlike rigid relational schemas that necessitate complex migrations or NULL-heavy tables for varying attributes, document-oriented storage enables an agile development lifecycle. This philosophy prioritizes developer productivity and adaptability, allowing application code to dictate structure rather than being constrained by predefined table schemas that require frequent and disruptive database-level modifications.

The 'wtimeout' parameter prevents a write operation from blocking indefinitely if the specified replica set members cannot acknowledge the write. This is a critical safety mechanism for application availability. If a network partition occurs or a node goes offline, the application will receive an error after the timeout, allowing it to handle the failure gracefully instead of hanging the application thread and exhausting the connection pool, which could lead to cascading service outages.

The auditing system in MongoDB Enterprise is essential for compliance and security monitoring. By configuring the audit log to capture events related to authentication and authorization, administrators gain visibility into who is accessing the database and what actions they are performing. This is crucial for forensic analysis, detecting unauthorized access attempts, and satisfying regulatory requirements that mandate detailed record-keeping for all database interactions within a production environment.

A compound index with an equality field followed by a range field is ideal for queries that filter on both. MongoDB will use the index to seek to the equality value and then scan the range on the second field. This minimizes document examinations and is the expected behavior for the given index and query.

Arbiters are lightweight processes that participate in elections but do not hold data. They are a cost-effective way to achieve a majority for elections in small replica sets. Understanding when to use an arbiter is crucial for designing a cost-efficient and highly available architecture, especially when deploying in multiple zones where adding a full data-bearing node might be cost-prohibitive or unnecessary due to data redundancy requirements.

The 'majority' write concern provides a guarantee that the write operation has been committed to a majority of the replica set members. This is the industry standard for ensuring data durability in the event of a primary node failover. DBAs must enforce this setting for critical business data to prevent 'lost updates' where an application assumes a write is permanent when it actually exists only on the primary that is about to crash.

Replica sets are MongoDB's foundation for high availability, providing automatic failover and data redundancy across multiple nodes. When the primary becomes unavailable, the remaining nodes elect a new primary, allowing the system to continue operating. This built-in mechanism requires no manual intervention and is essential for production deployments that demand continuous uptime and data durability.

The retryWrites=true connection string option instructs the MongoDB driver to automatically retry supported write operations once if they fail with a retryable error. This offloads retry logic from the application code and is the standard way to handle transient network issues in replica sets. Other options affect write concern, read routing, or connection timeouts, but none provide automatic write retries.

Write concern determines the level of acknowledgment required from the replica set before a write operation is considered successful. A higher write concern ensures stronger data durability by requiring the write to reach a majority of nodes, thereby preventing data loss in the event of a primary failure. This highlights MongoDB's philosophy of allowing developers to choose the right balance between write latency and data safety based on specific application requirements.

Hashed shard keys are ideal when incoming write operations rely on monotonic or sequential values, such as auto-incrementing IDs or timestamps. Hashing prevents write bottlenecks by scattering insertions across all cluster shards, whereas ranged keys would force all writes onto a single shard.

To optimize queries with equality filters and descending sorts, the index must match the equality field first, followed by the sort field with the correct direction. Placing category first satisfies equality lookup, while setting price to negative one avoids in-memory sorting stages during execution.

MongoDB's query router, mongos, can target queries that include the shard key, even with `$in`. It looks up the chunk ranges for the specified values and routes the query only to the shards that own those chunks. This is known as a targeted query and is efficient because it avoids contacting unnecessary shards.

To create a member that never becomes primary and is invisible to clients, you must set both priority to 0 and hidden to true. Priority 0 ensures it cannot be elected primary, while hidden true prevents client visibility and use as a sync source. These two settings together meet the requirements.

MongoDB's document model lets developers add or modify fields per document without a centralized schema migration. This means new features can be deployed without database downtime, directly supporting the startup's need for rapid iteration and continuous delivery.

The requirement is to always read the most up-to-date data, which is only guaranteed when reading from the primary. The "primary" read preference ensures that all reads are directed to the primary node. Other read preferences may read from secondaries, which can have stale data, or may fall back to secondaries if the primary is unavailable, violating the requirement.

Multi-document transactions in MongoDB 4.2 on replica sets provide ACID guarantees across multiple documents and collections. They are the only feature listed that ensures a series of reads and writes across two collections are applied atomically. The other options are storage or streaming features that do not offer transactional atomicity.

The shard key prefix dictates how MongoDB organizes and partitions chunk ranges across the cluster. A high-cardinality prefix ensures fine-grained chunk boundaries and prevents massive, unmanageable chunks from forming around repetitive values, which often happens when low-cardinality fields like boolean flags or status codes occupy the leading position.

A COLLSCAN stage indicates that the query engine scanned every document in the collection because no suitable index was found. Creating an index on the filtered field enables the query planner to select an IXSCAN stage, drastically reducing disk reads and improving throughput.

While mongostat gives a high-level view of server-wide operations and memory, mongotop provides a granular look at where the storage engine is spending its time. It breaks down read and write time by collection, allowing the DBA to identify which specific table is causing the most load on the system.

The index { a: 1, b: 1, c: 1 } cannot support the sort on c because b is a range predicate, which means the index order after the equality on a is determined by b, not c. To support both the filter and the sort, the index should be reordered so that the sort field c follows the equality field a, and the range field b comes last. The index { a: 1, c: 1, b: 1 } allows the equality on a to bound the prefix, then the sort on c to be satisfied by the index order, and finally the range on b to be applied as an index filter.

Sharding distributes data across shards for horizontal scale and high write throughput, while the dynamic schema accommodates heterogeneous sensor payloads without migrations. Together, these features address the platform's need to ingest semi-structured data from millions of devices and scale out as volume grows.

Binding MongoDB to the correct network interfaces is a fundamental security task. By default, older versions might bind to all interfaces, exposing the database to the public internet. Best practices dictate binding only to the loopback address and specific internal management or application network IPs to minimize the attack surface.

The $inc operator atomically increments or decrements a field by a specified amount, and $currentDate sets a field to the current date/time. Combining them in a single updateOne call ensures both modifications happen atomically on the matched document without altering other fields. This directly satisfies the need to decrement stock and add a timestamp in one operation.

The requirement is for a write concern that ensures acknowledgment after a majority of voting members have applied the write and written it to the on-disk journal. The write concern { w: 'majority', j: true } achieves both: w: 'majority' dynamically requires a majority of voting members, and j: true forces journaling on those members before acknowledgment. Using a fixed w: 2 may not adapt to membership changes, and omitting j: true does not guarantee journaling. (Explanation length: 65 words)

BSON (Binary JSON) is essential to MongoDB because it extends the JSON model by adding support for more data types like Date and BinData while optimizing for traversal. By encoding length prefixes into the binary format, MongoDB can quickly skip over fields without parsing the entire document. This design balance ensures that MongoDB maintains the human-readability benefits of JSON while achieving the performance characteristics necessary for high-throughput, enterprise-scale database operations.

The deleteOne method is the safest way to remove a single document because it accepts a filter and stops after deleting the first matching document, even if multiple documents match. This prevents accidental data loss that could occur with deleteMany if the filter criteria were not sufficiently specific. It is a fundamental practice to use the most restrictive method possible for destructive operations.