CIS-DF Certified Implementation Specialist - Data Foundations (CMDB and CSDM) Questions and Answers

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.

=========

Automatic relationship creation is fundamental to maintaining a service-aware and trustworthy CMDB. In ServiceNow, this capability is primarily delivered by Discovery and Service Mapping.

Discovery (Option C) automatically identifies infrastructure components—such as servers, network devices, and storage—and creates technical relationships between them (for example, “runs on,” “connected to,” or “depends on”). These relationships form the backbone of infrastructure dependency mapping.

Service Mapping (Option B) builds on Discovery by creating application- and service-level relationships. It maps how application components interact across servers, databases, and middleware, resulting in accurate Application Service models aligned with CSDM. These relationships are created and maintained automatically as the environment changes.

Option A (IntegrationHub ETL) focuses on data ingestion and transformation; it does not inherently create or maintain relationships unless explicitly scripted. Option D (Workflow Studio) orchestrates processes and automations but does not discover or infer CI relationships.

Therefore, the ServiceNow solutions that create automatic relationships are Service Mapping and Discovery, making Options B and C correct.

In ServiceNow, the CMDB Health Dashboard does not calculate health scores in real time by default. Instead, health scores are generated and refreshed by scheduled calculation jobs that evaluate CI data against defined health rules across the dimensions of completeness, correctness, and compliance.

To generate and maintain CMDB health scores, the scheduled jobs for CMDB Health must be active. These jobs periodically scan the CMDB, apply health rules (for example, required attributes populated, lifecycle status compliance, certification results), and calculate scores that are displayed on the dashboard and scorecards. Without these scheduled jobs running, the dashboard cannot produce current or meaningful health metrics.

Option B is incorrect because CMDB health scoring is not automatic or real-time; it depends on scheduled processing. Option C is also incorrect because CMDB Health is part of the core CMDB/Data Foundations capability in ServiceNow and does not require a separate “CMDB health calculation” plugin to be installed in modern implementations.

Activating and maintaining these scheduled jobs ensures that health scores remain accurate, trendable over time, and useful for governance decisions. This is a foundational requirement for using the CMDB Health Dashboard as a data quality improvement tool.

Therefore, the correct answer is A – The scheduled jobs for the CMDB Health Dashboard must be activated.

The CMDB Data Foundations Dashboard helps administrators assess whether important CMDB data is valid, properly configured, and aligned with expected data quality practices. It is designed to surface actionable gaps and risks, then guide remediation through playbooks. Therefore, B and C are correct. The dashboard does not automatically remediate all risks by itself; it guides administrators and data owners toward corrective actions through structured playbooks. It also is not primarily a custom metric development framework. Its purpose is to provide curated, ServiceNow-aligned metrics and remediation guidance for CMDB and CSDM maturity. This makes it useful for improving data health, identifying configuration issues, and supporting governance without requiring custom reporting or manual analysis from scratch.

=========

The correct answer is 75 because the Windows Server class has its own dynamic reconciliation rule configured as most reported for the Disk Space field. Even though the parent Server class uses the lowest value rule, the more specific class rule on Windows Server takes precedence for Windows Server records. In CMDB 360 / Multisource CMDB, dynamic reconciliation evaluates values from multiple contributing sources and selects the value according to the configured reconciliation strategy. Here, 75 GB is reported by two sources: Thycotic and ServiceNow. The other values, 50 GB and 80 GB, are each reported only once. Because the rule is “most reported,” the value appearing most frequently across sources is selected. Therefore, 75 GB is added to the CMDB.

=========

The Agent Client Collector (ACC) in ServiceNow is designed to collect inventory data from endpoints that are not consistently reachable by traditional Discovery methods. ACC is especially valuable where credential-based, network-based discovery is impractical or impossible.

Devices in secure environments (Option C), such as isolated networks, restricted zones, or highly regulated environments, often block inbound discovery traffic. ACC runs locally on the device and securely sends inventory data outward, making it ideal for these scenarios.

Devices that intermittently connect to the network (Option D), such as laptops, remote endpoints, or roaming devices, are another core use case. Traditional Discovery requires the device to be reachable during scheduled scans, which is unreliable for mobile or off-network assets. ACC ensures inventory data is collected whenever the device is online.

Option A (data center servers) is better served by agentless Discovery, which provides deeper infrastructure and relationship data. Option B (network devices in the DMZ) are typically discovered using SNMP and network discovery, not ACC.

