CIS-DF Questions and Answers

CMDB Data Manager provides policy-driven lifecycle governance for configuration items. The organization should configure Life Cycle Stage automation in Data Manager so that a qualifying lifecycle change on a parent CI is propagated consistently to the relevant child CIs.

This approach creates a controlled and auditable lifecycle process. It avoids relying on custom scripts or disconnected import logic and ensures that lifecycle transitions are applied according to defined conditions and CI relationships.

A Transform Map is intended to transform and import source data. It is not the appropriate mechanism for continuously cascading lifecycle changes between related CIs. Creating a new CI class would also be incorrect because lifecycle management is a behaviour applied to existing CI classes rather than a separate CI type.

CMDB Data Manager is specifically designed to automate CI lifecycle activities such as retirement, archival, deletion, certification, and attestation. Therefore, Data Manager lifecycle automation is the governed solution.

Dynamic reconciliation rules are tied to CMDB 360 / Multisource CMDB because they depend on visibility into multiple contributing data sources for the same CI. Standard reconciliation rules control which data source is allowed to update specific CI attributes based on source precedence, but dynamic reconciliation adds more advanced logic, such as choosing a value based on source reporting behavior or data comparison rules. CMDB Workspace and CMDB Data Manager do not enable dynamic reconciliation; they are management and governance interfaces. Reconciliation Rules alone are not the enabling feature because basic IRE reconciliation can exist without the CMDB 360 dynamic reconciliation capability. Therefore, to use dynamic reconciliation rules, CMDB 360 / Multisource CMDB must be enabled.

=========

Data Foundations strongly encourages using out-of-box synchronization mechanisms rather than custom scripting whenever possible, to reduce technical debt and improve upgrade safety. In this scenario, endpoint data is being ingested into the CI record, and the Asset team needs the corresponding Asset record kept in sync automatically for their asset management processes.

The recommended approach is to use Asset CI Field Mapping, which is designed specifically to map and synchronize fields between an Asset and its related CI. Creating or updating a mapping rule for “Assigned to” allows the platform to replicate the value in a controlled, supportable way without writing scripts. This approach aligns with best practices: standard configuration, clear governance, and minimal custom code.

Option B (a scripted business rule) can work technically, but it introduces maintenance risk, testing overhead, and potential upgrade fragility—exactly the kind of technical debt Data Foundations warns against when an OOTB capability exists. Option A (dot-walking) changes the user experience and does not truly populate the Asset field; it only displays a derived value and may not meet Asset team needs for reporting, exports, integrations, or lifecycle workflows that expect the Asset field to be set. Therefore, the best automated and best-practice solution is Asset CI Field Mapping.

In ServiceNow, each CMDB Health metric can independently define which CIs are in scope for evaluation. This scoping is controlled primarily through Health Inclusion Rules, not CMDB Groups.

In this scenario, the Duplicate metric evaluates all 60,000 Server CIs, indicating no inclusion rule is restricting its scope. In contrast, the Orphan metric evaluates only 50,000 Server CIs, which means 10,000 servers are intentionally excluded from that metric’s evaluation.

This difference is explained by a Health Inclusion rule configured specifically for the Orphan metric on the Server class. Health Inclusion rules allow administrators to define conditions—such as lifecycle state, environment, discovery source, or operational status—that determine whether a CI should be included in a specific health calculation. For example, retired servers or servers in build states may be excluded from orphan checks.

CMDB Groups are not used by the CMDB Health Engine to determine metric scope; they are used for reporting, assignment, and operational grouping. Therefore, Options A and D are incorrect. Option C is also incorrect because the Duplicate metric clearly evaluates the full population of 60,000 servers.

Thus, the scope difference is correctly explained by the Orphan metric having a Health Inclusion rule configured, making Option B the verified answer.

In Data Foundations, a low “Unique Locations” result indicates the CMDB contains duplicate Location records (or inconsistent location usage) that reduce data reliability for operational reporting and service analytics. This sits under “Insight” because the dashboard is highlighting a measurable quality issue, and the playbook provides a structured remediation path to restore confidence.

The recommended playbook-aligned process is to review the duplicate locations, determine which one is correct per the organization’s naming and data standards, then re-point dependent records (CIs) to the correct Location before removing the duplicate. That sequence is essential: if you delete a duplicate location without first updating related CIs, you risk leaving CIs with missing/invalid location references, creating new completeness and correctness issues.

Option C matches best practice: validate which location record should remain, update all affected CIs (and any other dependent records) to use the correct location, and then delete (or retire/merge, depending on process controls) the duplicate record. Option B is risky because it skips validation and dependency updates. Option D defeats the purpose of “Unique Locations” by allowing ongoing inconsistency. Option A is not the best fit because “Duplicate CI Remediator” is oriented toward CI duplicates; Location is typically a reference/organization data domain and is handled through the specific remediation steps for that data set. Therefore, C is the recommended process.

In ServiceNow, Service Graph Connectors deliver data ingestion patterns using protected, upgrade-safe artifacts, including script transforms. When a customer customizes a script transform provided by a Service Graph Connector, ServiceNow follows standard update set and upgrade behavior to protect customer customizations.

During a subsequent upgrade, if the out-of-box (default) script transform definition changes, ServiceNow does not overwrite the customized version. Instead, the platform records a skipped change, indicating that an update was available but intentionally not applied due to a local customization. This ensures customer-specific logic is preserved while still maintaining transparency about what changed in the newer release.

Option A is incorrect because upgrades do not halt due to customized transforms. Option C is also incorrect because Service Graph Connector upgrades proceed normally; they do not refuse to start because of customizations.

