MongoDB Certified Associate Database Administrator Exam Questions

Correct answer: B
The Subset Pattern reduces the amount of related data an application must read together by embedding only the frequently-accessed subset (e.g., a user’s most recent posts) directly alongside the parent document, instead of always reaching across collections — and, in a sharded cluster, across shards — to reassemble it. MongoDB’s official guidance frames the Subset Pattern specifically as an alternative to sharding a growing working set: “Rather than sharding your collection, you can reduce the size of your working set by using the subset pattern.” Applying the same idea here — embedding a bounded subset of each user’s most recent posts alongside the user document — avoids the repeated cross-shard round trips needed to join the two sharded collections for a profile view.

Why other options are incorrect
A. The Bucket Pattern groups time-series-like data into fixed time windows and is intended for high-volume time-series/IoT data, not for avoiding cross-collection joins.
C. The Approximation Pattern reduces the precision/frequency of expensive count or aggregation operations; it doesn’t address latency from joining across sharded collections.
D. The Tree Pattern (and its variants) models hierarchical data such as category trees; it has no bearing on avoiding cross-shard reads of unrelated collections.

Source: Group Data with the Subset Pattern

Correct answer: C
MongoDB explicitly documents “too many collections” as a schema design anti-pattern: creating a collection per partition key (in the docs’ own example, a collection per day; here, a collection per customer) forces MongoDB to maintain a separate default _id index per collection and often requires $lookup to query across them, both of which “can strain replica set resources and decrease performance.” The docs’ own worked fix is to remodel the schema so the data lives in far fewer collections — consolidating the per-partition data into a single collection (for example, one orders collection with a customerId field) — exactly what “redesign the schema to reduce the number of collections” describes.

Why other options are incorrect
A. Adding hardware doesn’t address the root cause — an unbounded, ever-growing number of _id indexes and $lookup-heavy queries — and only delays the same problem at a higher cost.
B. Labeling old collections with an “archive tag” doesn’t reduce the collection count, the index overhead, or the need for cross-collection lookups; the collections (and their indexes) are still there.
D. Creating a separate database per customer makes the sprawl worse, not better — MongoDB would now need to manage per-customer collections and databases, multiplying the same overhead.

Source: Reduce the Number of Collections

Correct answer: A
This is precisely the scenario MongoDB’s “Avoid Unbounded Arrays” documentation walks through: an array field (there, book reviews; here, post comments) that grows without bound can strain application resources, degrade index performance, and risk the 16MB BSON document limit. The docs’ recommended Subset Pattern fix is to keep only a bounded, frequently-accessed subset of comments embedded in the post document (e.g., the most recent ones) while storing the complete set — including the ones no longer embedded — in a separate collection, exactly matching “store only the most recent comments in the post document and move all comments to a separate collection.”

Why other options are incorrect
B. Leaving the unbounded array as-is is the anti-pattern itself — it’s what causes the performance degradation described in the question.
C. Moving all comments out with no bounded subset left in the post document is a pure referencing approach, not the worked pattern MongoDB documents for this exact “some documents grow disproportionately large” scenario, and it forces every post view to run an extra query just to show even a single comment.
D. The 16MB BSON document size limit is a hard, non-configurable limit in MongoDB — it cannot be increased.

Source: Avoid Unbounded Arrays

Correct answer: D
MongoDB’s aggregation pipeline documentation describes the pipeline as a sequence of stages where “the documents that a stage outputs are then passed to the next stage in the pipeline” — each stage operates only on what the previous stage produced. Because a stage “does not need to output one document for every input document” ($match, for example, filters documents out), placing $match as early as possible means every downstream stage — including an expensive $group — only has to process the smaller, already-filtered set of documents, a foundational aggregation performance practice.

Why other options are incorrect
A. Filtering only after grouping means the expensive $group stage still has to process every document in the collection, defeating the purpose of filtering early.
B. Aggregation stages are explicitly sequential — each stage’s output feeds the next stage as input; they are not processed in parallel.
C. Pulling the entire collection into application code to filter it discards the benefit of server-side aggregation and moves processing and network cost to the client.

Source: Aggregation Pipeline

Correct answer: B
MongoDB’s one-to-one data modeling guidance recommends embedding for exactly this case: “Embedding connected data in a single document can reduce the number of read operations required to obtain data. In general, structure your schema so your application receives all of its required information in a single read operation.” The docs list “user account to email address” as a textbook example of a one-to-one relationship suited to the embedded model.

Why other options are incorrect
A. Referencing the address in a separate collection requires an extra query (or a $lookup) every time the application needs the user’s profile — unnecessary overhead for data that’s always accessed together.
C. Splitting related data into separate databases adds operational complexity with no benefit for data that’s always read together.
D. Duplicating the entire user document per address field doesn’t model a one-to-one relationship at all and creates redundant, inconsistent data.

Source: Model One-to-One Relationships with Embedded Documents

Correct answer: C
MongoDB’s data modeling documentation states directly: “MongoDB has a flexible data model that allows you to store polymorphic data, meaning: Documents within a single collection are not required to have the same set of fields. A field’s data type can differ between documents within a collection.” This lets teams evolve their data model over time as application needs change, rather than requiring a rigid, pre-defined schema for every row as in a relational table.