ACC complements Discovery as part of a layered ingestion strategy, ensuring accurate inventory coverage across diverse environments.

Therefore, the correct answers are C – Devices in secure environments and D – Devices that intermittently connect to the network.

The correct answer is CSDM Data Foundation Dashboard because the requirement is specifically about end-to-end service modeling and guided improvement through status and playbooks. CSDM guidance focuses on modeling services, application services, business applications, offerings, technical services, and their relationships. The CSDM Data Foundation Dashboard provides visibility into CSDM maturity and uses playbooks to guide remediation of weak or missing service-model data. Service Mapping is only one technical capability used to discover and map service relationships; it is not the overall governance dashboard for CSDM adoption. CMDB Workspace is the broader operational workspace for CMDB management, but the question asks for status and playbook-based guidance for CSDM service modeling quality. Therefore, the best reference point is the CSDM Data Foundation Dashboard.

=========

In Data Foundations, “insight” focuses on turning trusted configuration data into clear visual understanding—so teams can assess relationships, troubleshoot impact, and validate service context. Unified Map supports this by providing a graphical view of CIs and their relationships, combining strengths of traditional dependency views and service-mapping-style visualization into a single, consistent map experience.

Unified Map is accessed from CMDB Workspace, typically via a Quick Links entry (and in some experiences, also from relevant CI/service contexts). This location makes sense in the Data Foundations model because CMDB Workspace is the central place where configuration and service data is explored, validated, and used for operational decision-making—exactly what mapping relationships is meant to enable.

The other options do not fit the purpose or access pattern. CI Class Manager is focused on defining and maintaining CI class structures and related class settings; it is not the user entry point for relationship visualization. CMDB Data Manager is focused on governance through lifecycle policies (attestation, archival, deletion) and bulk lifecycle operations—again, not the primary interface for interactive mapping and dependency exploration.

Therefore, for a Configuration Manager seeking to use Unified Map for relationship and dependency insight, the correct access point is CMDB Workspace.

A Web Server is an application or software CI hosted on an underlying physical or virtual Server CI. The standard ServiceNow relationship is therefore Runs on::Runs .

From the Web Server’s direction, the relationship reads Web Server runs on Server . From the reverse direction, the Server runs Web Server . This bidirectional relationship allows users and platform processes to traverse the relationship correctly during incident investigation, service impact analysis, change planning, and service mapping.

“Uses::Used by” represents a broader dependency or consumption relationship and does not accurately express direct software hosting. “Runs::Runs on” reverses the standard relationship direction presented in the question.

Discovery can identify the running software and its host and create the relationship automatically as part of the ingestion process. Therefore, the correct relationship is Web Server > Runs on::Runs > Server.

=========

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 CMDB Data Foundations Dashboard in ServiceNow is intended to provide ongoing, trend-based visibility into how well the CMDB ingestion and maintenance processes are functioning—not just point-in-time issue lists. This is why continual monitoring of its metrics is valuable.

Option B is correct because tracking active CIs updated in the last 90 days provides a strong indicator of data freshness and operational relevance. A healthy CMDB should reflect recent updates from Discovery, integrations, and governed manual processes. Monitoring this metric over time helps organizations detect stagnation, discovery failures, or integration issues early.

Option C is also correct because metrics for CIs processed by the Identification and Reconciliation Engine (IRE) directly indicate the effectiveness and adoption of governed ingestion practices. Consistent IRE processing confirms that integrations are not bypassing identification rules, reducing duplicates and improving trust in CMDB data. Trending this metric helps validate Data Foundations maturity.

Option A is incorrect because the dashboard is not designed to provide exhaustive audit failure lists; those are handled through certification and remediation workflows. Option D is also incorrect because orphan CIs are a specific health condition surfaced via health rules and remediation tools, not a core benefit metric for continual dashboard monitoring.

Therefore, the correct answers are B and C.

Design Domain → Enterprise Architect(s), Data Steward(s), Process Owner(s), Platform Owner

Foundation Domain → Enterprise Architect(s), Platform Owner

Portfolio Domain → Service Owner(s), Platform Owner

Technical Domain → Technology Service Owner(s), Application Service Owner(s), Platform Owner

