C100DBA MongoDB Associate Database Administrator(Based on MongoDB 6.0 and 7.0+) Question and Answers

The query contains equality predicates on both city and occupation, so an efficient compound index should contain both fields. Options A and C include only one query predicate plus the unrelated name field, forcing MongoDB to perform additional filtering that the index cannot resolve. Options B and D both contain the complete predicate set. For a query consisting entirely of equality predicates, MongoDB does not require those equality keys to appear in a particular order relative to one another for the query itself; { city: 1, occupation: 1 } and { occupation: 1, city: 1 } can both support the two equality conditions effectively. The original question appears to expect B because it mirrors the field order used in the query, but that distinction is not technically required under MongoDB ' s equality-key guidance. Field order becomes much more significant when the workload also needs a particular index prefix, sort order, range predicate, or when one ordering better supports additional common queries. Accordingly, the technically accurate review result is B and D, with B being the likely intended exam choice.

Study Guide reference/topic:Indexing and Query Optimization - compound indexes, equality predicates, and index key ordering.

===========

db.currentOp() is the mongosh helper used to inspect operations currently executing on a MongoDB server. Passing true requests a broad view that includes all in-progress operations as well as additional idle/system entries, so it can be used when the administrator wants to see the complete current-operation picture. The database-command form, db.adminCommand({ currentOp: true }), invokes the corresponding administrative command and is also valid for obtaining in-progress operation information. Option A adds a filter restricting the result to operations whose op field is " command " ; it therefore does not represent all operation types. Option B is not valid currentOp command syntax, and option E uses an all field that is not the documented special form for this helper. In modern MongoDB administration, the $currentOp aggregation stage is generally preferred for richer filtering and aggregation, but the question is testing the traditional helper and command interfaces. Therefore, C and D are the two valid choices among those presented.

Study Guide reference/topic:Performance Monitoring and Tuning - current operations, currentOp, and administrative diagnostics.

===========

updateMany() distinguishes between documents that match the filter and documents whose stored data actually changes. The filter { diagnosis: " Hypertension " } matches Carlos Martinez and Maria Lopez, so matchedCount is 2. Carlos currently has room: 203, and $set: { room: 207 } changes his document, contributing one to modifiedCount. Maria already has room: 207. She still satisfies the filter and therefore counts as a match, but setting a field to the value it already contains does not produce a material modification, so she does not increment modifiedCount. Juan Perez has diagnosis Arrhythmia, so he is neither matched nor modified. The resulting acknowledged operation therefore reports matchedCount: 2 and modifiedCount: 1, corresponding to option D. This distinction is essential when validating whether an update actually changed stored values rather than merely identifying matching records. This distinction is operationally important: a large difference between matched and modified counts can indicate that many matching documents already contained the requested state, not that the update failed. DBAs should use both counters when validating bulk-update behavior.

Study Guide reference/topic:MongoDB Architecture and Core Operations - updateMany(), $set, matchedCount, and modifiedCount.

===========

An upsert combines update behavior with conditional insertion. updateOne() first searches for a document matching { product: " laptop " }. If one exists, $set changes unitsInStock to 25. If none exists and the options document contains { upsert: true }, MongoDB inserts a new document based on the equality portions of the filter together with the update result. Option A uses exactly this pattern. Options B and C incorrectly use insertOne(), which inserts a supplied document and does not accept an update-operator document plus upsert semantics in this form. Option D uses the correct method and update structure but specifies True with a capital T. Mongosh uses JavaScript Boolean syntax, so the literal must be lowercase true. Upserts are useful when an application needs to ensure that a logical entity exists after an operation, but DBAs should consider a unique index on the identifying field when duplicate creation by concurrent requests must be prevented. Given the choices, updateOne(..., {$set:...}, {upsert:true}) is the valid operation, so A is correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - updateOne(), $set, upserts, and Boolean syntax.

===========

For a compound index to satisfy a multi-field sort, the indexed fields must occur in the same sequence as the sort specification, and their directions must either match the requested pattern or be the complete reverse of it. The query sorts by { department: 1, salary: -1 }, so option B exactly matches both the key order and the requested directions. MongoDB can scan that index and return the results already ordered, avoiding a blocking in-memory sort. Option A uses { department: 1, salary: 1 }, which does not match the mixed-direction sort and is not its full inverse. Option D puts name before the two sort keys. Because the query has no equality predicate on name, that leading key prevents the later fields from directly providing the requested global sort. Option C is not a sensible index definition for this workload. Separately, the displayed projection mixes inclusion and exclusion (name:1, salary:1, department:0), which MongoDB normally disallows except for _id; that syntax issue should be corrected independently. It does not change the intended index answer for the sort, which is B.