Why other options are incorrect
A. Requiring identical fields/types across every document describes a rigid relational-style schema — the opposite of MongoDB’s flexible document model.
B. MongoDB does not require a schema to be defined and validated up front; schema validation is an optional feature added later, not a prerequisite for inserting data.
D. MongoDB’s own guidance is the opposite: “You should structure your data model based on your application’s data access patterns to optimize performance” — access patterns are central to good MongoDB schema design, not irrelevant.

Source: Data Modeling in MongoDB

Correct answer: A
MongoDB’s documentation on limiting query results states: “By default, queries in MongoDB return all fields in matching documents. To limit the amount of data that MongoDB sends to applications, you can include a projection document to specify or restrict fields to return.” Passing a projection document to find() that specifies only name and price is exactly the mechanism designed for this.

Why other options are incorrect
B. Maintaining a separate collection just to hold two fields duplicates data and adds synchronization overhead instead of simply projecting the existing collection.
C. $merge writes aggregation results into a collection; it’s an output stage, not a way to restrict which fields a query returns to a client.
D. WiredTiger cache size affects how much data MongoDB can keep in memory; it has no effect on which fields a query returns to the application.

Source: Limit Fields to Return from a Query

Correct answer: D
The $set update operator “replaces the value of a field with the specified value” while leaving every other field in the document untouched, and combined with updateOne() it modifies only the single first matching document. MongoDB’s documentation also notes this keeps oplog entries small, since only the changed field is written, rather than the whole document.

Why other options are incorrect
A. replaceOne() with a document containing only status would replace the entire matching document with that one field, discarding all of the order’s other data.
B. Passing a plain field-value document (without $set or another update operator) to updateOne() is invalid — MongoDB update operations require update operators like $set to modify specific fields.
C. Deleting the document and reinserting one with only status destroys all the order’s other fields and changes its _id — far more destructive than a targeted field update.

Source: $set

Correct answer: B
MongoDB documentation states: “You do not need to explicitly specify an index as multikey. If you create an index on a field that contains an array value, MongoDB automatically creates the index as a multikey index,” and “For each distinct value in the array, MongoDB creates a separate entry in the index, and each entry points back to the same document.” This lets queries efficiently match any individual element of the array.

Why other options are incorrect
A. Storing the whole array as a single index entry would prevent MongoDB from matching individual array elements efficiently — not how multikey indexes work.
C. Text indexes are a distinct, explicitly-created index type for text search; MongoDB doesn’t automatically substitute one just because a field is an array.
D. MongoDB fully supports indexing array-valued fields — that’s exactly what a multikey index is for.

Source: Multikey Indexes

Correct answer: C
MongoDB recommends the ESR (Equality, Sort, Range) guideline for ordering compound index fields: “To create efficient compound indexes, follow the ESR (Equality, Sort, Range) guideline.” Placing equality fields first lets MongoDB narrow to matching documents immediately, the sort field next lets it use the index’s ordering to avoid an in-memory sort, and the range field last lets it scan the remaining bounded range — producing far fewer scanned keys than a poorly ordered index.

Why other options are incorrect
A. Placing the range field first (before equality) increases the number of index keys MongoDB has to examine before applying the equality and sort filters.
B. Leading with a sort field, ahead of the equality field, similarly forces MongoDB to scan more of the index than necessary.
D. The documentation directly contradicts this: “The order of the indexed fields impacts the effectiveness of a compound index,” with a worked example showing reordering fields dramatically changes how many index keys must be scanned.

Source: Compound Indexes

Correct answer: A
MongoDB’s explain plan documentation is direct: “Collection scans indicate that the mongod had to scan the entire collection document by document to identify the results. This is a generally expensive operation and can result in slow queries.” A COLLSCAN stage with totalDocsExamined equal to the whole collection means the available index was not used for this query — it needs to be reviewed (and possibly the index changed) so MongoDB’s query planner can select an IXSCAN plan instead.

Why other options are incorrect
B. A covered query produces an IXSCAN plan that satisfies the query entirely from the index — the opposite of the COLLSCAN behavior described.
C. COLLSCAN is described in MongoDB’s own documentation as “a generally expensive operation,” not the fastest possible plan.
D. A COLLSCAN doesn’t indicate index corruption — the query planner simply chose not to (or could not) use any available index for this query shape; the index itself is unaffected.

Source: Interpret Explain Plan Results

Correct answer: D
MongoDB defines this precisely: “A covered query is a query that can be satisfied entirely using an index and doesn’t have to examine any documents,” which requires that every field in the query and every field returned are part of the same index, with _id explicitly excluded if it isn’t part of that index. Because index keys are typically smaller than full documents and often already in RAM, covered queries can be significantly faster than queries that must fetch documents.

Why other options are incorrect
A. A sharded query refers to a query routed across a sharded cluster; it has nothing to do with whether an index alone can satisfy it.
B. “Capped query” is not a MongoDB term — “capped collection” refers to a fixed-size collection, unrelated to index coverage.
C. A tailable cursor continuously reads new documents appended to a capped collection; it’s unrelated to whether a query is index-covered.