CSDM governance requires the correct domain owners because each domain represents a different type of data accountability. The Design Domain is architecture-heavy and requires Enterprise Architects, Data Stewards, Process Owners, and the Platform Owner to ensure planning data is accurate and aligned. The Foundation Domain depends on shared platform reference data, so Enterprise Architects and the Platform Owner are key stakeholders. The Portfolio Domain is concerned with service ownership and service portfolio accountability, so Service Owners and the Platform Owner are the primary governance roles. The Technical Domain governs operational service and application service data, so Technology Service Owners, Application Service Owners, and the Platform Owner are needed. This division prevents one team from owning all CSDM data incorrectly and creates clear accountability.

=========

The query must contain the Application Service and Configuration Item nodes, the appropriate relationship between those nodes, and filters that restrict the results to the named Application Service and operational CIs.

Option A only adds Operational Status and Name as result columns. Displaying a field as a column does not filter records according to that field, so non-operational CIs could still appear.

Option C unnecessarily adds the Business Application class. The requirement is to find CIs belonging to a specific Application Service; no Business Application condition or relationship is required. Adding unnecessary classes can complicate the query and potentially alter its results.

CMDB Query Builder is designed to traverse relationships between CMDB classes. The guide similarly explains that Application Services and their related infrastructure should be represented through a CMDB query and connected through CMDB relationships.

Therefore, the correct sequence is Option B.

=========

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.

In Data Foundations, “Govern” includes maintaining consistency between closely related data domains so that operational and asset lifecycle processes remain trustworthy. For hardware endpoints (and other asset-backed items), Asset and CI records often represent the same real-world item from two perspectives: financial/lifecycle management (Asset) and operational/service context (CI). Automatic synchronization prevents drift such as different owners, locations, or statuses appearing in Asset vs CI, which can cause reporting errors, incorrect fulfillment decisions, and audit issues.

The platform supports synchronization through out-of-box synchronization logic (commonly implemented as business rules and related configuration) that updates the CI when an Asset changes, and updates the Asset when a CI changes—so the records stay aligned regardless of which team updates which record. Therefore, ensuring the Asset-to-CI update logic is active (A) and the CI-to-Asset update logic is active (B) is the right way to keep data synchronized automatically.

Option C is not required for synchronization; the intent is near real-time consistency driven by record changes, not batch jobs that run later. Scheduled jobs might exist for other maintenance activities, but they are not the primary mechanism for keeping Asset/CI synchronized. Option D is important as a data quality principle—ideally one Asset maps to one CI for physical items—but “ensuring one-to-one mapping” is not the automation mechanism itself. Automation is achieved through the active synchronization logic, which is why A and B are the correct answers.

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 , 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.

=========

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.

The CMDB Data Foundations Dashboard gives Configuration Management teams visibility into the condition, readiness, and quality of CMDB data. It presents curated metrics that expose gaps involving important attributes, configuration practices, relationships, ownership, and data-governance readiness. These results help administrators determine where corrective action is necessary and prioritize remediation according to operational risk.

The dashboard does not eliminate audits. Auditing, certification, attestation, and health calculations remain separate controls required to validate data. It also does not automatically correct every issue. Instead, the dashboard provides actionable findings and links to structured remediation playbooks that guide administrators through analysing, correcting, and governing the affected data.

The study guide specifically describes dashboard benefits as providing actionable insights for improving data quality and completeness and enabling CMDB health to be monitored over time. Therefore, improved visibility into CMDB health and data quality is the only accurate answer.

=========

In ServiceNow, the Duplicate CI Remediator is designed to resolve duplicate records while preserving the most authoritative data from each source. Data Foundations guidance clearly states that automated discovery is the system of record for technical attributes, such as IP address, hostname, and operational status, while manually maintained records often contain valuable business context, such as relationships to business applications or services.

In this scenario, the discovered CI contains the most accurate and up-to-date technical data, making it the correct CI to retain as the primary record. However, the manually imported CI has a critical relationship to a business application, which is essential for impact analysis, incident prioritization, and CSDM alignment. Deleting this CI without preserving the relationship would result in loss of business context and reduced CMDB value.

The Duplicate CI Remediator supports selective merging, allowing administrators to retain one CI while merging specific attributes or relationships from the duplicate. Option C reflects this best practice by retaining the discovered CI and merging the relationship from the manually imported CI, ensuring both technical accuracy and business relevance are preserved.

Options A and D would result in the loss of important relationship data, while Option B would discard the discovered CI, violating the principle that discovery should be the authoritative source for technical attributes.

Therefore, Option C is the correct and Data Foundations–aligned answer.

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.

