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

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.

===========

The first argument to find() is the query filter and the second argument is the projection. Because the requirement applies to every employee, the filter must be an empty document {}. The projection must include name and age while explicitly suppressing _id. MongoDB includes _id by default even in inclusion projections, so { name: 1, age: 1 } would return three fields: _id, name, and age. Adding _id: 0 is the documented exception that allows _id to be excluded from an otherwise inclusion-style projection. Option C therefore produces exactly the requested fields. Options A and B mistakenly place projection-like expressions in the filter position, which would cause MongoDB to search for documents where those fields literally match the specified values rather than controlling returned fields. Option D is close but violates the word “ONLY” because _id remains present. Projection design can also reduce network traffic and, when a suitable index covers both the predicate and projected fields, can contribute to covered-query plans. For this requirement, however, the essential syntax is find({}, {name:1, age:1, _id:0}), so C is correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - find(), filters, projections, inclusion fields, and _id exclusion.

===========

db.collection.deleteOne() deletes a single document that matches the supplied filter, so the direct operation is db.scientificPapers.deleteOne({ doi: " 10.1000/xyz123 " }). The DOI is the identifying criterion, and no additional filter is required. Option A is dangerous and incorrect: drop() removes the entire collection and its indexes rather than deleting a filtered document. Option B uses findOneAndDelete(), which can delete a single matching document, but the displayed filter also requires a nonexistent or inappropriate field/value pair, scientificPapers: " orders " , so the target document would not match. Option D misunderstands the method signature. The second argument to deleteOne() is an options document for settings such as write concern, collation, or hint; it is not a second query predicate. In production, a unique index on DOI could also ensure that the business identifier is unique and make the deletion highly selective. Among the presented commands, only option C cleanly and correctly deletes the one scientific-paper document identified by the specified DOI.

Study Guide reference/topic:MongoDB Architecture and Core Operations - delete operations, deleteOne(), filters, and collection management.

===========

MongoDB supports direct equality matching against elements contained in an array. When the predicate is { sizes: " M " } and sizes is an array field, a document matches when at least one element of the array equals the scalar value " M " . Document 1 contains only " XS " and " S " , so it does not match. Document 2 contains " M " in [ ' S ' , ' M ' , ' XL ' ], and document 3 contains " M " in [ ' M ' , ' L ' , ' XL ' , ' XXL ' ]; both therefore match. No $elemMatch expression is required for this simple scalar membership test. $elemMatch becomes important when multiple conditions must be satisfied by the same array element, particularly for arrays of embedded documents or compound conditions. This array equality behavior is a core part of MongoDB ' s document query model and allows concise filtering of array-valued fields. The correct result is consequently the t-shirt and vest documents, which corresponds to option D. This same matching behavior applies consistently whenever a scalar predicate targets values stored inside a BSON array field.

Study Guide reference/topic:MongoDB Architecture and Core Operations - querying array fields and equality predicates.

===========

The supported mongosh helpers for replica-set membership changes are rs.remove() and rs.add(). rs.remove(hostname) removes the member whose host string matches the supplied host:port, while rs.add() adds a new member using either a host string or a member configuration document that includes a host field. Option C uses those documented methods in the required sequence: remove node 1, remove node 2, then add node 1 back. The names rs.removeNode() and rs.addNode() shown in the other options are not standard MongoDB replica-set helper methods. Membership changes must be performed carefully because modifying voting or data-bearing membership can affect majority calculations, elections, and availability. Administrators normally execute membership changes while connected to the current primary, allow configuration propagation, and verify replica-set health afterward with rs.status() or related diagnostics. If a removed data-bearing node is later re-added, it may need to synchronize depending on how far its data has diverged from the current replica-set history. Among the choices, option C is the only valid command sequence.

Study Guide reference/topic:Cluster Reliability and Data Resilience - replica-set membership, rs.remove(), rs.add(), and topology changes.

===========

MongoDB Enterprise auditing supports three standard destination values for audit events: syslog, file, and console. With the syslog destination, audit records are sent to the operating system ' s syslog facility where supported. With the file destination, events are written to a configured audit log path, and administrators can control the output format according to the supported audit configuration. With the console destination, audit events are emitted to standard output, which can be useful in containerized or centrally collected logging environments. A raw TCP/IP port is not itself an auditLog.destination value. Organizations can certainly forward logs over the network using operating-system or observability tooling, but that transport is external to MongoDB ' s destination setting. A MongoDB database is likewise not one of the supported audit destinations; keeping audit evidence independent from the system being audited is also preferable for integrity and compliance. Auditing records security-relevant actions and can be filtered to meet regulatory or operational requirements. Therefore the three valid destinations among the choices are syslog, file, and console: A, B, and E.