Source: Query Optimization

Correct answer: B
MongoDB documentation defines a partial index as one that only “index[es] the documents in a collection that meet a specified filter expression,” created with the partialFilterExpression option. It notes: “Partial indexes have lower storage requirements and reduced performance costs for index creation and maintenance” compared to indexing the entire collection — exactly the benefit needed when only a small, well-defined subset of documents is ever queried.

Why other options are incorrect
A. A hashed index stores hashes of a field’s values to support even distribution (commonly for sharding); it doesn’t restrict which documents get indexed based on a filter.
C. A geospatial index supports queries on geographic location data; it’s unrelated to selectively indexing a subset of documents by a filter condition.
D. A unique index enforces that indexed field values are distinct across documents; it doesn’t limit indexing to a filtered subset of documents.

Source: Partial Indexes

Correct answer: C
MongoDB’s schema design guidance for this exact problem says: “To determine which indexes are rarely used, use the $indexStats aggregation stage,” which reports an accesses field showing “the number of times users have used each index to run an operation.” An index with zero (or very low) accesses is a strong candidate for removal, since every index still has to be maintained on every write regardless of how often it’s used for reads.

Why other options are incorrect
A. $lookup performs a join-like operation between collections; it has nothing to do with reporting index usage statistics.
B. Increasing the oplog size affects how much replication history is retained; it doesn’t help identify unused indexes or reduce write overhead from them.
D. Enabling sharding redistributes data across shards; it doesn’t identify or remove unnecessary indexes, and every shard would still maintain its own copy of each index.

Source: Remove Unnecessary Indexes

Correct answer: A
MongoDB’s manual describes this exact capability: “MongoDB includes a number of features that allow database administrators and developers to isolate workload by functional or geographical groupings,” and specifically “supports workload isolation based on functional or operational parameters, to ensure that certain mongod instances are only used for reporting workloads.” Using read preference tags (or, in Atlas, dedicated analytics nodes) to direct the nightly analytics job to specific replica set members keeps that heavy workload from competing for resources with the dashboard’s real-time reads on the primary.

Why other options are incorrect
B. Horizontal scaling increases overall capacity but doesn’t by itself separate the two competing workloads onto different members — the analytics job could still land on the same nodes serving the dashboard.
C. Query optimization improves how efficiently individual queries run, but the dashboard’s queries may already be well-optimized; the problem here is resource contention between two workloads, not inefficient queries.
D. Connection pooling manages how an application reuses database connections; it doesn’t route different types of workloads to different replica set members.

Source: Workload Isolation in MongoDB Deployments

Correct answer: D
Atlas documentation states: “The Performance Advisor monitors queries that MongoDB considers slow and suggests new indexes to improve query performance. The threshold for slow queries varies based on the average time of operations on your cluster to provide recommendations pertinent to your workload.” By default it dynamically adjusts its slow-query threshold to the cluster’s own typical operation times, and its index recommendations come with sample queries grouped by query shape.

Why other options are incorrect
A. AWS CloudTrail is an AWS account activity-logging service unrelated to MongoDB Atlas or query performance recommendations.
B. $merge is an aggregation pipeline stage that writes results to a collection; it has no role in identifying slow queries or recommending indexes.
C. The IP Access List controls which client IP addresses can connect to a cluster; it has nothing to do with query performance monitoring.

Source: Monitor and Improve Slow Queries with the Performance Advisor

Correct answer: B
The Performance Advisor documentation lists specific common causes of slow queries, including: “One query retrieves information from multiple collections with $lookup,” alongside queries unsupported by current indexes and documents with “large array fields that are costly to search and index.” Multi-collection $lookup joins are inherently more expensive than single-collection queries, so they’re flagged as a frequent source of slow-query alerts.

Why other options are incorrect
A. A covered query is satisfied entirely from an index without examining documents — a sign of good performance, not a cause of slowness.
C. Having too few documents is not a documented cause of slow queries; small collections are generally fast to scan even without ideal indexes.
D. The number of availability zones a cluster spans is a high-availability/topology consideration, not a documented cause of individual slow queries.

Source: Monitor and Improve Slow Queries with the Performance Advisor

Correct answer: C
Atlas documentation describes this feature directly: “The Query Shape Insights page displays charts and a table that describe the performance metrics for the query shapes in your project with the highest total execution time,” including “Total Execution Time, Avg Execution Time, Execution Count,” and the “Docs Examined:Returned ratio.”

Why other options are incorrect
A. AWS Direct Connect is a dedicated network connection service between an on-premises network and AWS; it has no relationship to query performance monitoring in Atlas.
B. $out is an aggregation pipeline stage that writes results to a new collection; it doesn’t surface query performance metrics.
D. Termination Protection prevents a cluster from being accidentally deleted; it’s unrelated to identifying slow query shapes.

Source: Monitor Query Shape Statistics with Query Shape Insights

