CIS-DF Exam Prep: Crack the ServiceNow Data Foundations Certification

In CSDM version 5, enterprise-wide capability tracking is firmly positioned within the Design and Planning domain. This domain is specifically intended to support Enterprise Architecture, Portfolio Management, and Strategic Planning use cases, making it the correct choice for an Enterprise Architect working across the organization.

The Design and Planning (Design) domain focuses on answering “what the business needs and how it should be designed” before services are built or delivered. It includes core concepts such as Business Capabilities, Value Streams, Information Objects, Business Applications, and Architectural relationships. Business capabilities represent what an organization does to achieve its objectives, independent of organizational structure, technology, or implementation. This abstraction is essential for enterprise architects, especially in highly regulated industries like financial services, where strategic alignment and impact analysis are critical.

The other domains do not fit this requirement:

Foundation provides shared reference data (companies, locations, users) but does not model enterprise capabilities.

Build and Integration focuses on application development, CI/CD pipelines, and integration layers.

Service Consumption is concerned with customers, offerings, and how services are consumed.

Service Delivery models the operational and technical delivery of services, including infrastructure and runtime environments.

From a Data Foundations and CSDM governance perspective, tracking enterprise capabilities in the Design and Planning domain ensures:

Clear separation between strategy, design, and operations

Alignment with ITIL 4 strategy and planning practices

Strong support for impact analysis, rationalization, and transformation initiatives

Therefore, Design and Planning (D) is the correct and fully aligned CSDM 5 domain for tracking enterprise capabilities.

In ServiceNow, controlling source precedence when multiple authorized data sources update the same CI attributes is a core responsibility of Identification and Reconciliation Engine (IRE) governance.

The correct and supported method is to assign priority to each data source in reconciliation rules. Reconciliation rules determine which source wins when multiple sources attempt to update the same attribute on a CI. By defining source precedence, the Configuration Manager ensures that the most authoritative system of record (for example, Discovery over manual imports, or HR systems over spreadsheets) consistently controls specific attributes or classes.

Option B is incorrect because manually sequencing data source runs is unreliable, does not scale, and violates Data Foundations best practices. Option C only controls how often data is refreshed, not which source is authoritative. Option D is incorrect because identification rules are used to uniquely identify CIs—not to control attribute-level precedence.

Using reconciliation rules provides deterministic, auditable, and automated control, which is essential for maintaining CMDB trust and avoiding data conflicts.

Therefore, the correct answer is A – Assign a priority to each data source in reconciliation rules.

The Common Service Data Model (CSDM) organizes CMDB data into domains that reflect how services are planned, delivered, and consumed. Correct placement of objects is essential for reporting, ownership, and downstream ITSM, ITOM, and IRM use cases.

Design and Planning domain → Business Process

Business Processes describe how the business operates and what capabilities are required. These are planning constructs used to design services and applications before they are built or delivered.

Foundation domain → Business Application

Business Applications are foundational reference objects that represent what applications exist and who owns them . They anchor ownership, lifecycle, and governance but are not directly operational.

Service Delivery domain → Application Service

Application Services represent running, operational technical services (often created via Service Mapping). They are central to Incident, Change, and Event Management, making them part of Service Delivery.

Sell / Consume domain → Business Service

Business Services represent what is offered to customers or consumers . They define value delivery, SLAs, and consumption context, which is why they belong in the Sell/Consume domain.

This mapping aligns with CSDM v5 guidance and ensures clear separation between planning constructs, foundational records, operational services, and consumer-facing services—a key principle for a scalable and governed CMDB.

The Unified Map in ServiceNow provides a consolidated view of services and their underlying components, integrating Discovery and Service Mapping data. To make this view actionable, Service Owners can apply filters to focus on relevant elements and reduce visual noise.

Filtering by CI type (Option A) is a core capability. It allows the Service Owner to show or hide categories such as servers, databases, load balancers, or applications—making it easier to analyze specific layers of the service.

Filtering by Business Criticality (Option D) is also available and highly valuable. This enables Service Owners to prioritize views around high-impact components, ensuring attention is focused on CIs that pose the greatest risk to service delivery.

Option B (Discovery source) is not typically exposed as a Unified Map filter because the map focuses on operational and service context, not ingestion provenance. Option C (Managed by group) is a governance attribute and is not a standard visual filter within the Unified Map.

Thus, the correct filter options are A – CI type and D – Business criticality.

In ServiceNow, CMDB 360 / Multisource CMDB extends the Identification and Reconciliation Engine (IRE) to support multi-source visibility, reconciliation, and confidence scoring. Configuration is controlled through system properties, each enabling a specific capability.

glide.identification_engine.multisource_enabled is the master switch that activates CMDB 360 functionality.

glide.identification_engine.multisource_cmdb_ci_enabled allows CMDB 360 to collect and evaluate data specifically from CMDB CI classes.

glide.cmdb.logger.source.cmdb_multisource enables detailed logging for troubleshooting multisource ingestion and reconciliation.

glide.identification_engine.multisource_recompute.max_ci_limit protects performance by limiting how many CIs can be processed during a recompute operation.

Capturing CMDB 360 data from non-CMDB classes is not supported, which is why no property applies to that option.

This mapping aligns with Data Foundations and CMDB governance best practices, ensuring CMDB 360 is enabled safely, transparently, and at scale.