Study Guide reference/topic:Security, Networking, and Encryption - auditing, auditLog.destination, compliance logging, and audit configuration.

===========

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.

===========

Encryption at rest protects persisted database data on storage media, but it is not a complete defense against every form of data exposure or breach. MongoDB ' s encrypted storage capabilities protect files and storage-level data, yet applications and the database server must still process authorized data in usable form. A compromised application account, stolen database credentials, excessive privileges, or a malicious authorized user can therefore expose data even when the underlying storage is encrypted. Network traffic also requires separate transport protection such as TLS; encryption at rest does not secure data as it travels between clients and servers. Option B incorrectly describes transport encryption rather than an at-rest capability. Option A is too subjective and not an inherent limitation, particularly in managed deployments where storage encryption may be enabled automatically. Option D is similarly overstated; encryption adds cryptographic work, but severe performance impact is not an intrinsic defining limitation. The correct security model is defense in depth: combine at-rest encryption with TLS, strong authentication, least-privilege authorization, auditing, and secure key management. Among the choices, C best captures the limitation that at-rest encryption alone cannot prevent all data breaches.

Study Guide reference/topic:Security, Networking, and Encryption - encryption at rest, TLS, authorization, and defense in depth.

===========

The documented mongosh helper is db.revokeRolesFromUser(), and its second argument is an array of roles to revoke. MongoDB permits each role in that array to be expressed either as an explicit document { role: < roleName > , db: < database > } or, when the role belongs to the database in which the command is run, as a simple role-name string. Option C uses the explicit role-document form and is therefore valid for a role named specialRole defined in myDB. Option E uses the shorthand string form and is valid when specialRole is in the current database context. Option A reverses the required document structure and does not supply the mandatory role and db keys. Options B and D use a singular helper, db.revokeRoleFromUser(), which is not the documented MongoDB method. The plural method name reflects that multiple roles can be revoked in a single operation. Administrators should also remember that revoking a directly assigned role does not necessarily remove privileges inherited through other roles. Among the choices, C and E are the syntactically valid revocation forms.

Study Guide reference/topic:Security, Networking, and Encryption - RBAC, user administration, and revokeRolesFromUser().

===========

MongoDB write concern defines the level of acknowledgment requested for a write. Setting the numeric value w: 1 means that a write is considered acknowledged after the primary has accepted it; no secondary acknowledgment is required. In a replica set with one primary and two secondaries, those secondaries can replicate the operation asynchronously after the client has already received success. That configuration is represented by { writeConcern: { w: 1 } }, making option D correct. The numeric type matters: w can be specified as an integer count or certain strings such as " majority " , but the string " 1 " is not the intended numeric node count shown by the question. Options B and C also omit the w field structure expected inside a write concern document. The durability trade-off is important: a w:1 write can be acknowledged before any secondary has replicated it, so a sudden primary failure before replication may result in that write being rolled back after failover. If the workload requires stronger durability, w: " majority " is commonly used. For exactly one acknowledging node, however, the correct setting is D.

Study Guide reference/topic:Cluster Reliability and Data Resilience - write concern, w acknowledgments, replica-set durability, and rollback risk.

===========

Sharding is MongoDB ' s horizontal-scaling mechanism: it partitions a collection ' s data across multiple shards so a deployment can scale storage capacity and distribute query or write workload beyond the limits of one server. That directly supports deployments with very large datasets and high-throughput operations, making C correct. MongoDB also supports zone sharding, which associates ranges of shard-key values with selected shards. Zones can be used to keep particular data near a geographical region, satisfy locality requirements, or map data ranges to hardware tiers, so A is also correct. Option B overstates what sharding itself provides; cross-region consistency behavior depends on replication topology, read/write concerns, latency, and application design rather than simply enabling sharding. Option D describes a deployment that already fits comfortably in memory and meets performance goals, so sharding may add unnecessary operational complexity. Option E primarily describes replication: replica sets maintain redundant copies, provide elections, and improve availability. Production shards are themselves normally replica sets, but redundancy is a replication function rather than the defining purpose of sharding. Therefore the two functions represented here are geographic zone distribution and horizontal scale: A and C.

Study Guide reference/topic:Sharding Strategies and Scalable Deployments - horizontal scaling, large datasets, throughput, shard keys, and zone sharding.