Custom CMDB class tables should begin with u_cmdb_ci . The u_ portion identifies a customer-created table, while cmdb_ci preserves the standard CMDB naming convention and clearly indicates that the table extends the Configuration Item hierarchy.

For example, appropriate custom class names may resemble u_cmdb_ci_custom_router or u_cmdb_ci_special_switch. The uploaded guide uses these exact naming patterns when discussing custom-class consolidation and the technical debt created by unnecessary custom classes.

Using only cmdb_ci would incorrectly suggest an out-of-box ServiceNow table. Prefixes such as u_ci_cmdb and ci_cmdb do not follow the standard hierarchy convention. Before creating any custom class, the administrator should still verify that a suitable supported class is not already available through the CMDB CI Class Models application.

=========

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.

The Desired State audit type is included in the CMDB Health Compliance calculation. A desired-state audit compares the actual values stored on a CI against the values or conditions that the organization expects the CI to meet.

In this scenario, the organization’s desired state is that every server must have the current approved patch level. A Certification Template can define the server population and attributes to be evaluated. The resulting audit identifies servers that do not satisfy the expected patch condition, and those results contribute to the Compliance KPI.

“Compliance” is the name of the overall CMDB Health scorecard, not the audit type selected for this check. “Architecture Compliance” is not the applicable audit type for validating server patch-level attributes.

The Compliance scorecard uses audit results to determine whether CIs conform to defined organizational standards. Therefore, the correct audit type is Desired State .

=========

The CMDB Data Foundations Dashboard is designed to provide visibility, insight, and guidance into the overall health of CMDB data. Its purpose is not to automate ITSM workflows, but to enable informed decision-making and continuous improvement of configuration data.

One of its primary benefits is providing actionable insights to improve data quality and completeness (Option B). The dashboard highlights gaps in CI attributes, missing relationships, and compliance issues, enabling CMDB administrators and data owners to take targeted corrective actions using Get Well Playbooks.

Another core benefit is enabling organizations to monitor and track CMDB health over time (Option D). The dashboard presents trends across health dimensions—completeness, correctness, and compliance—allowing teams to measure progress, justify investments, and demonstrate maturity improvements aligned to CSDM adoption stages.

Option A is incorrect because Change Management approvals are handled by workflow and policy engines, not the Data Foundations Dashboard. Option C is also incorrect because duplicate detection and remediation are handled through de-duplication tools and the Duplicate CI Remediator, not directly by the dashboard itself.

Therefore, the correct answers are B and D, which accurately reflect the strategic and operational value of the CMDB Data Foundations Dashboard.

For a hardware item that has both a CI record and an associated Asset record, ServiceNow maintains alignment between corresponding lifecycle fields. When the Hardware Status value changes on the CI, the related high-level lifecycle value on the Asset is synchronized through the State field.

The Asset State field represents the asset’s broad lifecycle condition, such as In Stock, In Use, In Maintenance, Missing, or Retired. A Substate provides a more detailed qualification of a State and is not the direct field requested by this Hardware Status update. The Asset tag is an identifying inventory value, while Installed is a date-related field; neither represents the corresponding lifecycle state.

The Data Foundations guide explains that the platform uses Asset-to-CI and CI-to-Asset synchronization logic so that updates made from either operational Configuration Management or financial and lifecycle Asset Management remain aligned. This prevents conflicting status information, inaccurate reports, and incorrect lifecycle decisions. Therefore, the associated Asset’s State field is automatically synchronized.

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.

Within Data Foundations, “Configuration” includes designing the CMDB data model in a way that supports operational usability—especially for ITSM processes like Incident and Change. One common usability challenge is that CI reference fields (such as the Incident “Configuration item” field) can become cluttered and confusing if they allow selection from every CI class, including highly technical or rarely used classes. To address this, ServiceNow uses the concept of Principal Classes: a curated subset of CI classes that are considered primary for operational selection and reporting.

Principal Classes are designated in the CI Class Manager, because this is where administrators configure and manage CI class behaviors and class-level settings. Defining Principal Classes at the class-management layer ensures that the platform can consistently apply this constraint across CI reference fields and related experiences. This aligns with Data Foundations goals: improving data quality and process outcomes by making it easier for users to select the correct CI, which in turn increases accuracy for assignment, routing, impact analysis, and analytics.

