Govern
About 35% of the CIS-DF exam — see all 5 domains.
The heaviest domain, so study it first.
CMDB Health: three KPIs, six metrics
| KPI | Metrics | What they measure |
|---|---|---|
| Correctness | Orphan, Staleness, Duplicate | Orphan: CIs that meet the class's orphan rule (missing required attributes and/or missing relationships; one orphan rule per class). Staleness: CIs not updated within the staleness rule's Effective Duration (base rule on Configuration Item: 60 days). Duplicate: CIs found by identification rules; only independent CIs are evaluated, and a set counts as total CIs minus one. |
| Completeness | Required, Recommended | Required: CIs missing mandatory fields. Recommended: CIs missing fields marked recommended. Default metric weights inside the KPI are 60% Required and 40% Recommended. |
| Compliance | Audit | CIs that fail CMDB audits. Audits must be activated before Compliance shows results. |
- Overall score: in Zurich the overall CMDB Health score is, by default, a simple average of the three KPI scores. Custom KPI and metric weights (CMDB Health Metric Preferences) only apply when an admin with sn_cmdb_admin turns on Use legacy calculation methods, the pre-Washington DC method.
- Relationship health is separate. Duplicate, orphan and stale relationships, plus relations that break suggested relationship, containment or hosting rules, are non-configurable metrics viewed on the Relationship Health Dashboard. They are not one of the three KPIs.
- Where you configure it: class-level health settings live in CI Class Manager, in the class's Health section (for example Correctness, then the Staleness Rule or Orphan Rule tab).
- It is off by default: the CMDB Health Dashboard jobs are disabled in the base system, so no health data appears until they are enabled.
- The CMDB Health Dashboard shows the overall score and each KPI, with drill-down to failing CIs. It is the place to validate data quality and compliance against your KPIs and critical success factors.
CMDB Data Manager
A policy-driven framework for bulk CI life cycle operations, administered from CMDB Workspace. Policies apply to classes that extend Configuration Item [cmdb_ci]. Six policy types:
| Policy | Use it to |
|---|---|
| Retire | Mark CIs retired while they stay visible in lists and in CMDB Health |
| Archive | Move CIs to an archive table for a retention period; they can be restored during that period |
| Delete | Remove CIs permanently, with no restore |
| Attestation | Create tasks so the people who manage CIs confirm they still exist (useful for manually maintained CIs) |
| Certification | Certify that specific attributes hold specific values |
| Delete CMDB Related Entry | Clean up stale records in related tables that reference a CI (for example serial numbers) |
- Targeting: a policy picks its CIs with a data filter: a table plus filter conditions (and related list conditions), optionally narrowed by an exclusion list. Principal classes are not the Data Manager scoping mechanism.
- Prerequisites: Retire, Archive and Delete policies need an active retirement definition for each targeted class; creating the policy fails without one. Attestation does not need one.
- Approvals and tasks go to the CI's Managed by group; if it is empty, approvals go to the administrator.
- CSDM life cycle order: CIs that are no longer needed are retired first, then archived or deleted according to business needs.
- Scenario tip: match the goal to the policy. "Remove but must be restorable" is Archive. "Gone for good" is Delete. "Confirm the CI is still real" is Attestation. "Confirm an attribute value" is Certification.
Principal classes
- A designation set per class in CI Class Manager (Class Info, Basic Info, Principal Class) by sn_cmdb_admin or itil_admin. It is not inherited by child classes, and the base system has no principal classes.
- Principal classes are the classes prioritized for tracking, health, certification and life cycle work. The Principal Class filter limits CI lists and dashboards to them, and a task property (com.snc.task.principal_class_filter) limits CI lookups on incident, problem and change records to principal classes.
Duplicates and de-duplication
- How duplicates appear: the same real item arrives from several sources with weak or inconsistent identifier data (for example one source sends only a serial number and another only name and IP), legacy imports that bypassed the IRE, or poorly designed identification rules.
- What the IRE does: when identification matches more than one CI, the IRE groups the set into a de-duplication task. With the default glide.identification_engine.skip_duplicates = true and fewer duplicates than the threshold (default 5), it updates the oldest CI (the main CI) and sets duplicate_of on the others. With skip_duplicates = false, matching fails with an error and no CI is updated.
- Remediating one task: the Duplicate CI Remediator wizard. Pick the main CI, then either Remediate Manually (choose values attribute by attribute) or Use Main CI (keep main CI values, merge relationships and default related items). The recommended action for the other CIs is to set attributes to custom values (for example mark them retired) so they are kept but excluded from future tasks; deleting them is the alternative.
- Remediating many tasks: de-duplication templates run from the CMDB Workspace De-duplication Dashboard. A template can also be applied to a single task.
Life cycle CI attributes
- CSDM standardizes life cycle on two fields: Life Cycle Stage (the broad phase, such as Operational) and Life Cycle Stage Status (the detail within it, such as In Use).
- Life Cycle Mapping rules map legacy values (Install Status, Operational Status, Hardware Status, asset State) per table to the best-fit stage and status pair; when several rules match, the highest priority rule (lowest number) wins. Legacy fields are not deleted.
Governance roles and operating the CMDB
- Configuration Manager / CMDB process owner: owns the CMDB process, policies and overall health.
- CI class owner: accountable for the data quality and standards of specific classes.
- Data steward: works the data day to day (remediation tasks, attestations, fixes) under the agreed standards.
- Platform owner / architect: owns the data model design and standards.
- Operationalizing the CMDB means continuous governance rather than a one-time load: health jobs running, dashboards reviewed, de-duplication and attestation tasks worked, audits active, and Data Manager policies on a schedule.
- CMDB Workspace is the role-based home for this work: CMDB Health, Data Manager administration and tasks, de-duplication, CMDB 360 and saved queries, Intelligent Search and the Data Foundations dashboards.
Sample questions from this domain
Three of the 114 in this domain, with the reasoning. The full set is in the question bank.
The overall CMDB Health score aggregates three high-level KPIs (often called the '3 C's'). Which set correctly names them?
- A. Correctness, Completeness, and Compliance ✓
- B. Discovery, Mapping, and Reconciliation
- C. Create, Read, and Update
- D. Foundation, Design, and Sell
Why: CMDB Health aggregates three KPIs, Correctness, Completeness, and Compliance (the '3 C's'), which are built from six sub-metrics (Orphan, Staleness, Duplicate / Required, Recommended / Audit). Foundation/Design/Sell are CSDM domain names, not health KPIs.
A data steward wants Server CIs that have no relationship to any application to be counted by the Orphan metric. How is this set up in CMDB Health?
- A. Add the application relationship as a criterion attribute in the Server identification rule
- B. Configure the orphan rule for the Server class in its CI Class Manager health settings ✓
- C. Lower the Server staleness Effective Duration so unrelated servers age out sooner
- D. Create a CMDB audit that fails such servers so they are counted under Orphan
Why: Orphan rules are defined per class (only one orphan rule per class), and CI Class Manager is the central place for class health settings, so the steward defines the Server orphan rule to require the application relationship. Staleness only measures how recently a CI was updated. Identification rule criterion attributes match incoming payloads to existing CIs and drive duplicate detection, not orphan logic. A CMDB audit feeds the Audit metric under Compliance, not the Orphan metric under Correctness.
An organization wants to automatically retire and eventually archive Configuration Items that have not been discovered or updated in 90 days. Which tool is designed to manage this CI lifecycle through policy?
- A. Data Manager ✓
- B. Virtual Agent
- C. Form Designer
- D. CI Class Manager
Why: Data Manager governs the CI lifecycle and enforces policies, for example, retiring or archiving stale CIs based on rules. CI Class Manager configures class structure but does not run lifecycle policies.