mongosh, the MongoDB Shell, is the interactive command-line environment used to connect to MongoDB deployments and perform administrative and data operations. Through mongosh, a DBA can run CRUD queries, aggregation pipelines, user and role administration, replica-set commands, server diagnostics, index operations, and many other management tasks. mongod, option B, is the MongoDB database server process itself; it stores data and serves requests but is not the interactive administration client. mongostat, option C, is a monitoring utility that reports a concise stream of server activity metrics such as operation rates, memory, connections, and queue information. mongotop, option D, reports time spent reading and writing data by namespace and is likewise a diagnostic utility rather than a general administration shell. DBAs may also use MongoDB Compass, Atlas interfaces, Ops Manager, or automation tooling depending on the deployment, but among these four command-line tools, mongosh is the one intended for broad interactive access and administration. Therefore option A is correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - MongoDB Shell, administration tools, server processes, and monitoring utilities.

===========

replaceOne() replaces the matched document ' s content with the replacement document, except that the immutable _id value is preserved when it is not explicitly changed. Ordinary application fields that are omitted from the replacement disappear. The required final document must retain userid, retain first, and change roles to " SuperUser " . Option B supplies all three fields and therefore produces the requested document structure. Option A omits userid, so that ordinary field would be removed from the replacement. Option C omits both userid and first, leaving only roles in addition to the preserved _id. Option D incorrectly uses the update operator $set inside a replacement document. $set belongs with update operations such as updateOne() or updateMany(); a replaceOne() replacement must be a replacement document rather than an update-operator document. This distinction is important for DBAs and application developers because accidental use of a partial replacement can delete fields that were intended to remain. If the goal is only to change one field, updateOne({userid:1}, {$set:{roles: " SuperUser " }}) would normally be safer. Given the choices, B is correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - replaceOne(), full-document replacement, and update-versus-replacement semantics.

===========

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.

===========

MongoDB equality filters use the form { field: value }. To return the document whose name field contains the exact string " Poppy " , the query therefore uses { name: " Poppy " }, as shown in option D. This shorthand equality syntax is equivalent to explicitly using $eq. Option B uses the correct field but the value is lowercase " poppy " . Normal MongoDB string equality is case-sensitive unless a suitable collation or another case-insensitive technique is deliberately configured, so it does not match the displayed " Poppy " value. Option A uses name.Poppy as a dot-notation path. Dot notation is for accessing a nested field inside an embedded document, but here name stores a scalar string and has no nested Poppy field. Option C searches for a field literally named Poppy, which the sample documents do not contain. This question tests the basic field/value predicate syntax used by find(). The correct command is db.contacts.find({ " name " : " Poppy " }), making option D correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - find(), equality predicates, string matching, and dot notation.

===========

Replica-set elections determine which eligible member serves as primary. An election can occur after the current primary becomes unavailable, after certain reconfigurations, during replica-set initialization, or when a primary is deliberately stepped down. Eligible voting members exchange election information and, when a candidate obtains the required support, that candidate transitions to primary and begins accepting writes. Option A describes asynchronous replication through the oplog, which is a separate mechanism. Option C is unrelated: index creation is an administrative database operation, not a function of elections. Option D is also incorrect because elections do not add members to the replica-set configuration; adding a secondary requires an explicit membership change such as rs.add() or equivalent configuration management. Elections are the foundation of automatic failover and are one reason MongoDB replica sets can provide high availability without a human manually designating a replacement primary after every failure. During an election there can be a brief period in which writes are unavailable, so applications should use retryable behavior and appropriate driver topology handling. The purpose described in option B is therefore correct.

Study Guide reference/topic:Cluster Reliability and Data Resilience - replica-set elections, primary selection, voting, and automatic failover.

===========

The quantity condition is “less than or equal to 1000,” which maps to MongoDB ' s $lte comparison operator. The sales representative condition is “not equal to Anne,” which maps to $ne. When predicates on two different fields appear in the same query document, MongoDB applies an implicit logical AND, so both conditions must be true for a document to match. Option C therefore expresses exactly the requested filter: { quantity: { $lte: 1000 }, salesRep: { $ne: " Anne " } }. Options A and D use $neq, which is not MongoDB ' s inequality operator. Options B and D use $lt, which excludes documents whose quantity is exactly 1000 and therefore fails the “less than or equal” requirement. One nuance of $ne is that it can also match documents where the field is missing, because a missing field is not equal to the specified value. If the application requires salesRep to exist as well, an explicit existence predicate may be appropriate. For the wording shown, however, option C is the correct command.

Study Guide reference/topic:MongoDB Architecture and Core Operations - comparison predicates, $lte, $ne, and implicit AND semantics.

===========