This behavior aligns with Data Foundations best practices: avoid modifying OOTB content when possible, but when customization is necessary, ensure it is protected during upgrades. Administrators should review skipped changes after upgrades to decide whether to manually adopt new OOTB logic.

Therefore, the correct answer is B – A skipped change is created and no change is made to the script transform definition.

CMDB Data Foundations Dashboard playbooks explain why a deficient metric matters and provide recommended actions for improving it. This includes insight into downstream consequences such as duplicate creation, inaccurate assignment, unreliable impact analysis, weak service context, incorrect reporting, or ineffective Incident, Change, and Security Operations processes.

The playbooks also provide remediation options. These guide administrators through analysing affected records, identifying responsible data sources, correcting existing data, and introducing governance controls to prevent the condition from returning. The guide describes remediation playbooks as structured guidance for analysing issues and implementing targeted corrective actions.

They are not automatically executed scripts. Human analysis, source correction, ownership decisions, and governance changes are generally required. They are also more than generic remediation templates because their value includes contextual impact information and metric-specific recommendations.

Therefore, the two stated benefits are downstream-impact insight and remediation options, making B and D correct.

=========

In the Common Service Data Model (CSDM), the Incident form is designed to capture operational impact and enable effective incident routing, prioritization, and communication. To achieve this, CSDM prescribes using classes that represent how services are delivered and consumed, not how they are planned or governed.

Application Service (Option A) is an appropriate class on the Incident form because it represents the technical service that is running in production and is directly impacted during an incident. Application Services are service-mapped, relate to underlying infrastructure, and support impact analysis, root cause investigation, and automated assignment. This makes them ideal for associating incidents with technical outages or degradations.

Service Offering (Option C) is also appropriate because it represents how a service is consumed by users or business units. Service Offerings allow Incident Management to understand who is affected, enable targeted communications, and support SLA/OLA alignment. For example, an email service offering for a specific department clearly identifies the impacted consumer group.

Business Application (Option B) is not recommended on the Incident form. Business Applications are logical representations used for portfolio, ownership, and governance purposes, not day-to-day operational incident handling. Using them directly on incidents can reduce precision and automation.

Service Portfolio (Option D) is a strategic construct used for service lifecycle management and is never associated with operational incidents.

Therefore, according to CSDM best practices, the correct classes used on the Incident form are Application Service and Service Offering, making Options A and C the correct answers.

Information Objects in CSDM are used to represent logical data associated with Business Applications. They are especially important for governance, compliance, privacy, and audit use cases because they describe the type of data a Business Application processes, stores, or transmits. For example, if an application handles personal data, payment card data, or regulated healthcare information, that logical data context should be modeled as an Information Object and related to the Business Application. Option A is too broad and incorrectly frames the object as general data for a group of CIs. CIs represent technical components, while Information Objects describe logical business data. Option B is too narrow because API exchange data is only one possible technical integration scenario and does not define the purpose of the CSDM artifact. Therefore, the correct purpose is to describe logical data related to Business Applications.

The correct answer is Use the CMDBTransformUtil API in the transform script . Import Sets and Transform Maps can create duplicate CIs if they write directly into CMDB tables without routing the data through the Identification and Reconciliation Engine. The CMDBTransformUtil API is used in transform scripting to process incoming CI data through the CMDB identification and reconciliation logic. This allows ServiceNow to evaluate existing CIs using configured identification rules and then update the correct CI rather than creating a duplicate record. Coalesce rules are not sufficient for CMDB ingestion because they rely on simple field matching and do not apply the full IRE logic. “Comparison rules” is not the correct mechanism. A system property alone is also not the recommended implementation pattern for vendor shipment import data. Therefore, CMDBTransformUtil is the correct method to prevent duplicate CI creation through import sets.

Enabling Multisource CMDB makes the CMDB 360 experience available in CMDB Workspace. CMDB 360 provides visibility into the different discovery and integration sources contributing information to a CI. Administrators can compare source-level attribute values, identify data gaps and conflicts, and investigate how reconciliation determines the final value stored on the CI.

The Home tab provides general workspace navigation and summary information. The Management tab contains administrative capabilities such as CMDB Data Manager policies. The Insights tab provides adoption, health, and analytical information, but it is not the primary Multisource CMDB work area.

The study guide specifically states that CMDB 360 saved queries are viewed and created through the Saved Queries area on the CMDB 360 tab. It also explains that Multisource CMDB retains source contributions and supports analysis of differing or missing values across sources. Therefore, enabling the feature populates the CMDB 360 tab.

=========

When transitioning to CSDM-aligned lifecycle management, ServiceNow introduces a structured lifecycle framework that separates high-level intent from detailed operational state.

Life Cycle Stage represents the macro phase of a CI’s existence (for example: Plan, Build, Deploy, Operate, Retire ).

Life Cycle Stage Status refines that phase with granular, sub-level states that vary by CI type.

Life Cycle Object determines which lifecycle stages and statuses apply, based on what kind of CI is being managed (hardware, application, document, etc.).

Life Cycle Mapping ensures a safe transition from legacy status fields by translating existing values into standardized CSDM lifecycle values—avoiding data loss or process disruption.

Together, these objects enable consistent lifecycle governance, improve reporting accuracy, and support automation across ITSM, ITOM, and IRM use cases—while remaining backward compatible with legacy CMDB data.

In Data Foundations, “Insight” is about using health metrics to understand whether the CMDB is trustworthy and operationally usable. The CMDB Health Dashboard organizes health into scorecards that group related checks. When leadership asks for Duplicate CIs, Orphan CIs, and Stale CIs, they are asking about the CMDB’s ongoing hygiene and adherence to governance expectations—not simply whether fields are filled in.

These three metrics align best with Compliance because they represent whether CI records comply with rules that keep the CMDB clean and current over time:

Duplicate CIs indicate the identification and governance controls are not consistently preventing multiple records for the same real-world item.

Orphan CIs indicate relationship governance gaps—records exist without expected relationships or context, reducing their operational value and often signaling incomplete ingestion or lifecycle control issues.

Stale CIs indicate lifecycle management gaps—records are not being updated, attested, retired, or archived appropriately, which increases risk and noise in operational processes.

By contrast, Completeness focuses on whether required attributes are populated (owners, support group, environment, etc.). Correctness focuses on whether values and relationships are accurate and logically valid. While duplicates/orphans/stale can affect correctness indirectly, the dashboard’s grouping for these hygiene and lifecycle-oriented measures is best represented by Compliance, which is why B is the correct answer.

Life cycle mappings are used to review how legacy CMDB status values correspond to the newer CSDM life cycle stage and life cycle stage status model. This is a key governance activity during transition from older status fields to CSDM-aligned lifecycle management. The mapping layer allows administrators to understand and control how legacy operational values translate into standardized lifecycle stages and stage statuses. This prevents inconsistent reporting, incorrect CI retirement behavior, and confusion between old and new status models. A choice list only stores selectable values and does not provide the mapping relationship between legacy status and CSDM lifecycle fields. Life cycle properties may control behavior but do not serve as the review location for legacy-to-CSDM value alignment. Therefore, when reviewing equivalent legacy status and CSDM lifecycle values, the correct location is Life cycle mappings.

Identification rules can be reviewed and configured through CI Class Manager and the CI Identifiers module .

CI Class Manager provides the modern class-centric interface for managing a CMDB class. It consolidates class hierarchy information, attributes, identification rules, reconciliation settings, principal-class configuration, and recommended relationships. This allows an administrator to understand an identification rule in the context of the class to which it applies.

The CI Identifiers module provides direct access to identification-rule definitions used by the Identification and Reconciliation Engine. These rules specify the attribute combinations that determine whether incoming data represents an existing CI or requires creation of a new CI.

API Integrations does not define IRE identification criteria. “IRE Application” is not the applicable class-level configuration location presented by the platform for this task.

=========

In Data Foundations (CMDB and CSDM), relationship modeling must reflect real operational dependency so that incident triage, change impact analysis, and service visibility remain accurate. When an Application is hosted on a Server, the standard hosting-style relationship used in CMDB relationship governance is expressed as “Runs on::Runs”. This pairing represents the two directional descriptors of the same relationship type: from the application perspective it runs on the server, and from the server perspective it runs the application.

This matters because CMDB relationships are used by downstream capabilities (for example, dependency views, impact calculations, and governance rules). Using the correct out-of-box relationship descriptor pair ensures consistent reporting and prevents confusion when teams traverse relationships “upstream” and “downstream.” In addition, relationship governance rules and inheritance are commonly built around standard relationship types; using the correct “Runs on::Runs” semantics supports validation across subclasses (for example, specific application and server subclasses) without requiring custom relationship definitions.

The other options are either reversed (“Runs::Runs On”), represent different semantics (“Uses::Used by”), or do not align with the typical hosting relationship naming used for application-to-server hosting dependencies. Therefore, the correct relationship expression between an Application and a Server is Application > Runs on::Runs > Server.

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.

Agent Client Collector (ACC) → Collects inventory and telemetry from devices using an installed agent, especially where agentless discovery is not practical.

ServiceNow Discovery → Automatically identifies devices and applications on the network and populates the CMDB with accurate, up-to-date information.

Service Graph Connectors → Facilitates integration between ServiceNow and external systems to import and synchronize CMDB data.

Service Mapping → Builds the complete topology of services and shows how they are supported by underlying infrastructure and applications.

Each ingestion product has a specific role in CMDB Data Foundations. ServiceNow Discovery is primarily agentless and discovers infrastructure, applications, and relationships across the network. Agent Client Collector is agent-based and is useful for devices that are intermittently connected, remote, restricted, or difficult to scan through traditional Discovery. Service Graph Connectors are prebuilt, governed integrations used to bring third-party data into the CMDB while aligning with IRE and ServiceNow class models. Service Mapping focuses on service topology by identifying how application services depend on infrastructure and application components. The key distinction is that Discovery and ACC collect technical inventory, Service Graph Connectors integrate external sources, and Service Mapping builds service dependency models.

=========

Identification Inclusion Rules restrict the population of existing CIs that the Identification and Reconciliation Engine considers when attempting to identify an incoming CI. They add qualifying conditions to the identification process so that IRE searches only the relevant subset of records instead of evaluating every CI in the class.

For example, an inclusion rule could constrain matching to CIs belonging to a particular company, environment, domain, or other defined population. After narrowing the candidate records, IRE applies the class’s identifier entries and identification criteria to decide whether an existing CI matches the incoming data. Identification rules determine whether an incoming record matches an existing CI or requires creation of a new record.

Option A describes reconciliation rules, which control source authority over attributes. Option B is incorrect because inclusion rules do not stop the source from submitting data.

The video displays “Health Inclusion Rules,” but that is a terminology error. Health Inclusion Rules control CMDB Health scope; Identification Inclusion Rules are used by IRE.

=========

A CMDB Data Foundations Dashboard playbook provides a Problem Overview and information about likely Root Causes . The Problem Overview explains the deficient metric, why the condition matters, and the operational or governance risks created by poor performance. The Root Cause material helps administrators identify why the condition exists, such as incomplete source data, incorrect transformations, missing ownership, inappropriate class usage, or weak governance controls.

The guide describes these playbooks as structured, prescriptive guidance for identifying root causes, assessing ingestion and governance gaps, and applying appropriate corrective actions.