The other options do not fit the responsibility. CMDB Workspace is primarily used for exploring and analyzing CMDB data, not configuring class-level constraints. CMDB Data Manager focuses on governance automation (like lifecycle policies and bulk remediation operations), not CI class designation rules. System Properties may influence global behaviors, but Principal Class designation is a modeling configuration handled through CI class configuration, which is why CI Class Manager is the correct location.

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.

=========

The correct answer is Data Quality Scheduled Job because CMDB data quality checks are not simply visual or manual activities. Scheduled jobs are used to execute recurring evaluations that calculate and refresh quality indicators for CI records. These jobs support CMDB health and data quality by periodically checking records against configured rules, such as stale records, missing required attributes, compliance conditions, or correctness-related metrics. CMDB Workspace is the interface where users can review and act on CMDB information, but it is not itself the mechanism that performs scheduled quality evaluation. Business rules can enforce logic during insert or update actions, but they are not the normal mechanism for recurring CMDB data quality calculation. Therefore, the Data Quality Scheduled Job is the best answer.

=========

CMDB 360, also known as Multisource CMDB, preserves source-specific CI information instead of retaining only the final reconciled value. Administrators can therefore examine the latest values contributed by individual sources and identify missing, inconsistent, or conflicting attribute values. This source-level history also allows the platform to recalculate the winning CMDB value after reconciliation logic changes, without requiring each source to submit its data again.

Option B is therefore correct because stored multisource data supports recomputation following a reconciliation-rule change. Option D is correct because CMDB 360 records the latest source contribution and makes it available for comparison and analysis.

Option A is misleading. Standard IRE reconciliation rules can use discovery sources even when CMDB 360 is not enabled; CMDB 360 enhances visibility and recomputation but is not what makes basic source-priority rules possible. Option C describes the broader role of CMDB Health or Data Foundations dashboards rather than CMDB 360. The guide identifies source-value gaps and differing source values as the principal insights delivered by CMDB 360.

=========

CMDB 360/Multisource CMDB retains information about the values contributed by individual data sources. When reconciliation logic is modified, the administrator can perform a recompute operation so the latest rules are applied to the stored source contributions without waiting for every external system to send the data again.

This enables administrators to test and refine source-precedence or dynamic reconciliation rules and then recalculate the resulting CI attribute values using the available historical source data. The capability is particularly useful when correcting an inappropriate source-priority rule or implementing dynamic rules such as Most Reported or Last Updated.

CMDB 360 does not eliminate identification rules, permanently lock records, or automatically archive records based on quarterly reporting behaviour. Identification remains necessary to match incoming data to the correct CI, while reconciliation determines which authorized source controls an attribute.

=========

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, 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, “Insight” includes using dashboards and guided remediation to identify and fix issues that degrade CMDB trust. Missing serial numbers on Hardware CIs is a high-risk data quality issue because serial number is commonly used as a key identifier for uniqueness. When it is missing, identification and reconciliation become less reliable, increasing the likelihood of duplicate CI creation from Discovery, integrations, or manual entry.

ServiceNow provides structured, prescriptive guidance through the CMDB Data Foundations Dashboard Playbooks. These playbooks are designed specifically to help administrators move from a dashboard finding (for example, low uniqueness or incomplete key identifiers) to a repeatable remediation approach. They typically guide you to: confirm the scope of impacted CI classes, validate which sources should populate serial number (Discovery, integrations, import sets, vendor feeds), verify mapping and transformation logic, and then remediate existing records while putting controls in place to prevent recurrence.

Option B focuses on CMDB Health Dashboard guidance, which is helpful for health scoring and rules, but the question explicitly references a data foundations-type remediation need tied to data completeness of key identifiers and timely resolution using structured guidelines. Options A and D are CSDM-focused and do not directly address CI identifier population and duplication risk in the CMDB ingestion context. Therefore, the structured guidelines to troubleshoot and resolve missing serial numbers in a Data Foundations context are the CMDB Data Foundations Dashboard Playbooks.

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 correct answers are C and D. Identification and reconciliation rules are essential because they control how incoming CI data is matched to existing records and how updates from different sources are reconciled. This prevents duplicate CIs and ensures that authoritative sources update the correct attributes. CI Class Manager is also required because it provides governance over CI class structure, attributes, and inheritance. Standardized CI classes prevent each source from classifying the same real-world object differently. Option A is the cause of the problem, not the solution. Option B introduces avoidable technical debt because custom scripts are harder to govern, maintain, and upgrade. A Data Foundations-aligned solution uses standard class governance plus IRE rules to enforce consistency across all sources.

=========