Correct answer: A
MongoDB documents three profiler levels: level 0 means “the profiler is off and does not collect any data”; level 1 means “the profiler collects data for operations that exceed the slowms threshold or match a specified filter”; and level 2 means “the profiler collects data for all operations,” ignoring slowms/filter settings. Level 1 is exactly the configuration for capturing only slow operations.

Why other options are incorrect
B. Level 0 is the default, disabled state — it doesn’t collect any profiling data at all, slow or otherwise.
C. Level 2 collects data for every operation regardless of duration, more data (and overhead) than “only operations exceeding slowms.”
D. MongoDB’s database profiler only defines levels 0, 1, and 2 — there is no level 3.

Source: Database Profiler

Correct answer: D
MongoDB documentation states: “By default, the slow operation threshold is 100 milliseconds,” and “The profiler writes all the data it collects to a system.profile collection, a capped collection in each profiled database.” This gives DBAs an out-of-the-box baseline for flagging slow operations without any manual configuration.

Why other options are incorrect
A. 10 seconds is not MongoDB’s default slow operation threshold, and profiler data is written to system.profile, not the oplog (which records write operations for replication, not profiling data).
B. 1 millisecond is far stricter than MongoDB’s documented 100ms default, and profiler output goes to the system.profile collection, not a text file.
C. MongoDB does define a default threshold (100ms) — it does not treat every operation as slow by default.

Source: Database Profiler

Correct answer: B
Atlas documentation describes Namespace Insights as showing collection-level query latency: “The Namespace Insights page displays two charts and a table with information for each top or pinned namespace,” reporting metrics including “P50 latency,” “P95 latency,” and “P99 latency,” and letting a DBA “manage pinned namespaces and choose up to five namespaces to show in the corresponding query latency charts.”

Why other options are incorrect
A. AWS WAF is a web application firewall for filtering HTTP traffic; it has no relationship to MongoDB collection-level query latency.
C. $facet is an aggregation stage that processes multiple aggregation pipelines within a single stage; it doesn’t provide a monitoring dashboard for collection latency.
D. Encryption at Rest using Customer Key Management is a data-at-rest security feature, unrelated to query latency monitoring.

Source: Monitor Collection-Level Query Latency with Namespace Insights

Correct answer: C
Atlas documentation is explicit: “Query Targeting alerts often indicate inefficient queries,” triggered when “the average number of documents scanned relative to the average number of documents returned server-wide across all operations during a sampling period exceeds a defined threshold. The default alert uses a 1000:1 threshold.” It further states the alert “typically occurs when there is no index to support a query or queries or when an existing index only partially supports a query,” and recommends: “Add one or more indexes to better serve the inefficient queries. The Performance Advisor provides the easiest and quickest way to create an index.”

Why other options are incorrect
A. Query Targeting is a MongoDB-specific efficiency metric about scanned-vs-returned documents, not a signal of a DDoS attack, and AWS Shield is unrelated to MongoDB Atlas.
B. Voting member count affects elections and fault tolerance, not the ratio of documents a query scans versus returns.
D. Oplog size affects the replication window, not query-level scan efficiency; reducing it would not address inefficient queries.

Source: Fix Query Issues

Correct answer: A
MongoDB documentation shows exactly this pattern: db.currentOp() “returns a document that contains information on in-progress operations for the database instance,” and its filtering example finds active operations on a specific database running longer than 3 seconds using {"active": true, "secs_running": {"$gt": 3}, "ns": /^db1\./}. This lets a DBA identify problem operations before deciding whether to terminate any of them with db.killOp().

Why other options are incorrect
B. Creating a collection has nothing to do with inspecting currently running operations.
C. Dropping a collection is a destructive operation unrelated to diagnosing long-running queries, and doing so without first confirming the cause would risk unintended data loss.
D. rs.reconfig() changes replica set configuration (such as member settings); it does not inspect or report on currently running operations.

Source: db.currentOp()

Correct answer: D
Atlas documentation describes the Real-Time Performance Panel (RTPP) as monitoring and displaying “current network traffic, database operations on the machines hosting MongoDB in your clusters, and hardware statistics about the hosts,” with use cases including the ability to “visually identify relevant database operations” and view “slowest operations with ability to terminate them” directly from the panel.

Why other options are incorrect
A. AWS Cost Explorer analyzes AWS billing and usage, unrelated to MongoDB Atlas real-time performance monitoring.
B. $bucket is an aggregation stage for grouping documents into ranges; it’s unrelated to real-time operational monitoring.
C. VPC Peering is a private networking feature connecting an Atlas cluster’s VPC to another VPC; it doesn’t provide real-time operation visibility.

Source: Monitor Real-Time Performance

Correct answer: B
The Real-Time Performance Panel documentation states its use cases include the ability to “discover potential replication lag on secondary members of replica sets,” in the same panel that shows “query execution times and the ratio of documents scanned to documents returned” — combining replication health and query performance monitoring in one live view, displayed only for secondary members of the replica set.

Why other options are incorrect
A. AWS Config tracks AWS resource configuration compliance; it is unrelated to MongoDB replica set replication lag.
C. $redact is an aggregation stage used to restrict document content based on field-level access-control logic; it has no monitoring function.
D. Online Archive moves infrequently accessed data to a read-only, cheaper storage tier; it doesn’t display replication lag or query execution times.

