PowerExams Prepare. Practice. Pass.

ServiceNow CIS-DF (Data Foundations: CMDB & CSDM) — Study Guide

Certified Implementation Specialist – Data Foundations. Structured by the five official exam domains (blueprint updated November 2025). Original content mapped to the public exam blueprint — not affiliated with or endorsed by ServiceNow.

The exam is 75 questions in 90 minutes and includes multiple choice, multiple select, drag/drop matching, and scenario-based items. Weight your study toward Govern (35%) — more than a third of the exam — then Insight (20%) and Ingest (19%).

Big picture: CIS-DF is about building a trusted CMDB. Everything ties back to data being Complete, Compliant, and Correct (the 3 C's of CMDB Health), structured according to CSDM, ingested cleanly through the IRE, and kept healthy over time through Data Manager and governance.

Domain 3 — Govern (35%) — heaviest, study first

Governance is the largest domain, so lead with it.

CMDB Health aggregates three KPIs — Correctness, Completeness, and Compliance (the "3 C's") — built from six sub-metrics, plus a separate Relationships group:

KPI Sub-metrics What they measure
Correctness Orphan, Staleness, Duplicate Orphan CIs (fail an orphan rule — e.g., missing required attributes and/or missing relationships); stale CIs (not updated within the staleness rule's effective duration, base default 60 days on cmdb_ci); duplicate CIs (detected via identification rules)
Completeness Required, Recommended CIs missing mandatory (dictionary-mandatory) fields; CIs missing fields flagged as recommended
Compliance Audit CIs that fail their CMDB audits

A separate Relationship Health dimension scores orphan/stale/duplicate relationships and relations not compliant with suggested/containment/hosting rules. Per the docs, the overall CMDB Health score aggregates only the three KPIs (Correctness, Completeness, Compliance) by their scorecard weights — Relationship Health is reported separately and does NOT roll into the overall score. All of this surfaces on the CMDB Health Dashboard and the CMDB / CSDM Data Foundations Dashboards, supporting KPIs and Critical Success Factors (CSFs).

Precision note: they are three KPIs composed of six sub-metrics — not "six metrics across three dashboards." Dashboards (Health, service, group, CI, Data Foundations) are a separate UI layer.

CMDB Data Manager is a policy-driven framework for bulk CI life-cycle operations — specifically deletion, archival, and attestation — at scale, rather than ad hoc record-by-record cleanup. Key ideas:

  • Policies define a lifecycle action and the conditions under which it runs (e.g., archive CIs not updated in N days). On a scenario question, match the goal (e.g., "remove CIs not seen in 90 days") to the correct Data Manager policy.
  • Principal classes — a real CMDB concept (there is a Principal Class filter) for the meaningful top-level classes an organization actively manages. Policies and reporting are scoped to principal classes so governance focuses on what matters instead of every class.

Deduplication: duplicates arise when the same real-world item is created by multiple sources or with insufficient identification data, so the IRE cannot match them. The IRE/Health create a De-duplication task for each set of duplicates; De-duplication templates group those tasks for bulk remediation. To remediate a single de-duplication task, ServiceNow provides the out-of-the-box Duplicate CI Remediator wizard (pick the surviving CI, merge/remove the rest, re-point relationships); the De-duplication templates and the CMDB Workspace De-duplication Dashboard handle bulk/consistent remediation. (The OOB wizard exists — its name is "Duplicate CI Remediator," not "Deduplication Wizard.")

Key governance roles (know who does what):

  • CMDB / Configuration Manager — owns the overall process and health.
  • CI Class Owner / Data Steward / CMDB Librarian — owns data quality for specific classes.
  • Platform Owner / Architect — design and standards.

Operationalizing the CMDB means moving from a one-time build to ongoing, repeatable governance: dashboards monitored, KPIs tracked, remediation tasks worked, audits run regularly.

CMDB Workspace is the modern, role-based interface for working with CMDB data — viewing CI details, relationships, health, and remediation in one place, rather than navigating raw lists.

Domain 4 — Insight (20%)

Insight is about getting value and answers out of the CMDB.

  • Business value of the CMDB: it's the single source of truth that powers ITSM, Service Mapping, Event Management, Security Operations, Software Asset Management, and more. Better CMDB data → better impact analysis, change risk, and service visibility.
  • Natural Language Query (NLQ) lets users ask plain-language questions of CMDB data instead of building filters.
  • CMDB 360 / Saved Queries: CMDB 360 (multisource) shows attribute values from multiple sources side by side. CMDB Saved Queries let you build and reuse complex relationship queries, and build custom reports from that data.
  • Dependency views / Unified Map: visualize a CI and its upstream/downstream relationships to understand impact. Use these for impact analysis and troubleshooting.
  • CMDB Foundation Dashboards & Playbook: the dashboards summarize health and data quality; the Playbook provides structured, prescriptive guidance — typically a summary of the indicator → overview of the problem → why it matters → how to fix/improve — to drive remediation.

Domain 2 — Ingest (19%)

Ingest is about getting data in cleanly without creating technical debt.

Choosing an ingestion method (a common scenario): match the source to the right mechanism.

  • Discovery — agentless, schedule-based discovery of infrastructure via MID Server.
  • Service Graph Connectors (SGC) — the preferred, IRE-aligned way to integrate third-party data sources (e.g., other CMDBs, cloud, SCCM). They use the IRE, support multisource, and minimize technical debt and upgrade risk.
  • Agent Client Collector (ACC) — lightweight agent-based data collection.
  • Manual / Import Sets — for non-discoverable CIs and attributes (e.g., business applications, contracts) that no tool can discover. Maintain these deliberately.

Minimize technical debt / ensure upgradeability: prefer out-of-the-box, IRE-driven integrations (Service Graph Connectors) over custom import scripts that bypass identification; don't write directly to CMDB tables. Certified, maintained connectors reduce custom upgrade/maintenance debt (no hand-written coalesce). (Note: connectors still require normal upgrade maintenance — this is not a guarantee that a data source is never skipped on a given upgrade path.)

Relationships can be populated automatically (by Discovery, Service Mapping, or connectors) or manually (by an admin defining a relationship between two CIs). Suggested/automated relationship features reduce manual effort.

Asset vs. CI alignment: an Asset (alm_asset / financial & contractual record) and a CI (cmdb_ci / operational record) are two tables kept in sync by the out-of-the-box "Update Asset fields on change" business rule (AssetAndCISynchronizer), which fires when a synchronized attribute changes. Key mapping: the asset's State/Substate ↔ the CI's Install Status (install_status), and for hardware the Hardware Status/Substatus (hardware_status) — Install Status and Hardware Status are independent of each other. Knowing which fields sync (and that asset and CI are distinct records, not one record) is testable.

Compliance identifiers: security and regulatory identifiers can be tracked against CSDM objects so the CMDB supports audit and compliance reporting.

Domain 1 — Configuration (15%)

Configuration covers the technical building blocks of the CMDB.

CI Class Manager is the single place to manage the CMDB class hierarchy:

  • View and edit the class hierarchy (parent/child classes extending cmdb_ci).
  • Manage table, attributes, relationships, identification rules, reconciliation rules, and dependent relationships for each class in one UI.
  • Use it to extend the model correctly rather than creating ad-hoc tables.

Identification and Reconciliation Engine (IRE) is the gatekeeper for all data entering the CMDB:

  • Identification rules determine whether an incoming payload matches an existing CI (using identifier entries / criterion attributes, evaluated by priority) — preventing duplicates.
  • Reconciliation rules decide which data source is authoritative for a given attribute, so a lower-priority source can't overwrite a higher-priority source's value (data source precedence).
  • All standard ingestion (Discovery, Service Graph Connectors, etc.) should go through the IRE rather than writing directly to CMDB tables.

CMDB 360 / Multisource CMDB stores attribute values per data source and shows them side by side, with reconciliation deciding the displayed/authoritative value. Configure it when multiple sources report on the same CIs and you need to see and reconcile discrepancies.

Domain 5 — CSDM Fundamentals (11%)

CSDM (Common Service Data Model) is ServiceNow's prescriptive, standard framework for structuring service and CI data so it's consistent and product-ready.

  • Why CSDM: it provides a common language/structure across products (ITSM, ITOM, CSM, SecOps, APM, SPM), enabling service-aware reporting, impact analysis, and a trustworthy CMDB. Following CSDM is what makes data reusable across the platform.

  • CSDM domains (CSDM 5, 2025) — seven total, but they are not all the same kind of thing:

    • Foundation — a supporting layer (not a lifecycle stage): referential base data (companies, business units, departments, locations, groups, users, product models, contracts). Most Foundation "common data" (Company, Department, User, etc.) are not CIs.
    • The five sequential lifecycle / data-flow domains: Ideation & Strategy (new in CSDM 5) → Design & Planning (the tables formerly used by APM, now Enterprise Architecture) → Build & Integration → Service Delivery (formerly "Manage Technical Services") → Service Consumption (formerly "Sell/Consume").
    • Manage Portfolios — a cross-cutting domain that spans portions of all five lifecycle domains, not a sequential stage.

    Exam-timing flag: older CSDM 4 used four domains (Foundation, Design, Manage Technical Services, Sell/Consume). If the live exam still references the older names, recognize both — but teach the current CSDM 5 labels.

  • Key CSDM 5 specifics worth knowing: Service Delivery relabels cmdb_ci_service_auto to "Service Instance" and adds new Service Instance sibling classes (Connection, Data, Facility, Network, Operational Process) — these are real classes that extend cmdb_ci_service_auto (introduced in the CMDB CI Class Models update), populated/maintained manually rather than auto-discovered (it is a relabel + new sibling extension classes, not a brand-new base class). CSDM 5 also adds SBOM (Software Bill of Materials, sn_sbom_core, spanning Design & Planning and Build & Integration), Ideation & Strategy (SPM), AI/OT classes, and renames Technical Service → Technology Management Service. (Note: ITBM is now SPM; APM is now EA.)

  • Approach to abiding by CSDM: start with Foundation data, then progress through the official adoption stages Crawl → Walk → Run → Fly, building service models incrementally rather than boiling the ocean. (Foundation is treated as its own first implementation stage.)

  • Mapping across stakeholders/industries (scenario): correctly place CIs and services into the right CSDM domain by working with the stakeholders who own those services, regardless of industry-specific terminology.

Fast-recall cheat list

  • Heaviest domain: Govern (35%) — lead your study here.
  • CMDB Health = 3 KPIs (the 3 C's): Correctness, Completeness, Compliance — built from 6 sub-metrics (Orphan, Staleness, Duplicate / Required, Recommended / Audit). Relationship Health is a separate dimension, reported on its own — it does NOT roll into the 3-KPI overall score.
  • Correctness sub-metrics: Duplicate, Staleness (default 60 days), Orphan (orphan = fails the orphan rule, not strictly "zero relationships").
  • Data Manager = policy-driven bulk CI lifecycle ops (deletion, archival, attestation); scope via principal classes.
  • Duplicates: IRE/Health create de-duplication tasks; de-duplication templates do bulk remediation (no OOB "wizard").
  • IRE = identification (prevent duplicates) + reconciliation (authoritative source precedence). Everything enters the CMDB through it.
  • CI Class Manager = one UI for class table, attributes, hierarchy, and identification/reconciliation rules.
  • Service Graph Connectors are the preferred, certified/maintained, IRE-aligned integration method (reduce custom upgrade debt); manual/import for non-discoverable CIs.
  • Asset (alm_asset) and CI (cmdb_ci) are separate records kept in sync (State ↔ Install Status) by a business rule.
  • CMDB 360 / multisource stores attribute values per source; reconciliation decides the authoritative value.
  • CSDM 5 (7 domains): Foundation (supporting layer) + 5 sequential lifecycle domains (Ideation & Strategy → Design & Planning → Build & Integration → Service Delivery → Service Consumption) + Manage Portfolios (cross-cutting). Adopt Foundation → Crawl → Walk → Run → Fly.