Playbooks may recommend analysis, correction, reporting, and governance activities, but they do not normally provide fully automated remediation scripts that should be executed without review. “Problem Analysis” is not the named documentation component tested here; analysis is instead performed through the recommended remediation plays.

=========

The correct answer is Business Service Offering and Business Service. In CSDM, the Sell/Consume domain represents how services are presented to and consumed by business users, customers, or consumers. Business Services describe the business-facing services delivered by the organization, while Business Service Offerings represent the specific consumable versions of those services, often differentiated by audience, location, service level, availability, or entitlement. Option A belongs more closely to technical service delivery and management, not Sell/Consume. Option B belongs to Design and Planning, where Business Applications, Business Capabilities, and Information Objects are modeled. Since the question specifically asks for the Sell/Consume domain, the correct tables are Business Service and Business Service Offering.

=========

In the CMDB class hierarchy, Server is a generic parent class, while Linux Server and Windows Server are more specific child classes. When ServiceNow Discovery detects sufficient evidence (such as OS signatures) to move a CI from a generic class to a more specialized one, this action is called a Class Upgrade.

A Class Upgrade occurs when a CI is reclassified down the hierarchy into a more specific subclass, enriching the record with additional attributes, behaviors, and discovery patterns appropriate to that class. This is a standard and expected behavior in mature CMDB implementations and aligns with Data Foundations best practices.

A Class Switch would imply lateral movement between unrelated classes, which is not what happens here. A Class Downgrade would move a CI from a specific class back to a more generic one, typically when discovery confidence is reduced—not the case in this scenario.

By performing class upgrades automatically, Discovery improves CMDB accuracy, reporting precision, and service mapping quality without manual intervention.

Therefore, the correct answer is C – Class Upgrade.

The correct answer is Technology Management Service Offering, also called a Technical Service Offering. In CSDM-aligned configuration, Technical Service Offerings can be related to Dynamic CI Groups so that operational ownership values are synchronized to the member CIs. This includes the Support Group, which is used by ITSM processes for routing incidents, problems, and operational work. A Dynamic CI Group alone defines CI membership, but it does not provide the service-offering ownership context by itself. A Technology Management Service represents the broader technical service, while the offering is the consumable operational layer that carries support and management group information. CI Class Manager is used for class and schema configuration, not for automatically maintaining CI support groups. Therefore, the correct mechanism is the Technology Management Service Offering.

=========

The correct answer is Run. The Run stage of CSDM maturity focuses on operationalizing the service model so that it supports real ITSM and operational processes. Technology Management Services and Technical Service Offerings are used to represent technical services delivered by internal technology teams. When these offerings are connected to Dynamic CI Groups, operational ownership data such as Support Group and Managed By Group can be populated and maintained on associated CIs. This is beyond the basic Crawl and Walk stages, which focus on foundational CMDB data and initial service modeling. It is also not Fly, which represents more advanced optimization and enterprise-level maturity. Because the scenario is about using Technical Service Offerings to drive operational support alignment for CIs, it belongs to the Run stage.

=========

Service Graph Connectors are a key Data Foundations ingestion capability in ServiceNow. They provide out-of-the-box, upgrade-safe integrations that ingest data into the CMDB using the Identification and Reconciliation Engine (IRE), ensuring data quality and source governance.

Two primary categories of Service Graph Connectors are:

Cloud (Option A): These connectors integrate with major cloud providers and platforms (such as AWS, Azure, and GCP) to ingest infrastructure, platform, and service data into the CMDB. They are essential for managing hybrid and multi-cloud environments and maintaining accurate cloud CI relationships.

Observability (Option B): These connectors integrate with monitoring and observability tools (such as APM, infrastructure monitoring, and telemetry platforms). They provide near-real-time operational data that enriches CI records and supports incident correlation, impact analysis, and service health insights.

Option C (DevOps) is incorrect because DevOps integrations are typically handled through CI/CD tools and workflow integrations rather than Service Graph Connectors. Option D (Workflow Automation) is unrelated; Service Graph Connectors focus on data ingestion, not process orchestration.

Therefore, the correct connector categories are Cloud and Observability, making Options A and B the correct answers.

The CMDB Data Foundations Dashboard is specifically designed to assess whether foundational CMDB configurations and data practices align with ServiceNow recommendations. It exposes gaps involving required attributes, ownership, relationships, identification practices, ingestion controls, and other foundational conditions.

The dashboard provides actionable metrics and connects deficient results to structured Get Well or remediation playbooks. These playbooks guide administrators through understanding the problem, identifying affected records and sources, correcting the data, and implementing controls that prevent recurrence.

CMDB Workspace is the broader operational interface. CMDB Data Manager governs CI lifecycle policies such as certification, attestation, retirement, archival, and deletion. The CMDB Health Dashboard calculates health dimensions such as completeness, correctness, and compliance, but it does not provide the same curated assessment of alignment with recommended Data Foundations practices.

=========

In ServiceNow, ingesting custom CIs must be done with a strong focus on upgrade safety, governance, and long-term maintainability. Data Foundations guidance explicitly discourages repurposing or overloading base classes, as this creates technical debt and upgrade risk.

Option B is a best practice because the CMDB CI Class Models Store delivers ServiceNow-supported CI classes that align with platform evolution. Before creating or extending classes, administrators should verify whether a suitable class already exists or has been introduced in newer releases. This avoids duplication and ensures future compatibility.

Option D is also correct. When no suitable class exists, extending an existing CI class (under the appropriate parent) to add required attributes preserves inheritance, discovery behavior, reporting, and upgrade compatibility. This approach is preferred over creating entirely new, disconnected schemas.