Study Guide reference/topic:Indexing and Query Optimization - compound indexes, sort support, index prefixes, and key direction.

===========

A hidden index remains physically present and continues to be maintained as documents are inserted, updated, or deleted, but the query planner does not consider that index when choosing normal execution plans. This makes hidden indexes especially useful for safely testing whether an index can be removed. An administrator can hide the index and observe production query behavior as though the index were absent. If performance or plan quality degrades, the index can be unhidden immediately without rebuilding it because MongoDB has continued to maintain it in the background. Option A is incorrect because a hidden index is still an index and is not simply removed from index statistics. Option B is also incorrect; hiding an index can actually force collection scans or alternative plans if that index was previously important. Option D misunderstands the feature entirely: hiding an index has no effect on document visibility. Hidden indexes are therefore a risk-reduction mechanism for index lifecycle management, especially before dropping an index in a production environment. Option C accurately states that purpose.

Study Guide reference/topic:Indexing and Query Optimization - hidden indexes, query planner behavior, and safe index-removal testing.

===========

Filesystem snapshots and mongodump are both recognized approaches for backing up self-managed MongoDB deployments, including replica sets. Filesystem snapshots capture the storage volume at a point in time and can be very efficient for large deployments when the underlying storage platform provides consistent snapshot functionality. mongodump creates a logical BSON backup of database contents and supports replica-set-aware options; when writes continue during the dump, oplog capture can be used to support a consistent restore point. The other tools serve different purposes. mongoexport exports collection data to JSON or CSV for interchange or reporting but is not a full-fidelity database backup solution. mongofiles manages content stored in GridFS rather than backing up the database. bsondump reads BSON dump files and renders their contents in a human-readable form; it does not create the original database backup. A sound production strategy also includes restore testing, retention policies, off-site copies, and recovery-point/recovery-time objectives. For the specific choices offered, the two valid backup methods are filesystem snapshots and mongodump, so C and E are correct.

Study Guide reference/topic:Cluster Reliability and Data Resilience - backup strategies, filesystem snapshots, mongodump, and restore planning.

===========

db.currentOp() reports information about operations that are currently in progress and accepts a filter document to restrict the output. The ns field in current-operation information identifies the namespace, typically in database.collection form. The regular expression /^qa\./ therefore matches namespaces beginning with qa., which isolates operations targeting collections in the qa database. Option C correctly supplies that namespace expression as a filter argument to db.currentOp(). Options A and B use a nonexistent db.listOps interface. Option D incorrectly treats ns as though it were a property or method chained from db.currentOp; filtering belongs inside the argument document. On current MongoDB versions, administrators are encouraged to use the $currentOp aggregation stage for more powerful filtering and composition, but the legacy helper remains the interface being tested here. Once the problematic operation is identified, the DBA can inspect details such as operation type, namespace, duration, waiting state, and client information before deciding whether additional action such as optimization or termination is justified. Thus C is the correct command.

Study Guide reference/topic:Performance Monitoring and Tuning - active operations, namespaces, long-running operation diagnostics, and currentOp.

===========

The outer $or returns a document if either branch is true. Document 1 satisfies the first branch because product equals " x-small box " , so it is included regardless of the second branch. The nested $and requires both qty != 50 and the absence of " brown " from the colors array. Document 2 has quantity 60 but contains " brown " , so it fails $nin. Document 3 has quantity 45 and its colors do not include brown, so it satisfies both conditions. Document 4 has no brown but quantity is exactly 50, so it fails $ne: 50. Document 5 has quantity 10 and colors [ ' grey ' , ' white ' ], so it also satisfies both nested predicates. The final set is therefore documents 1, 3, and 5. This question also illustrates that MongoDB applies an implicit AND between multiple top-level field predicates in the same document, but here the explicit $and makes the required conjunction clear. Option D is the only answer containing exactly the matching documents.

Study Guide reference/topic:MongoDB Architecture and Core Operations - logical query operators, $or, $and, $ne, and $nin.

===========

MongoDB read preference controls which replica-set members are eligible to serve read operations. The mode secondary sends reads only to eligible secondary members. If no suitable secondary is available, the read fails rather than falling back to the primary. That strict behavior is exactly what the question asks for. secondaryPreferred, option A, normally routes reads to secondaries but can use the primary when no suitable secondary is available, so it does not guarantee that every read is served by a secondary. Options B and C are not valid MongoDB read preference mode names. Secondary reads are useful for specific workloads, but DBAs must account for asynchronous replication: a secondary can lag the primary, so data returned from a secondary may be stale relative to the latest acknowledged primary write. MongoDB provides additional controls such as tag sets and maximum staleness settings to restrict which secondary members are considered acceptable. When the explicit requirement is to direct all reads away from the primary and exclusively to secondary members, secondary is the correct read preference. Therefore option D is correct.