Source: Monitor Real-Time Performance

Correct answer: C
MongoDB’s explain plan documentation walks through exactly this comparison: when totalKeysExamined and totalDocsExamined both equal nReturned, “the query scanned 3 index entries and 3 documents to return 3 matching documents, resulting in a very efficient query” — every key and document examined actually matched and was returned, with no wasted scanning.

Why other options are incorrect
A. totalKeysExamined equals totalDocsExamined here (both 3), not greater than it — and even so, examining more keys than documents isn’t automatically inefficient by itself; the real efficiency signal is how these numbers compare to nReturned.
B. Non-zero totalKeysExamined indicates the query did use an index (an IXSCAN), not a collection scan.
D. These numbers describe only what this particular query examined and returned; they say nothing about the collection’s total document count, which could be far larger.

Source: Interpret Explain Plan Results

Correct answer: A
MongoDB Atlas’s own high-availability guidance recommends exactly this: “you can scale your deployment by adding nodes, regions, or cloud providers to withstand zone, region, or provider outages, respectively,” noting a single-region, three-node deployment only protects against “node or AZ failure within a single region,” while a multi-region (or multi-cloud) deployment additionally protects against a full-region or full-provider outage — all while keeping automatic failover with “RPO = 0 (no data loss)” and “RTO in seconds.”

Why other options are incorrect
B. “A single primary node with multiple backup nodes” isn’t a real Atlas high-availability architecture — Atlas deploys a replica set of multiple data-bearing nodes with automatic election-based failover, not one primary paired with passive “backup nodes.”
C. A single three-node replica set confined to one region protects against node/AZ failure but not a full regional outage, which the scenario specifically calls out (“global,” “minimal downtime… even during unexpected outages”).
D. Atlas’s failover is explicitly automatic, not manual: “This failover process is fully automatic and recovers to the exact moment of failure with no data loss… in seconds.” Manual intervention would introduce exactly the downtime the scenario is trying to avoid.

Source: Guidance for Atlas High Availability

Correct answer: D
MongoDB Atlas documentation explains the purpose of analytics nodes directly: selecting the Analytics read preference lets you “isolate BI Connector for Atlas queries from your operational workload and read from dedicated, read-only analytics nodes,” and “by isolating electable data-bearing nodes from the BI Connector for Atlas, electable nodes don’t compete for resources with BI Connector for Atlas, thus improving cluster reliability and performance.” Analytics nodes exist to keep resource-intensive reporting/BI workloads from competing with the electable nodes serving the primary transactional workload.

Why other options are incorrect
A. Write operations always go through the primary and replicate to secondaries as part of normal replication; analytics nodes (read-only, non-electable) don’t distribute writes — that’s not their function.
B. Analytics nodes can be deployed in any configured region like other replica set members, but geographic distribution is a separate concern (multi-region deployment) from what analytics nodes are specifically for.
C. Analytics nodes are about isolating query workload by directing reads to dedicated members, not about enabling a particular index or search capability like full-text search.

Source: Configure Additional Settings

Correct answer: B
MongoDB documentation lists specific triggers for replica set elections, including: “the secondary members losing connectivity to the primary for more than the configured timeout (10 seconds by default),” along with events like adding a new node, initiating the replica set, or running rs.stepDown() or rs.reconfig(). Losing contact with the primary beyond that timeout is one of the most common real-world triggers, since the secondaries can no longer confirm the primary is healthy.

Why other options are incorrect
A. A client opening a read-only connection is routine application activity and has no effect on replica set membership or primary status.
C. Running a read query on a secondary doesn’t affect replica set health checks or trigger an election.
D. Creating an index is a normal administrative/DDL operation; while it can briefly affect performance, it is not one of the documented election triggers.

Source: Replica Set Elections

Correct answer: C
MongoDB documentation is explicit: “Members with a priority value of 0 cannot become primary and do not seek election.” This is commonly used for members intended to remain secondaries only — for example, a member dedicated to backups or analytics workloads in a specific region — while still allowing them to vote and hold data.

Why other options are incorrect
A. A priority-0 member is specifically excluded from ever becoming primary — the exact opposite of automatically winning every election.
B. Priority influences the timing and likelihood of a member calling or winning an election among eligible members, but it doesn’t multiply that member’s vote count; each voting member still casts one vote.
D. MongoDB’s documentation states directly that “member priority affects both the timing and the outcome of elections,” so priority clearly does matter.

Source: Replica Set Elections

Correct answer: A
MongoDB’s replication documentation explains: “Each operation in the oplog is idempotent. That is, oplog operations produce the same results whether applied once or multiple times to the target dataset.” This is critical because secondaries (and processes like initial sync or point-in-time recovery) may need to reapply oplog entries, and idempotency guarantees that reapplying an already-applied operation doesn’t corrupt the data.

Why other options are incorrect
B. Idempotency doesn’t mean the oplog is safe to delete — it’s a capped collection secondaries depend on to stay in sync; deleting entries a secondary hasn’t yet applied would break replication for that member.
C. All writes in a replica set go through the primary first, which then records them in its oplog for secondaries to copy; idempotency doesn’t change this write path.
D. The oplog is a capped collection with a fixed size (the “oplog window”), not an unlimited store — older entries roll off as new ones are written.

