Part 5 Full Quiz — CMDB & CSDM

B is correct. A CI is any component — physical or logical — that is managed and tracked in the CMDB: servers, applications, services, databases, network devices, virtual machines, and more. CIs are NOT limited to hardware (C) — software, services, and logical constructs are equally valid CIs. Not every ServiceNow record is a CI (A). The CMDB exists to track infrastructure dependencies and support change management, incident impact analysis, and asset lifecycle.

B is correct. The CMDB class hierarchy is: cmdb (base CMDB table) → cmdb_ci (base CI class, extends cmdb, adds CI-specific fields like Name, Asset Tag, Serial Number, Status) → specific CI types like cmdb_ci_server, cmdb_ci_computer, cmdb_ci_appl. All CIs extend cmdb_ci directly or through intermediate classes. For a Windows Server, use cmdb_ci_win_server (most specific) or cmdb_ci_server. cmdb itself is the base but CIs live in cmdb_ci and its children.

B is correct. cmdb is the root of the CMDB hierarchy — it is the grandparent table. cmdb_ci extends cmdb and serves as the base class for all actual CI records, adding essential CI fields (Name, Class, Asset Tag, etc.). All specific CI classes (cmdb_ci_server, cmdb_ci_appl, etc.) extend cmdb_ci, not cmdb directly. They are not aliases (A), not split by hardware/software (C), and cmdb_ci is very much still in use (D).

B is correct. Specific CI classes provide: (1) domain-specific fields — router classes have port counts, routing protocols; server classes have CPU/RAM fields; (2) class-specific Discovery patterns — Discovery uses CI class to know what attributes to collect; (3) precise IRE identification rules — IRE uses class-specific identifiers; (4) targeted reporting and CMDB Health. Using cmdb_ci for everything loses these benefits and reduces data quality.

B is correct. In CMDB relationship direction, the hosting/infrastructure CI is upstream (parent). For "Application Runs on Database Server": the Database Server is the upstream/parent; the Application is the downstream/child. This matters for Service Maps and impact analysis — if the Database Server fails, the Application (child) is impacted. The direction is: infrastructure → application, not application → infrastructure.

B is correct. The CMDB relationship 3 C's: Contain — a parent CI physically/logically contains child CIs (e.g., a rack contains servers); Connect — CIs are networked or communicate with each other (e.g., server connects to switch); Control — a management CI controls another (e.g., a cluster controls its nodes). Understanding these categories helps classify relationship types and understand CMDB service dependency maps.

B is correct. The Service Map (accessible from a Business Service CI) visualises the full CMDB relationship chain — from Business Service down through all infrastructure CIs. When a CI has an active Incident or Change, the Service Map highlights impacted components in the dependency tree, making it immediately clear what services are at risk. This is the primary value of maintaining CMDB relationships. Task SLAs (C) and Audit History (D) do not show relationship-based impact.

B is correct. Relationship types (stored in cmdb_rel_type) give semantic meaning — "Application X Runs On Server Y" conveys the nature of the dependency. This semantic meaning enables: (1) directional Service Map visualisation; (2) impact analysis that understands hosting vs connectivity vs containment; (3) clear documentation for change management. Without a meaningful type, a relationship just says "A is somehow related to B" — much less useful for impact assessment.

B is correct. The IRE (Identification & Reconciliation Engine) solves two problems: (1) Identification — when new CI data arrives (from Discovery, SCCM, or any source), IRE uses identification rules to determine if a matching CI already exists in the CMDB (preventing duplicates); (2) Reconciliation — when multiple sources provide conflicting values for the same CI attribute, IRE applies precedence rules to determine which source wins. Discovery (A) scans networks; IRE processes Discovery results.

C is correct. IRE uses the Serial Number as an identification rule to match the incoming Discovery data to the existing CI. Once matched (no duplicate created), IRE applies reconciliation rules to resolve the attribute conflicts — each attribute can have a source priority list (e.g., Discovery > SCCM > Manual). The existing CI is updated with the reconciled values. Creating duplicates (A) is exactly what IRE is designed to prevent. Deleting (B) and flagging for manual review (D) are not default IRE behavior.

B is correct. An Identification Rule tells IRE: "to identify a cmdb_ci_server, check if a record already exists with matching Serial Number AND/OR IP Address." The identifier fields are the "keys" used for lookup. If a match is found: update existing CI. If no match: create new CI. Without well-defined identification rules, every Discovery run would create duplicate CIs. Identification Rules are the foundation of CMDB data quality via IRE.

B is correct. CMDB Health measures three dimensions: (1) Completeness — percentage of CIs with all required attributes populated; (2) Compliance — CIs that meet defined rules/standards; (3) Correctness (sometimes called Accuracy) — data validated against source of truth. A 38% completeness score means most CIs are missing required fields — a data quality problem requiring attention. Discovery coverage (A) and certification (D) are separate concerns.

B is correct. A Staleness Rule flags CIs for the CMDB Health dashboard — it is purely a reporting/visibility indicator. The stale CI record continues to exist unchanged. ServiceNow does NOT automatically delete (A), create incidents (C), or trigger Discovery (D) as a result of staleness alone. These remediation actions would require additional custom automations (Scheduled Jobs, Event Rules) built on top of the staleness data. The staleness flag is an alert, not an action.

B is correct. IRE Reconciliation Rules define source precedence per attribute: e.g., "for IP Address, Discovery wins; for Owner, Manual entry wins; for OS Version, SCCM wins." This gives fine-grained control over which source is authoritative per field. Last-write-wins (A) is chaotic and unpredictable. Locking CIs (C) prevents legitimate automated updates. Separate records per source (D) defeats the purpose of the CMDB — you'd have no single truth.

B is correct. The three core CMDB Health dimensions: Completeness — are all required/expected attributes populated? (this question); Compliance — do CIs adhere to defined governance rules and standards?; Correctness/Accuracy — is the data in the CMDB accurate and verified against a source of truth? "Owner and Location populated" is a completeness check — it measures whether data exists, not whether it's accurate or policy-compliant.

C is correct. Horizontal Discovery classifies the CI and records the IP address. Vertical Discovery then connects via SSH/WMI to collect detailed attributes: CPU count, RAM, OS. If Vertical fails (missing credentials, pattern gaps, network access issues), the CI exists with basic identity data but no detail attributes — exactly the pattern described. Check credential coverage and Vertical Pattern matching for the specific CI class. This connects Part 3 Discovery phases with Part 5 CMDB Health.

B is correct. Absent is a CMDB Data Manager workflow state — it represents a CI that no data source has confirmed within the configured threshold. It does NOT correspond to any operational_status value. The standard operational_status OOTB list: 1=Operational, 2=Non-Operational, 3=Repair in Progress, 4=DR Standby, 5=Ready, 6=Retired, 7=Pipeline, 8=Catalog. No 'Absent' slot. This is a very high-frequency exam trap also addressed in Part 6 Topic 6.

B is correct. In cmdb_rel_ci, 'parent Runs on child' means the parent DEPENDS ON the child. The Application Service (parent) runs on the server (child) — server downtime cascades upstream. The Dependency View visualizes exactly this impact chain. This connects Part 5 Topic 2 (CI Relationships) with the CSDM service model (Topics 6-7) and how CMDB supports Change impact analysis.