Free MongoDB C100DBA Practice Exam with Questions & Answers | Set: 3

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.

===========

connections.totalCreated is a cumulative count of incoming connections created during the lifetime of the running MongoDB server process. It includes connections that are still open as well as connections that have already closed. That is why the example can show totalCreated: 5 while current: 4: five connections have been created since the process started, but only four remain current. Option A is incorrect because the counter is not limited to closed connections. Option C corresponds more closely to connections.current, which reports presently existing incoming client connections. Option B is imprecise because “since the server was set up” could imply the lifetime of the installation or deployment across restarts, whereas server-status counters generally reflect the current process lifetime. Tracking totalCreated alongside current, active, and connection-pool behavior helps administrators identify excessive connection churn, poorly configured client pools, or bursts of new connections. The most accurate interpretation among the choices is therefore the number of connections created since the server process was started, making D correct.

Study Guide reference/topic:Performance Monitoring and Tuning - serverStatus, connection metrics, and cumulative connection counters.

===========

MongoDB stores records as BSON documents. BSON, short for Binary JSON, is a binary serialization format that preserves the JSON-like document model while supporting a richer set of data types required by database applications. Mongosh commonly displays documents using JavaScript or Extended JSON-like notation, which is why JSON is a tempting distractor, but the native stored representation is BSON. BSON supports types such as ObjectId, dates, binary data, timestamps, Decimal128, 32-bit and 64-bit integers, arrays, embedded documents, and other values that standard JSON does not represent natively. Base64 is an encoding technique often used to render binary data as text and is not MongoDB ' s document storage format. XML is also unrelated to MongoDB ' s native representation. Understanding BSON is fundamental for database administrators because document-size limits, type comparisons, index keys, serialization behavior, and driver interoperability all depend on BSON semantics. The flexible document model allows fields to contain scalar values, nested documents, and arrays within the same record structure. Therefore the encoded format used by MongoDB to store documents is BSON, making option C correct.

Study Guide reference/topic:MongoDB Architecture and Core Operations - BSON, document structure, data types, and JSON/BSON distinctions.

===========

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.

===========

MongoDB custom roles are defined in terms of privileges, and each privilege specifies a resource plus one or more allowed actions. For read/query access, find is a valid privilege action. To represent all normal collections in a specified database, MongoDB uses a resource document with the target database and an empty collection name, for example { db: " products " , collection: " " }. Option B therefore combines the correct resource scope with the find action and does not grant write capability. The distractors confuse built-in role names with privilege actions. read, readWrite, and readAnyDatabase are built-in roles or role concepts, not the appropriate action values for the privileges[].actions list shown here. Likewise, a literal " * " collection value is not the documented database-wide resource form for this custom privilege. In practice, an administrator could also assign MongoDB ' s built-in read role rather than creating a custom role if its permissions exactly match the requirement. Given the specific createRole() choices, however, option B is the technically correct construction.

Study Guide reference/topic:Security, Networking, and Encryption - RBAC, custom roles, resources, and privilege actions.

===========