Option A is incorrect because repurposing base classes and renaming attributes breaks standard semantics, causes confusion, and complicates upgrades. Option C is incorrect because extending Asset tables to represent CIs conflates ITAM and CMDB concerns; assets and CIs serve different purposes and lifecycles.

Therefore, the solutions that minimize technical debt and ensure upgrade compliance are B and D.

Health Inclusion Rules determine which CI records are included in CMDB Health calculations. Health Inclusion Rules The Configuration Manager can configure conditions for the relevant CI classes so that only managed, operationally relevant, or management-ready CIs contribute to the Completeness KPI.

For example, an inclusion rule can limit the calculation based on lifecycle stage, operational status, environment, discovery source, or another class attribute that identifies managed CIs. This prevents unmanaged, retired, transitional, or incomplete populations that are not yet under governance from distorting the organization’s health score.

A custom business rule is unnecessary and would introduce avoidable customization and maintenance effort. The score also does not have to include the entire CMDB because each health metric can have a separately controlled evaluation scope. Therefore, configuring Health Inclusion Rules i

The CMDB Integrations Dashboard provides visibility into integrations that populate the CMDB, including Service Graph Connector activity and mapping information. It enables administrators to inspect how source data is mapped to ServiceNow target classes and fields, review connector execution information, and investigate ingestion or mapping problems.

Service Graph Connectors are prebuilt, governed integrations that import third-party data into the CMDB through standardized class mappings and IRE processing. They are intended to minimize custom transformations and preserve source and reconciliation information. The guide describes Service Graph Connectors as upgrade-safe integrations that ingest external data while applying Identification and Reconciliation Engine controls.

Integration Hub is the broader integration and automation framework, not the specific dashboard for reviewing Service Graph Connector field mappings. IntegrationHub ETL is a separate tool for building and managing ETL transformations. It does not serve as the inspection dashboard for mappings belonging to an installed Service Graph Connector.

Therefore, B is correct.

When data quality issues such as missing serial numbers threaten CMDB integrity and increase the risk of duplicates, ServiceNow provides prescriptive, step-by-step remediation guidance through the CMDB Data Foundations Dashboard Playbooks.

These playbooks are specifically designed to help administrators identify root causes, assess ingestion and governance gaps, and apply corrective actions using structured remediation plays (Analyze Data, Fix Data, Govern Data). For missing serial numbers, the playbooks guide teams to review Discovery patterns, identification rules, reconciliation sources, and governance controls to ensure authoritative data capture and prevention of future issues.

The CMDB Health Dashboard Playbooks focus on health scoring and metrics, not guided remediation. CSDM Data Foundations Dashboard Playbooks is not a distinct product naming; the correct construct is CMDB Data Foundations. Now Create Playbooks provide implementation project guidance, not operational troubleshooting for live data issues.

Therefore, the correct answer is A – CMDB Data Foundations Dashboard Playbooks, which are purpose-built to quickly troubleshoot and remediate CMDB data quality problems while aligning with best practices in ServiceNow.

CMDB 360, also known as Multisource CMDB , provides attribute-level visibility into the data contributed by different discovery and integration sources. It enables an administrator to examine which source supplied a particular attribute, compare competing values, identify missing source contributions, and understand how reconciliation selected the final value stored on the CI.

The guide explains that CMDB 360 reveals gaps in attribute data and differing attribute values across sources. These insights help administrators diagnose reconciliation conflicts, inappropriate source precedence, incomplete integrations, and inconsistent discovery results.

CMDB 360 is not itself the mechanism used to ingest records. Service Graph Connectors, IntegrationHub ETL, Import Sets, and Discovery perform ingestion. CMDB 360 instead preserves and exposes the source- level contributions after ingestion so that data owners can investigate and improve multisource data quality.

=========

CMDB Data Manager supports multiple governance policy types because CMDB lifecycle management is broader than simply deleting or certifying records. The complete set represented here is Retire, Archive, Attestation, Certification, and Delete. Retire policies support lifecycle transition of CIs that should no longer be active. Archive policies remove records from active operational use while preserving them according to retention requirements. Delete policies permanently remove records when they no longer need to be retained. Attestation policies validate that a CI still exists or is still relevant. Certification policies require users to validate and potentially correct specific CI attribute values. Options B, C, and D are incomplete because each omits at least one major CMDB Data Manager policy type. Option A is therefore the best answer because it includes both lifecycle/removal policy types and validation-focused policy types.

The CMDB and CSDM Data Foundations Dashboards are obtained from the ServiceNow Store as a free application. This is different from the standard CMDB Health Dashboard, which is part of the platform CMDB capability. The Data Foundations Dashboards provide guided visibility into CMDB and CSDM readiness, maturity, and remediation opportunities through metrics and playbooks. They are intended to help organizations improve CMDB quality and CSDM alignment without building custom dashboards from scratch. Option A is incorrect because this specific dashboard application is not simply active by default. Option B is incorrect because it is not a paid Store application. Option C is incorrect because the correct source is the ServiceNow Store, not Innovation Lab. Therefore, the correct answer is D.

=========

Service Mapping creates and maintains an Application Service by discovering the application’s entry point and tracing its dependencies across the supporting infrastructure. The resulting service map can include application components, servers, databases, middleware, load balancers, and communication relationships. This produces the service-aware topology required for impact analysis, incident investigation, and change-risk assessment.

ServiceNow Discovery identifies infrastructure CIs and can create technical relationships between discovered components, but Discovery alone does not normally build the complete, application-centric service topology requested in the question. Agent Client Collector gathers inventory and telemetry from devices through an installed agent, while Event Management processes and correlates operational events and alerts.