Source: Replica Set Oplog

Correct answer: D
MongoDB documentation defines this directly: “The oplog window is the time difference between the newest and the oldest timestamps in the oplog. If a secondary node loses connection with the primary, it can only use replication to sync up again if the connection is restored within the oplog window.” If the gap is restored within that window, the secondary can catch up by replaying the missed oplog entries; if not, it typically requires a full resync.

Why other options are incorrect
A. Priority determines eligibility and likelihood of winning elections, not whether a disconnected secondary can resync via the oplog.
B. Arbiters hold no data at all and aren’t relevant to a data-bearing secondary’s ability to resync from the oplog.
C. Shard key type affects how data is distributed across a sharded cluster; it has no bearing on a single replica set member’s ability to catch up on missed oplog entries.

Source: Replica Set Oplog

Correct answer: B
MongoDB documentation explains that with { w: 1 }, “data can be rolled back if the primary steps down before the write operations replicate to any of the secondaries,” whereas { w: “majority” } “requests acknowledgment that the calculated majority of data-bearing voting members have durably written the change to their local oplog,” providing durability guarantees that make the acknowledged write far less likely to be lost in a subsequent failover.

Why other options are incorrect
A. Arbiters never hold data, so a write concern can’t require them to persist data; majority write concern is calculated based on data-bearing voting members.
C. Majority write concern does the opposite of disabling replication — it explicitly waits for replication to a majority of members before acknowledging the write, which is safer but not faster than w:1.
D. The documentation directly contrasts the two: w:1 writes can be rolled back on failover in ways majority writes are specifically designed to avoid, so they are not functionally identical.

Source: Write Concern

Correct answer: C
MongoDB documentation describes secondaryPreferred as: “Operations typically read data from secondary members of the replica set. If the replica set has only one single primary member and no other members, operations read data from the primary member.” This matches the requirement exactly — prefer secondaries to offload the primary, but fall back to the primary if no secondary is available.

Why other options are incorrect
A. primary is the default mode and reads only from the primary, which doesn’t offload any read traffic away from it.
B. secondary reads only from secondaries and, per the documentation, “if no secondaries are available, then this read operation produces an error or exception” — it does not fall back to the primary.
D. nearest routes to whichever member (primary or secondary) has the lowest latency; it’s about minimizing latency, not preferring secondaries with a primary fallback specifically.

Source: Read Preference

Correct answer: A
MongoDB documentation describes exactly this use case: “In some circumstances (such as when you have a primary and a secondary, but cost constraints prohibit adding another secondary), you may choose to add an arbiter to your replica set.” An arbiter “participates in elections for primary” and “has exactly 1 election vote,” but “does not have a copy of the data set and cannot become a primary,” making it a lightweight way to restore an odd number of voters without the storage/compute cost of a full data-bearing member.

Why other options are incorrect
B. MongoDB replica sets can have only one primary at a time; “a second primary” isn’t a valid replica set role.
C. A hidden secondary with a full data set still requires the same storage and compute resources as any other data-bearing secondary — it doesn’t solve the cost constraint described.
D. Config servers store metadata for a sharded cluster; they aren’t a substitute for a voting member in a standalone replica set’s election process.

Source: Replica Set Arbiter

Correct answer: D
Atlas’s high-availability documentation states: “Atlas clusters self-heal by promoting an existing secondary node to the role of primary node in a replica set election. This failover process is fully automatic and recovers to the exact moment of failure with no data loss (RPO = 0) in seconds,” confirming this RPO/RTO combination holds “with majority write concern” across the documented deployment paradigms.

Why other options are incorrect
A. Automatic failover with majority write concern is specifically designed to avoid data loss, not to lose 24 hours of data — a very different (and far worse) scenario than a routine primary failover.
B. Atlas failover is explicitly automatic, requiring no manual promotion, and the replica set continues serving reads from secondaries even during the brief election window.
C. Failover is handled through replica set election, not by restoring from a backup snapshot — snapshots address disaster recovery scenarios like data corruption, not routine primary node failures.

Source: Guidance for Atlas High Availability

Correct answer: B
Atlas documentation explains that Continuous Cloud Backup “enhances standard cloud backups by offering Point In Time (PIT) recovery. This additive feature stores snapshots along with the cluster’s oplog to capture data changes between snapshots, enabling you to recover your data to the exact moment (a point in time) right before any failure or event,” supporting “Recovery Point Objectives (RPOs) as low as 1 minute” — squarely addressing scenarios like “a code error that corrupts your entire database.”

Why other options are incorrect
A. Standard Cloud Backup snapshots alone only let you restore to the time of a scheduled snapshot; the RPO is limited to the interval between snapshots, so changes since the last snapshot can’t be surgically excluded.
C. Termination Protection prevents accidental cluster deletion; it has no role in point-in-time data recovery.
D. The Performance Advisor recommends indexes for slow queries; it has no backup or recovery function.

Source: Guidance for Atlas Backups