In Data Foundations, “govern” is not only about defining standards—it also includes implementing repeatable controls that keep CMDB data clean over time. CMDB Data Manager is the ServiceNow capability built specifically for policy-driven CI lifecycle operations such as deletion, archival, and attestation. Rather than relying on one-off scripts or manual cleanup, Data Manager applies consistent lifecycle rules at scale, which is a core expectation of CMDB Data Foundations governance.

The place to administer these lifecycle policies is within CMDB Workspace, under the Management area, where the Data Manager tools expose a dedicated Policies experience. From there, a Data Manager can create new policies, publish them, and manage existing policies used to automate lifecycle processing. This aligns with the intent of “keeping the CMDB healthy and efficient” because it operationalizes governance through automated, standardized actions and controlled approvals where needed.

By contrast, CI Class Manager is primarily for managing CI class definitions and class-level settings (for example, class configuration related to identification, reconciliation, and health rules), not for publishing CI lifecycle automation policies. “CMDB 360” is oriented toward exploring CI/service context, and “Service Operations Workspace” is designed for operational workflows rather than CMDB lifecycle policy administration.

In CMDB governance, different CMDB Data Manager policy types serve different validation and enforcement purposes. When the objective is to allow an assigned individual to review and update specific fields on a CI record, the correct policy type is Certification.

A Certification policy creates actionable tasks that require the assignee to validate and, if necessary, correct specific CI attributes, such as lifecycle status, support group, environment, or ownership. During certification, the user can directly update CI fields to bring the record into compliance with defined standards.

Attestation (Option C) only asks the user to confirm that a CI still exists or is still valid; it does not require or enable attribute-level updates. Audit (Option A) is used for reporting and evidence collection, not remediation. Compliance (Option D) measures adherence to rules but does not itself generate editable remediation tasks.

Certification is therefore the primary mechanism used when human validation and correction of CI data is required—making it a cornerstone of CMDB data quality management.

Hence, the correct answer is B – Certification.

The Unified Map is designed to provide enhanced visual insight and analysis across the CMDB by consolidating configuration item (CI) relationships from multiple sources—such as Discovery, Service Mapping, and manual relationships—into a single, interactive view. While traditional Service Mapping maps are optimized for modeling and understanding application-to-infrastructure dependencies, the Unified Map extends this capability with more flexible visualization and exploration features.

Option B is correct because the Unified Map allows users to zoom in and out, enabling both high-level overviews and detailed inspections of complex CI relationships. This capability is particularly valuable in large enterprise environments where services may span hundreds or thousands of infrastructure components. Zoom functionality supports impact analysis, troubleshooting, and architectural reviews without overwhelming the user with unnecessary detail.

Option C is also correct because the Unified Map supports filtering of map nodes based on user preferences. Administrators and analysts can filter by CI class, relationship type, lifecycle state, or other attributes, allowing them to focus on what is most relevant to their task—such as identifying only production CIs, security-relevant components, or a specific technology stack. This aligns strongly with Data Foundations principles by improving usability and decision-making without altering underlying data.

Option A is incorrect because modifying the number of levels displayed is a characteristic more closely associated with Service Mapping configuration rather than an added Unified Map capability. Option D is incorrect because visibility into an application and its host is a core Service Mapping function, not an enhancement unique to the Unified Map.

In summary, the Unified Map adds value by improving interactivity, flexibility, and user-driven insight across the CMDB.

This scenario hinges on how the Identification and Reconciliation Engine (IRE) in ServiceNow evaluates identification rules.

The identification rule for the Apache Web Server class includes Version as part of the identifier criteria, along with Class and Configuration file. Identification rules must match all criterion attributes exactly for an incoming record to be identified as an existing CI and reconciled.

Yesterday’s discovery created an Apache Web Server CI with a specific version value. When Apache is upgraded and discovery is rerun, the Version attribute changes. Because Version is part of the identifier, the incoming record no longer matches the existing CI’s identifier entry. As a result, the IRE cannot identify the existing CI as the same configuration item.

When identification fails and no matching identifier entry is found, the IRE proceeds to insert a new CI record rather than updating the existing one. This behavior is intentional and protects the CMDB from incorrectly reconciling records that no longer meet identification criteria.

Option A is incorrect because reconciliation only occurs after successful identification.

Option C is incorrect because reclassification is unrelated to identification criteria.

Option D is incorrect because this is not an error condition; it is expected IRE behavior.

This example highlights a best practice caution: volatile attributes (such as Version) should generally not be used as identifier attributes, as they can cause unintended CI duplication during upgrades.

Within the Common Service Data Model (CSDM), information objects are used to represent non-CI data entities that provide important business or governance context but are not configuration items themselves. These objects are especially important when extending service visibility beyond pure infrastructure and application relationships.

The use case described in Option A—understanding asset lifecycle compliance in a Business Application context—explicitly requires information objects. Asset lifecycle data (such as financial state, depreciation, warranty, and compliance milestones) is typically managed in IT Asset Management (ITAM) and must be associated to Business Applications without converting every asset-related data point into a CI. Information objects enable this linkage while maintaining clean CMDB boundaries.

Option B focuses on event-to-incident automation, which relies on CIs, technical services, and operational relationships, not information objects. Option C (proactive case management) is primarily a CSM and service offering use case. Option D (SecOps risk context) relies on application services and business application relationships, not information objects. Option E (business service impact) is addressed through service modeling and service mapping, again without requiring information objects.

Information objects are introduced as organizations mature and need to integrate governance, financial, or compliance data with service and application models—making asset lifecycle compliance the correct match.

Therefore, the correct answer is A.