The study material identifies Service Mapping as the capability that builds Application Service topology and shows how services are supported by underlying applications and infrastructure. It also describes top-down Service Mapping as the recommended high-fidelity approach for mission-critical Application Services.

=========

Foundation → Use the base system tables when implementing CSDM to get the highest value from ServiceNow products and the Now Platform.

Design and Planning → Understand CIs related to Business Applications and related capabilities; identify redundancies, monitor costs, and make better investment decisions around the roadmap.

Service Consumption → Understand Business Services, ownership, cost, scope of work offered to business consumers, and request access to business services.

Service Delivery → Understand Technical Services, Technical Service Offerings, service support, and all relationships to underlying technology CIs.

CSDM separates data into domains so organizations can model business planning, consumption, and technical delivery without mixing concerns. The Foundation domain provides base reference data such as users, groups, companies, locations, and foundational tables used across the platform. Design and Planning supports architecture and portfolio planning through Business Applications, Business Capabilities, and Information Objects. Service Consumption focuses on how services are exposed to and consumed by business users through Business Services and Business Service Offerings. Service Delivery focuses on how services are technically operated using Technical Services, Technical Service Offerings, Application Services, and supporting infrastructure CIs. This separation is what makes CSDM valuable: each domain answers a different management question while still connecting to a unified service model.

=========

Creating new CI classes is a high-impact configuration activity and must follow strict Data Foundations and CSDM-aligned best practices to avoid long-term technical debt and upgrade risk.

Option B is a recommended first step. Before creating any new CI class, administrators should install or update the CMDB CI Class Models Store application and verify whether an appropriate class already exists. ServiceNow frequently delivers new CI classes through updates and class model packages, and duplicating an existing or planned class can lead to fragmentation and governance issues.

Option C is also correct. When a new class is truly required, it should be added under an appropriate parent class to inherit attributes, behaviors, and discovery patterns. For an IoT Sensor, this might be under a hardware or device-related parent class, ensuring consistency and minimizing customization.

Option A is incorrect and dangerous—deleting unused classes can break dependencies and historical data. Option D is also discouraged; modifying existing classes to repurpose them violates upgrade-safe design principles and can negatively impact discovery, integrations, and reporting.

By verifying existing models first and extending the class hierarchy correctly, organizations maintain a clean, scalable, and upgrade-safe CMDB.

Therefore, the correct answers are B and C.

Creating a custom CI class in the CMDB is a dictionary-level configuration activity and must be performed with the correct minimum privileges to ensure governance and upgrade safety in ServiceNow.

The sn_cmdb_admin role is required because it grants administrative access to CMDB structures, including CI class hierarchy management. This role ensures that changes align with CMDB governance controls and Data Foundations practices.

The personalize_dictionary role is also required because adding a new CI class involves creating or extending dictionary entries (tables, attributes, inheritance). Without dictionary-level access, a user cannot define new classes or attributes in the CMDB schema.

Option A is incorrect because sn_cmdb_admin alone is insufficient without dictionary privileges. Option B and D focus on form personalization, which affects UI layout only and does not allow creation of new CI classes. Additionally, itil_admin is not the correct role for schema-level CMDB changes.

Therefore, the minimal and correct role combination is sn_cmdb_admin and personalize_dictionary, making Option C the verified answer.

In ServiceNow, validating whether Configuration Items (CIs) still exist is a core CMDB governance activity. Over time, environments change rapidly—servers are decommissioned, cloud resources are torn down, and applications are replaced. If existence validation is not enforced, the CMDB quickly fills with obsolete or “ghost” CIs.

Attestation policies are specifically designed to address this need. An attestation policy automatically generates and assigns tasks to responsible users or groups, asking them to confirm that a CI still exists and is still relevant. This process focuses on acknowledgment rather than deep data validation, making it lightweight and scalable across large CMDBs.

Certification policies (Option A) are used when specific attributes must be validated, such as lifecycle status, support group, or environment. While important for data correctness, certification is not intended solely to confirm CI existence. Delete (Option B) and Retire (Option C) policies are lifecycle actions that remove or transition records, but they do not validate existence before taking action.

Attestation integrates cleanly with CMDB Workspace, assigns tasks automatically, and supports auditability—ensuring accountability for CI ownership. This makes it the correct and Data Foundations–aligned policy type for validating CI existence.

Therefore, Option D – Attestation is the correct answer.

CI Class Manager provides a centralized interface for reviewing and configuring the characteristics of each CMDB class. It includes class hierarchy information, attributes, identification rules, reconciliation settings, suggested relationships, principal-class configuration, and related governance information.

Identification rules define the attributes that IRE uses to determine whether incoming data matches an existing CI or should create a new record. Reconciliation settings identify which sources are authorized or prioritized for updating particular attributes. These capabilities allow an administrator to document the authoritative sources and identification criteria for principal CI classes in one management interface.

The CMDB Data Foundations Dashboard identifies foundational quality risks, while CMDB Data Manager controls lifecycle policies. CMDB Workspace is the broader operational interface, but CI Class Manager is the specific tool for class-level configuration and identification governance.

=========

The CMDB Data Foundations Dashboard identifies implementation risks and data-quality deficiencies, while its associated playbooks provide structured remediation guidance. The playbooks lead the administrator through a repeatable sequence for understanding the problem, identifying affected records and data sources, correcting existing data, and introducing governance controls to prevent recurrence.

The dashboard does not automatically install or configure third-party integrations. Those integrations are handled through capabilities such as Service Graph Connectors, IntegrationHub ETL, and Discovery. It also does not replace the CMDB Health Dashboard. CMDB Health calculates and reports metrics such as completeness, correctness, compliance, duplicates, orphaned CIs, and stale CIs. The Data Foundations Dashboard complements those health capabilities by focusing on foundational readiness and guided improvement.