Correct answer: C
Atlas documentation describes this setting directly: “You can enable termination protection to ensure that a cluster will not be accidentally terminated and require downtime to restore from a backup. To delete a cluster that has termination protection enabled, you must first disable termination protection.” This is especially recommended when using infrastructure-as-code tools, since it prevents an accidental redeploy from deleting live infrastructure.

Why other options are incorrect
A. Read Preference: nearest controls which replica set member handles reads based on latency; it has no relationship to preventing cluster deletion.
B. A partial index is a query optimization/indexing feature, unrelated to protecting a cluster from deletion.
D. The Subset Pattern is a schema design pattern for bounding embedded data; it has no connection to cluster deletion protection.

Source: Guidance for Atlas High Availability

Correct answer: A
MongoDB’s shard key selection documentation explains: “The cardinality of a shard key determines the maximum number of chunks the balancer can create. Where possible, choose a shard key with high cardinality,” giving the example that sharding on a field with only 7 unique values creates a maximum of 7 chunks, capping the cluster at 7 effectively usable shards regardless of how many shards are actually deployed.

Why other options are incorrect
B. Shard key selection doesn’t create additional indexes beyond the shard key index itself; it doesn’t multiply the number of indexes on the collection.
C. Sharding and capped collections are unrelated concepts; choosing a low-cardinality shard key doesn’t convert or require a capped collection.
D. Sharding doesn’t disable replication — each shard in a sharded cluster is typically deployed as its own replica set, independent of the shard key chosen.

Source: Choose a Shard Key

Correct answer: D
MongoDB’s documentation defines this as the “frequency” property of a shard key: “The frequency of the shard key represents how often a given shard key value occurs in the data. If the majority of documents contain only a subset of the possible shard key values, then the chunks storing the documents with those values can become a bottleneck within the cluster.” High overall cardinality alone doesn’t guarantee even distribution if a small number of those values are disproportionately common.

Why other options are incorrect
A. Shard key frequency issues affect data distribution and load balancing across shards; they don’t disable indexing or querying of the collection.
B. MongoDB doesn’t automatically revert a sharded collection back to unsharded because of a frequency imbalance — the imbalance simply persists (and causes hot chunks) unless the DBA addresses it.
C. The documentation explicitly warns that high cardinality alone “does not, on its own, guarantee even distribution of data across the sharded cluster” — frequency still matters.

Source: Choose a Shard Key

Correct answer: B
MongoDB’s documentation describes this directly: “A shard key on a value that increases or decreases monotonically is more likely to distribute inserts to a single chunk within the cluster” because new values always fall at the boundary of the highest (or lowest) chunk, concentrating all new writes on a single shard. The documented recommendation is to “use Hashed Sharding for monotonically changing keys,” since hashing scatters the values — and therefore the corresponding inserts — evenly across the key range.

Why other options are incorrect
A. A monotonically increasing shard key doesn’t prevent reads or require a full collection scan; the issue is uneven write distribution, not read performance, and a text index addresses text search, not this problem.
C. The problem is fixable — hashed sharding is the documented fix — and shard keys aren’t restricted to a single field in general.
D. Shard key monotonicity affects data/write distribution across shards; it has no relationship to replica set elections, a separate replication concern.

Source: Choose a Shard Key

Correct answer: C
MongoDB documentation describes zones for exactly this use case: “In sharded clusters, you can create zones of sharded data based on the shard key. You can associate each zone with one or more shards in the cluster,” listing “geographic locality” as a documented purpose: to “ensure that the most relevant data reside on shards that are geographically closest to the application servers.” The balancer then automatically migrates chunks so that a range of shard key values only lives on the shards associated with its zone.

Why other options are incorrect
A. The database profiler records information about slow operations; it has no role in controlling where sharded data physically resides.
B. A partial index selectively indexes a subset of documents within a single collection based on a filter; it doesn’t control which physical shards store which data ranges.
D. Read Preference: nearest routes reads to the lowest-latency replica set member; it doesn’t control where data is written/stored across shards.

Source: Zones in Sharded Clusters

Correct answer: A
MongoDB documentation states plainly: “Salted Challenge Response Authentication Mechanism (SCRAM) is the default authentication mechanism for MongoDB,” used to “verify the supplied user credentials against the user’s name, password and authentication database.” SCRAM is based on IETF RFC 5802 and uses per-user random salts rather than comparing passwords in plaintext.

Why other options are incorrect
B. x.509 certificate authentication is a supported alternative mechanism, but it must be explicitly configured — it isn’t the mechanism MongoDB falls back to by default for username/password logins.
C. Kerberos is likewise a supported enterprise authentication mechanism that must be explicitly configured; it isn’t MongoDB’s default.
D. MongoDB never compares passwords in plaintext for SCRAM authentication — it uses salted, hashed challenge-response verification, not a plaintext comparison.

Source: SCRAM

Correct answer: D
MongoDB’s access control documentation states: “A role grants privileges to perform sets of actions on defined resources. A role applies to the database on which it is defined and can grant access down to a collection level of granularity,” and built-in roles specifically “define access at the database level for all non-system collections… and at the collection level for all system collections.”