In ServiceNow Data Foundations, specifically within CMDB Data Manager, policies are used to enforce data quality, completeness, and governance across configuration items (CIs). When defining a Data Manager policy, administrators can configure task creation for non-compliant records and specify how those tasks are assigned. One key configuration is the Assignment type, where “User Group Field” allows assignment to a group dynamically based on a group reference field on the CI record.

Out of the box, ServiceNow provides two default and universally available group reference fields for this purpose:

Assignment Group

Managed By Group

These two fields are considered core CMDB governance fields and are consistently available across most CI classes. They align directly with ITIL 4 Service Configuration Management and CSDM accountability models, ensuring that remediation tasks are routed to teams responsible for operational ownership or technical management of the CI.

Assignment Group (Correct – D) This is the most commonly used operational field in ServiceNow. It represents the team responsible for working on tasks related to the CI and is fully supported by CMDB Data Manager for automated task assignment.

Managed By Group (Correct – C) This field represents the group accountable for managing the CI throughout its lifecycle. It is a standard CMDB field and is explicitly supported by Data Manager policies for governance-driven task routing.

The other options are not default Data Manager assignment fields:

Owned by Group is often added through extensions or governance customization and is not guaranteed to exist across all CI classes.

Support Group is a CSDM and ITSM operational concept, commonly derived or mapped, but it is not a default group reference field exposed for CMDB Data Manager task assignment.

From a Data Foundations and CSDM governance perspective, using Assignment Group and Managed By Group ensures consistent accountability, scalable automation, and alignment with CMDB best practices.

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.

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.

The correct answer is Pinned Classes . In CI Class Manager, pinning a class is used to keep frequently managed CI classes easily accessible. A CI Class Owner who regularly manages the Windows Server class does not need to search for it repeatedly through the full class hierarchy. By pinning the class, the owner can return to it quickly, improving administrative efficiency and reducing navigation overhead. “CI Favorites” is not the correct CI Class Manager feature in this context, and “Search CI Classes” can locate a class but does not streamline ongoing repeated management in the same way. Search is useful for one-time discovery, while pinned classes are specifically useful for recurring ownership and class administration tasks. Therefore, the feature that best supports this requirement is Pinned Classes.

=========

In ServiceNow, the Duplicate CI Remediator is a governed tool designed to safely resolve duplicate Configuration Items while preserving the most valuable and authoritative record. The first step in the remediation wizard is identifying the Main CI, which will be retained after remediation.

ServiceNow uses two primary attributes to help determine the best candidate for the Main CI:

Oldest Created (Option A)

The oldest CI is often preferred because it typically has a longer operational history, may be referenced by historical incidents, changes, problems, or audits, and is more likely to be embedded in downstream processes and reports. Retaining the oldest CI helps avoid breaking historical references.

Most Related Items (Option B)

A CI with the most relationships (for example, links to applications, services, incidents, or other CIs) is generally the most valuable from a business and operational context perspective. Preserving these relationships is critical for impact analysis, Change Management, and CSDM-aligned service modeling.

Options C (Newest Created) and D (Least Related Items) are not used as selection criteria because newer or weakly-related CIs typically contain less historical and relational value and are better candidates for removal or merging.

By prioritizing Oldest Created and Most Related Items, the Duplicate CI Remediator aligns with CMDB Data Foundations best practices, ensuring minimal data loss, preserved business context, and safer de-duplication outcomes.

Therefore, the correct answers are A and B.

The correct answer is C . In CSDM and Application Portfolio Management, a platform should be modeled as a Business Application with the architecture type Platform Host . Applications that run on or are provided by that platform should be modeled as Platform Applications and should reference the platform host. In this scenario, the ServiceNow Platform is the platform host, while Incident and Change are platform applications because they are capabilities delivered on the ServiceNow Platform. The relationship is not best represented by making all three applications generic web-based applications. That would lose the platform/application distinction. The preferred model is also not simply a Depends On relationship, because CSDM provides a more specific platform host reference model for this use case. Therefore, ServiceNow Platform should be Platform Host, and Incident and Change should be Platform Applications referencing ServiceNow Platform.

=========