Therefore, the defining benefit of the playbook is its step-by-step approach to improving CMDB data quality and alignment with recommended practices.

=========

CMDB 360 / Multisource CMDB extends the standard IRE by enabling Dynamic Reconciliation Rules, which determine attribute values dynamically based on incoming data patterns rather than fixed source priority.

Within the Create Reconciliation Rule wizard, two supported dynamic rule types are:

Most Reported (Option B): selects the attribute value that is reported most frequently across all sources. This is useful when multiple sources contribute data and consensus is a strong indicator of correctness.

Last Updated (Option C): selects the most recently updated value, which is useful for rapidly changing attributes such as IP address or operational state.

Option A (Smallest Value) and Option D (Last Created) are not supported dynamic reconciliation rule types in ServiceNow.

Dynamic reconciliation rules are particularly valuable in complex, multisource environments where rigid source precedence is insufficient and data confidence must be inferred.

Therefore, the correct answers are B – Most Reported and C – Last Updated.

Business Application records represent logical applications from a portfolio, ownership, investment, risk, and lifecycle perspective. They are principally used by Application Portfolio Management and Enterprise Architecture to support application rationalization .

Rationalization enables an organization to evaluate applications based on factors such as business value, technical fitness, cost, risk, lifecycle status, capability alignment, and functional redundancy. Decision-makers can then determine whether an application should be invested in, tolerated, migrated, consolidated, replaced, or retired.

Application availability is normally monitored through operational Application Services and their supporting infrastructure rather than through the logical Business Application record. Change impact analysis also relies mainly on Application Services, service maps, and relationships to affected infrastructure CIs.

Because Business Applications belong to the Design and Planning context and provide strategic portfolio information, application rationalization is the appropriate business-decision use case

Bottom of Form

In a mature CMDB implementation within ServiceNow, CI operational attributes are leveraged to automate ITSM workflows. One of the most important outcomes of accurate Configuration Management is automatic incident routing.

When a CI is selected on an Incident record, ServiceNow evaluates the CI’s Support Group attribute. If populated correctly, the platform automatically copies this value into the Assignment Group field on the Incident. This ensures incidents are routed to the correct resolver group without manual triage, reducing mean time to resolution (MTTR).

The Support Group is a CI attribute, not an incident field that drives workflow directly. The Assignment Group is the operational field used by Incident Management to assign ownership. Managed by Group, Approval Group, and Change Group are used in other governance and lifecycle contexts and are not auto-populated during incident creation.

This behavior is a direct result of Data Foundations best practices: maintaining accurate CI-to-support-group relationships to enable automation and consistency across ITSM processes.

Therefore, the correct answer is C – Assignment Group.

The correct option is Allow fallback to parent’s rules . In CI identification, ServiceNow evaluates the configured identification rule for the target class first. If the Tomcat rule cannot find a match using its class-specific criterion attributes, fallback behavior allows the Identification and Reconciliation Engine to attempt matching against the parent class identification rule. Since Tomcat is a more specific application class, falling back to the parent Application identification rule helps prevent unnecessary duplicate records when a match cannot be made at the subclass level. “Applies to” defines the class or scope for the identifier entry. “Independent” controls whether a rule is evaluated independently rather than through parent inheritance. “Criterion attributes” are the fields used for matching, not the fallback setting. Therefore, the correct configuration is Allow fallback to parent’s rules .

=========

Identification rules are configured through CMDB CI Class Manager . These rules define how the Identification and Reconciliation Engine determines whether an incoming CI already exists or whether a new CI record should be created. For server records, identification rules usually rely on attributes such as serial number, name, hostname, hardware identifiers, or other class-specific criteria. If these rules are weak or missing, duplicate server records can be created during Discovery, Service Graph Connector imports, or other integrations. The CMDB Health Dashboard detects health issues such as duplicates, but it is not where identification rules are configured. CMDB Workspace provides operational access to CMDB capabilities, but CI Class Manager is the correct configuration location. CMDB Data Manager governs lifecycle policies, not IRE identification logic. Therefore, the correct answer is B.

=========

A CI class is set as a Principal Class from the Basic Info tab in CI Class Manager by selecting the Principal Class check box. Principal Classes are important because they control which CI classes are treated as primary, operationally meaningful classes in CMDB processes and reference fields. For example, Principal Classes influence which CIs appear in key task fields such as Configuration Item fields on Incident, Change, and other ITSM records. This keeps users from selecting low-level or irrelevant child records when the business process expects a meaningful CI. There is no separate requirement to click a dedicated Principal Class UI Action, and it is not configured through a Yes/No choice list in this scenario. The Basic Info tab exposes the class-level property directly, so checking the Principal Class checkbox is the correct configuration action.

The CMDB Data Foundations Dashboard is paired with Get Well Playbooks that guide administrators through structured remediation. The “Services Have Owners Identified” playbook focuses on closing ownership gaps for services, which is a governance and data correction activity.

Fix Data (Option A) is used to correct missing or incorrect values, such as populating owner fields, assigning responsible groups, or updating relationships. In this playbook, Fix Data actions are required to actually remediate the issue by assigning owners to services.

Govern Data (Option D) is also required because ownership is not a one-time correction—it must be enforced and sustained. Govern Data establishes policies, ownership accountability, and controls (such as certifications or attestations) to ensure services continue to have owners over time and do not regress.

Analyze Data (Option B) is used to understand patterns and root causes, but it does not remediate the issue. Report Data (Option C) provides visibility and communication, not corrective action.

Therefore, the remediation plays that apply to the Services Have Owners Identified playbook are Fix Data and Govern Data, making Options A and D correct.