Why other options are incorrect
A. Roles are scoped to the database on which they’re defined, not automatically applied deployment-wide — exactly the scoping the documentation describes.
B. MongoDB’s RBAC model explicitly supports finer granularity than deployment-wide — down to individual collections, not just the whole deployment.
C. MongoDB documentation notes “roles never limit privileges” when a user has multiple roles, implying users can, and often do, hold more than one role at a time.

Source: Built-In Roles

Correct answer: B
Atlas documentation states: “You can create custom roles in Atlas when the built-in roles don’t include your desired set of privileges,” letting a DBA select specific privilege actions scoped to a particular database and collection rather than granting a broader built-in role’s full set of privileges.

Why other options are incorrect
A. Built-in roles are fixed, predefined role definitions in MongoDB and Atlas — they cannot be edited; only custom roles can be created and tailored.
C. An IP access list entry controls which network addresses can connect to a cluster at all; it has nothing to do with scoping a database user’s privileges to a single collection.
D. Creating an entirely separate Atlas project is a drastic, unrelated step for what is simply a privilege-scoping problem that custom roles solve directly.

Source: Configure Custom Database Roles

Correct answer: C
MongoDB documentation is explicit: native Encryption at Rest is “Available in MongoDB Enterprise only… Available for the WiredTiger Storage Engine only.” Encryption occurs transparently at the storage layer, so “all data files are fully encrypted from a filesystem perspective, and data only exists in an unencrypted state in memory and during transmission,” using AES256-CBC by default (with AES256-GCM available on Linux).

Why other options are incorrect
A. Native encryption at rest is not available in MongoDB Community Edition — it’s an Enterprise-only feature.
B. This feature isn’t restricted to capped collections; it encrypts data files at the storage layer regardless of collection type.
D. MongoDB does support native encryption at rest — specifically in Enterprise with the WiredTiger storage engine.

Source: Encryption at Rest

Correct answer: A
MongoDB documentation describes TLS/SSL as something that requires deliberate configuration: “To configure your deployment to use TLS, follow the quickstart,” indicating it must be set up rather than being active out of the box. Once configured, it “encrypt[s] all of MongoDB’s network traffic” so that traffic “is only readable by the intended client,” using strong ciphers with a minimum 128-bit key length.

Why other options are incorrect
B. TLS/SSL is not automatically enabled on a fresh MongoDB installation — a DBA must explicitly configure certificates and enable it.
C. When configured, TLS/SSL can protect both client-to-server and inter-node (member-to-member) traffic, not exclusively inter-node traffic.
D. MongoDB fully supports TLS/SSL when properly configured; it’s a core, well-documented security feature, not something MongoDB is incompatible with.

Source: TLS/SSL (Transport Encryption)

Correct answer: D
Atlas documentation states plainly: “Atlas only allows client connections to the cluster from entries in the project’s IP access list. Each entry is either a single IP address or a CIDR-notated range of addresses,” with support for up to 200 entries per project (100 for certain older sharded clusters) and even temporary entries that auto-expire.

Why other options are incorrect
A. Atlas explicitly restricts connections to only allow-listed addresses by default — it does not allow unrestricted access from any IP address.
B. The IP access list is based on client IP address or CIDR range, not on which cloud region the connecting client happens to be in.
C. The access list is configured by the project’s own administrators to allow their own application’s/organization’s IP addresses — it isn’t restricted to MongoDB, Inc.’s own addresses.

Source: Configure IP Access List Entries

Correct answer: B
MongoDB documentation separates the two clearly: once access control is enabled, “users must authenticate themselves” to prove their identity, after which “MongoDB employs Role-Based Access Control (RBAC) to govern access to a MongoDB system. A user is granted one or more roles that determine the user’s access to database resources and operations. Outside of role assignments, the user has no access to the system.” Authentication answers “who are you?”; authorization (via granted roles) answers “what are you allowed to do?”

Why other options are incorrect
A. These are documented as two distinct steps in MongoDB’s security model — proving identity versus determining permitted actions — not the same process.
C. Authentication occurs first (a user must prove their identity), and authorization/role evaluation happens afterward, based on the roles granted to that authenticated identity — not the reverse.
D. Role-based access control applies to self-managed MongoDB deployments as well as Atlas; the documentation notes only that the specific built-in role definitions differ slightly between Atlas and self-hosted deployments, not that authorization is Atlas-exclusive.

Source: Role-Based Access Control

Correct answer: C
Atlas documentation confirms this capability directly: “Atlas Project Owners can configure an added layer of encryption on their data at rest using the MongoDB Encrypted Storage Engine and their Atlas-compatible Encryption at Rest provider,” explicitly supporting “AWS Key Management Services,” “Azure Key Vault,” and “Google Cloud KMS” as providers, available for M10+ clusters.

Why other options are incorrect
A. The Performance Advisor recommends indexes to fix slow queries; it has no relationship to encryption key management.
B. Namespace Insights reports collection-level query latency; it’s unrelated to encryption at rest or key management.
D. Zone sharding controls which shards store which ranges of data geographically; it has no connection to managing encryption keys.

Source: Configure Additional Settings