The contextual side panel is the correct work area because it displays detailed information about the selected node in Unified Map. When a Service Owner selects the home node or a related CI/service node, the contextual side panel provides supporting operational context such as active Incidents, planned Changes, related records, and other actionable details. This is exactly the requirement in the question: the Service Owner does not merely need to see topology; they need related work items connected to the selected node. The Map itself displays relationships and topology, but it does not provide the detailed related-record panel by itself. The toolbox provides map interaction tools, and content controls influence what layers or types of content are displayed. Neither of those is the correct place to review related Incidents and Changes for a selected node. Therefore, the correct answer is Contextual side panel.

Managing CI classes and Principal Class designation is a schema-level CMDB activity that directly impacts how CIs appear in ITSM processes such as Incident, Change, and Problem. In ServiceNow, these activities require specific administrative privileges to ensure governance, security, and upgrade safety.

The sn_cmdb_admin role is required because it provides administrative access to CMDB structures, including CI class hierarchy management, Principal Class configuration, and overall CMDB governance. Without this role, users cannot add, remove, or govern CI classes effectively.

The personalize_dictionary role is also required because adding or removing CI classes involves dictionary-level changes. CI classes are implemented as tables that extend the CMDB schema, and modifying the Principal Class filter relies on dictionary metadata. This role grants permission to create, modify, or remove class definitions safely.

The sn_csdm_admin role focuses on managing CSDM constructs (domains, services, lifecycle alignment) but does not grant dictionary or schema modification rights. The cmdb_query_builder role is used only for querying and reporting and does not allow structural changes.

Therefore, the two required roles are personalize.dictionary and sn_cmdb_admin, making Options A and B 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.

=========

In ServiceNow CMDB governance, the CI Class Manager allows administrators to assign ownership and accountability at the class level. This ownership is used by governance tools—especially CMDB Data Manager—to automatically determine who receives tasks and actions related to data lifecycle management.

The group reference field that aligns with class ownership and is consumed by CMDB Data Manager policies is the Managed By Group. This field represents the team responsible for the technical stewardship and lifecycle management of CIs within that class.

When CMDB Data Manager executes policies such as retention, archival, or cleanup, it uses the Managed By Group to assign tasks to the appropriate data owners. This ensures governance actions are routed to the correct accountable team without manual intervention.

Approval Group, Support Group, and Change Group serve different purposes. Approval Group is used for workflow approvals, Support Group is used for operational ticket routing, and Change Group supports Change Management governance. None of these reflect data ownership at the class level.

Therefore, to leverage CI class ownership defined in the CI Class Manager within CMDB Data Manager policies, the correct field is Managed By Group, making Option B the verified answer.

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.

=========

IntegrationHub ETL is a ServiceNow data-ingestion application used to extract data from external sources, transform it through defined mappings, and load it into the CMDB. Its Robust Transform Engine provides a guided, low-code mechanism for mapping source data to appropriate CMDB classes, attributes, and relationships.

A major Data Foundations advantage of IntegrationHub ETL is its integration with the Identification and Reconciliation Engine. Incoming records can be processed through identification and reconciliation rules so that existing CIs are updated correctly, duplicate creation is reduced, and source-authority controls are respected.

Agent Client Collector is used to gather inventory and telemetry from devices through an installed endpoint agent. Service Mapping builds Application Service topology and dependency relationships; it is not the general ETL application for importing data from multiple external sources.

The guide identifies IntegrationHub ETL as the recommended method for importing external data through the Identification and Reconciliation API when a dedicated Service Graph Connector is not the applicable solution.

The correct answer is Configuration File Path . When the same application can be installed more than once on the same server, the identification rule must use an attribute that can distinguish one installed instance from another. Configuration File Path is stronger than file name because the same file name can exist in multiple installation directories. It is also stronger than version because multiple instances may run the same version. Port can help in some cases, but ports may be reused, changed, or not consistently available for every application pattern. Class is too broad because it only identifies the type of CI, not the specific application instance. A path-based criterion is more precise because it identifies where that application instance is installed on the server. Therefore, Configuration File Path is the best criterion attribute for preventing incorrect matches between multiple instances.

=========

A Business Application represents a logical application from a portfolio, ownership, investment, risk, and lifecycle perspective. Following an acquisition, Business Application records allow the combined organization to compare overlapping applications, identify redundant functionality, establish authoritative application ownership, and decide which applications should be retained, consolidated, migrated, replaced, or retired.

An Application Service represents a deployed and operational instance of an application, such as a production or development service. The Application class represents executable software components running on infrastructure, while Incident is a process record and not part of application portfolio modelling.

Business Applications belong to the CSDM Design and Planning domain and support application portfolio management and rationalization. Therefore, they are the appropriate records for unifying and evaluating the applications inherited through the acquisition.