Study Guide reference/topic:Cluster Reliability and Data Resilience - replica-set read preferences, secondary reads, and staleness.

===========

Adding replica-set members addresses availability and recovery objectives. A normal secondary maintains a replicated copy of the primary ' s data and can be elected primary if the current primary becomes unavailable, thereby improving service availability compared with a single-node deployment. That directly supports option D. A delayed member intentionally applies oplog entries later than the primary, preserving an older logical state of the dataset for a configured delay period. This can help recover from operator mistakes such as an accidental destructive update or drop operation because the administrator may be able to access the delayed copy before the damaging operation is applied there. That supports option A. A delayed member is not a substitute for long-term archival or a formal backup-retention policy; its recoverable history is constrained by the delay configuration and oplog window, so B is not the intended objective. Option C describes sharding, which partitions data across shards rather than simply replicating it. Encryption at rest is configured independently and is unrelated to adding secondaries or delayed members. Therefore, A and D are the two reasons that align with the proposed replication design.

Study Guide reference/topic:Cluster Reliability and Data Resilience - replica sets, delayed members, failover, and operator-error recovery.

===========

A replica-set secondary maintains a replicated copy of the primary ' s dataset. The primary records data-changing operations in its oplog, and secondary members continuously copy and apply those oplog entries asynchronously to keep their data synchronized. This redundancy allows an eligible secondary to participate in an election and potentially become primary if the current primary becomes unavailable. mongos, option B, is the query-routing process used in a sharded cluster; it does not store an application dataset copy. An arbiter, option C, participates in replica-set voting and elections but deliberately does not maintain a copy of the database data. A shard, option D, is a data partition in a sharded cluster and is normally implemented as a replica set in production, but “shard” is not the replica-set member role that replicates the primary ' s data. Secondary behavior is central to MongoDB high availability, read-scaling options, backup strategies, and failover. Administrators monitor secondary replication lag and health to ensure the copies remain sufficiently current. Therefore the member responsible for maintaining copies of the primary ' s data is the secondary, making option A correct.

Study Guide reference/topic:Cluster Reliability and Data Resilience - replica-set primaries, secondaries, oplog replication, and redundancy.

===========

mongosh accepts a MongoDB host address in hostname:port form, so mongosh " node-1.cluster1.mycompany.local:27017 " is the valid choice among the commands shown. A canonical URI form such as mongosh " mongodb://node-1.cluster1.mycompany.local:27017 " is also valid, and the connection can alternatively be expressed using --host together with --port. Option A uses an unsupported --hostname switch rather than the documented --host option. Option B invents a --connect flag that is not the standard mongosh interface. Option C constructs an invalid string using an ampersand-style parameter rather than a MongoDB URI or a normal host:port target. Port 27017 is MongoDB ' s default server port, so it could often be omitted if the deployment uses the default, but explicitly including it is valid and removes ambiguity. In authenticated or TLS-enabled environments, the DBA would also supply credentials, authentication database, certificate settings, or a connection string carrying those parameters. For the simple host-and-port requirement in the question, option D is correct.

Study Guide reference/topic:Security, Networking, and Encryption - mongosh connectivity, host/port addressing, and connection options.

===========

MongoDB ' s flexible document schema is a defining distinction from the conventional fixed-table model associated with relational database systems. Documents in the same MongoDB collection can contain different fields, nested structures, arrays, or representations when the application domain requires that flexibility. MongoDB can still enforce schema rules through validation, so a flexible schema does not mean the absence of governance; it means the physical model is not inherently restricted to one rigid row structure for every record. The other choices are not sufficiently distinguishing. Relational database platforms can provide replication, authentication, and horizontal partitioning or sharding techniques, so those capabilities are not unique architectural differences. MongoDB ' s BSON document model also allows data that is commonly normalized across multiple relational tables to be embedded within one application-oriented document where that design is appropriate. This can reduce joins and map more naturally to object structures used by applications. DBAs must still choose schemas carefully based on access patterns, document growth, duplication, and consistency requirements. Among the choices, Flexible Schema most accurately represents a fundamental MongoDB-versus-RDBMS difference, so option D is correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - document databases, BSON data modeling, flexible schemas, and relational-model differences.

===========