The correct answer is Service Delivery . In CSDM, the Service Delivery domain focuses on how services are technically delivered and operated. It includes the modeling of technical services, technical service offerings, application services, infrastructure CIs, and the relationships that connect them. The scenario specifically asks about Infrastructure CIs, Technology Management Offerings, Technical Service Offerings, and Application Services, which are all part of the technical operating model for delivering services. Foundation is used for base reference data such as locations, groups, companies, and users. Design and Planning focuses on business applications, capabilities, and planning artifacts. Service Consumption focuses on how consumers access and consume services. Build and Integration is associated with development and deployment activities. Because the question is about technical service relationships and operational service delivery, Service Delivery is the correct CSDM domain.

=========

The Crawl stage establishes the initial CSDM foundation and design information required to create a usable CMDB. This includes identifying applications, their ownership, associated Application Services, foundational reference data, and essential relationships.

The Application Owner provides authoritative information concerning the Business Application, including ownership, lifecycle, criticality, purpose, and portfolio context. The Application Service Owner provides operational knowledge about the deployed Application Services, their environments, support arrangements, and relationships to underlying CIs.

The guide explains that Crawl addresses the Foundation and Design domains. Foundation establishes organizations, locations, users, groups, products, and core CI information, while Design introduces Business Applications, capabilities, processes, Information Objects, ownership, and architecture context.

Business Service Managers and Technology Service Owners become more central as business-facing and technical services mature during later stages. Customer Service Managers are primarily associated with service consumption. Therefore, B is correct.

=========

The Asset-CI Field Mapping capability is specifically designed to control synchronization between related Asset and CI records. The Configuration Analyst can create or configure a field-mapping rule so that the Computer CI’s Owned by value is propagated to the corresponding Asset field through the platform’s supported synchronization framework.

CI Class Manager controls CMDB class definitions and does not create parent-child inheritance between Asset and CI tables for field synchronization. A scheduled integration could copy the information, but it introduces unnecessary processing and delay when an out-of-box synchronization mechanism exists. A scripted business rule could also work technically, but it introduces custom code, maintenance effort, and upgrade risk.

Using Asset-CI Field Mapping provides a governed, supportable, and reusable configuration that keeps the operational CI and financial Asset perspectives aligned.

=========

The Correctness scorecard evaluates whether CI data accurately represents the real environment. It includes the Duplicate , Orphan , and Staleness metrics.

Duplicate identifies cases where the same real-world configuration item is represented by multiple CMDB records. Orphan identifies CIs that lack expected relationships or supporting context. Staleness identifies records that have not been updated within the configured period and may no longer represent active infrastructure.

The other choices belong to different CMDB Health KPIs. Audit belongs to Compliance because it evaluates whether CI values satisfy defined standards or desired-state conditions. Required and Recommended belong to Completeness because they measure whether mandatory and useful attributes are populated.

Therefore, Duplicate, Orphan, and Staleness are the metrics shown under Correctness.

=========

In the CMDB Health Dashboard, the format Healthy CIs / Evaluated separates two different meanings. The Evaluated value represents the total number of CIs included in the metric calculation scope. The Healthy CIs value represents how many of those evaluated CIs passed the metric. In this question, 60,000 server records were evaluated for the Duplicate metric, so 60,000 server records are in scope. Of those, 59,000 are healthy, meaning they are not considered duplicate according to the duplicate evaluation logic. The remaining 1,000 are not healthy for that metric and require investigation or remediation. Option B incorrectly treats the healthy count as the scope. Option C identifies the unhealthy difference, not the evaluated scope. Option A invents a Linux/Windows breakdown that is not provided by the scorecard. Therefore, the evaluated scope is 60,000 server records.

CMDB 360, also known as Multisource CMDB, is designed to provide visibility into how multiple discovery or integration sources contribute data to the same CI. Its value is not simply identifying duplicate or orphan CIs; those are handled through CMDB Health and de-duplication capabilities. CMDB 360 helps administrators compare source contributions and understand conflicts or gaps across those sources. A key insight is gaps in attribute data, where one source supplies certain CI attributes while another source does not. Another key insight is different attribute values from different data sources, which helps identify reconciliation problems, source precedence issues, and inconsistent discovery results. This is central to improving data trust because the CMDB often receives data from Discovery, SCCM, cloud connectors, manual imports, and third-party systems. Therefore, the correct insights are gaps in attribute data and different attribute values across sources.

The Design and Planning domain of CSDM focuses on planning-level constructs such as Business Applications, Business Capabilities, Information Objects, and architecture context. The two roles most directly involved are the Application Owner and the Enterprise Architect . Application Owners provide authoritative ownership, lifecycle, criticality, and portfolio information for Business Applications. Enterprise Architects define and govern enterprise capabilities, application rationalization, architecture alignment, and strategic planning relationships. Application Service Owners are more closely aligned with operational service delivery and application service health, especially in the technical/manage domain. Business Relationship Managers are more closely tied to consumption, offerings, and business-facing service value. Because Design and Planning is about application portfolio and enterprise architecture structure, the correct roles are Application Owner and Enterprise Architect.

=========

CMDB Query Builder provides purpose-built Export Query and Import Query functions for transferring saved query definitions between ServiceNow instances. The administrator selects the saved query, exports its definition as an XML file, and the receiving team imports that file using the Import Query function. The imported definition then appears in the destination instance’s Saved Queries tab.

Exporting the query as a report would transfer report configuration rather than the complete Query Builder canvas and relationship definition. A generic record-level XML export is not the prescribed Query Builder workflow.

ServiceNow also documents transfer through an update set, but identifies that process as an alternative maintained for backward compatibility. Because the question asks for the direct and recommended Query Builder approach, Option A is the best answer.