=========

A web server is a software-based CI hosted on underlying server hardware or a virtual machine. The standard ServiceNow relationship is therefore Runs on::Runs . From the Web Server CI’s perspective, it runs on the Server CI. When the same relationship is viewed in the reverse direction, the Server runs the Web Server.

The reverse wording in Option B incorrectly changes the parent-to-child direction. “Uses::Used by” represents a dependency or consumption relationship, not the direct hosting relationship between installed software and its host. Option D reverses that unrelated relationship type.

ServiceNow documentation defines Runs on::Runs as the standard relationship between a software application CI and its hosting hardware or virtual machine, giving Tomcat running on a Linux server as an example. Discovery can automatically identify and load these CI relationships into the CMDB.

=========

This question hinges on understanding class-specific Dynamic Reconciliation Rules in CMDB 360 / Multisource CMDB within ServiceNow.

Although two different dynamic rules are configured, the rule applied depends on the CI class being evaluated:

For the Server class, the configured rule is Largest value for the RAM attribute.

For the Windows Server class, the rule Most reported would apply—but only if the CI were evaluated as a Windows Server.

The question explicitly asks for the resulting RAM value for a Server CI, not a Windows Server CI. Therefore, the Largest value rule governs the outcome.

Looking at the multisource values:

2,048 MB (LANDesk)

4,096 MB (Tivoli)

4,096 MB (ServiceNow)

8,192 MB (Altiris)

Under the Largest value dynamic reconciliation rule, the IRE selects the maximum numeric value, regardless of how frequently it is reported or which source provided it.

The Most reported logic (which would result in 4,096 MB) does not apply here because that rule is configured for a different class (Windows Server).

This scenario illustrates an important CMDB 360 principle: Dynamic reconciliation is evaluated per class, and child-class rules do not override parent-class rules unless the CI is actually classified under that child class.

The CMDB Data Manager is the ServiceNow capability responsible for generating actionable governance tasks and assigning them to CI class owners and data stewards. These tasks appear directly in the “My Work” tab within the CMDB Workspace, enabling proactive and role-based CMDB governance.

CMDB Data Manager focuses on data lifecycle management, including archival, retirement, and cleanup of CIs based on defined policies. When lifecycle rules or retention thresholds are met—or when human validation is required—the Data Manager creates tasks to prompt responsible owners to take action. This ensures that CMDB data remains accurate, compliant, and lean over time.

The CMDB Health Dashboard (Option C) provides visibility into health metrics such as completeness, correctness, and compliance, but it does not generate tasks. Similarly, De-duplication templates (Option A) support duplicate identification and remediation workflows, but they do not create ongoing governance tasks in the CMDB Workspace.

By surfacing tasks in “My Work,” CMDB Data Manager operationalizes governance and embeds accountability into daily workflows, which is a key principle of CMDB Data Foundations.

Therefore, the correct answer is Option B – CMDB Data Manager.

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 correct answer is that all related CIs are displayed in the Affected CIs related list. A Dynamic CI Group is used to represent a dynamically maintained set of CIs based on defined membership criteria. In this case, the group contains all Windows servers. When the group is referenced on a Change form, the practical purpose is to apply the Change to the group members rather than manually selecting each Windows Server CI. The Affected CIs related list is the correct place to represent the individual CIs impacted by the Change. Impacted Services are derived from service relationships and impact calculations, not simply from group membership. Therefore, referencing the Dynamic CI Group causes its related member CIs to be represented as affected CIs for the Change.

=========

In the CSDM lifecycle model, the Life Cycle Stage represents the broad phase of a CI or asset, while the Life Cycle Stage Status supplies a more precise condition within that phase. When a hardware-backed server reaches End of Life, valid disposition-oriented statuses include Disposed and Donated . These values indicate how the organization concluded responsibility for the physical item after its operational use ended.

“Charity” is not a standard lifecycle status. A charitable transfer would be represented by the standardized status Donated , rather than by creating a separate nonstandard value. “Broken” describes a physical condition and is not the appropriate standardized End-of-Life disposition status in this question.

The Data Foundations material distinguishes Life Cycle Stage as the macro lifecycle phase and Life Cycle Stage Status as its more granular condition. It also identifies “Disposed” as a lifecycle-status value rather than a CMDB Data Manager policy type. ServiceNow likewise defines lifecycle state as the combination of an item’s stage and status.

=========