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

Removing obsolete or inactive CIs from the CMDB must be handled carefully to avoid data loss, audit issues, and unintended operational impact. In ServiceNow, the recommended and governed approach is to use an archive policy.

Archive policies are designed to manage CI lifecycle cleanup based on defined conditions such as class, last updated date, lifecycle status, or operational state. In this scenario, the condition would target Linux Server CIs that have not been updated in six months. Archive policies can either archive or permanently delete records in a controlled, auditable manner, ensuring compliance with data retention and governance standards.

Creating a business rule (Option A) is strongly discouraged for bulk CMDB cleanup because it introduces technical debt, upgrade risk, and unpredictable side effects. A scheduled job (Option C) may automate execution but lacks governance logic and lifecycle awareness on its own.

Archive policies integrate with CMDB Data Manager, provide visibility into actions taken, and support approval and rollback where appropriate. This aligns fully with Data Foundations best practices for maintaining a lean, accurate, and trusted CMDB.

Therefore, the correct and recommended action is B – Create an archive policy.

In Data Foundations, “Insight” focuses on turning configuration data into actionable visibility. CMDB 360 (often associated with Multisource CMDB capabilities) provides a guided experience in CMDB Workspace for exploring CI data and running queries across sources. Within this experience, Saved Queries are managed directly under the CMDB 360 area of CMDB Workspace because they are part of the CMDB 360 query-and-analysis workflow.

A CMDB 360 Saved Query is not the same as a generic CMDB Query Builder query created from classic navigation modules. The CMDB 360 experience typically uses a tile/window approach where users can view existing saved queries, create new queries, modify them, and run them to retrieve CMDB 360 data aligned to multisource reporting and analysis. Keeping saved queries on the CMDB 360 tab makes them easy to discover and reuse for repeatable insights (for example, coverage and source comparisons, CI data quality checks by source, and targeted investigation of records).

The Insights tab in CMDB Workspace is generally used to understand adoption and health-related insights about CMDB features, not as the primary location for creating CMDB 360 multisource saved queries. “Coverage” is a specific lens/view and does not represent the saved-query creation workspace. “CMDB Query Builder” is a related capability, but the question explicitly asks where CMDB 360/Multisource Saved Queries are viewed and created in CMDB Workspace , which is the Saved queries window on the CMDB 360 tab.

This question tests understanding of reconciliation source priority in the Identification and Reconciliation Engine (IRE) in ServiceNow.

In reconciliation rules, lower numeric values represent higher priority. Therefore, the priority order is:

ServiceNow (100) – highest authority

Altiris (200)

SCCM (300) – lowest authority

Why A is correct

Because Altiris (200) has higher priority than SCCM (300), data from Altiris can update records originally inserted by SCCM. This is exactly how reconciliation precedence works—higher-priority sources can overwrite lower-priority ones.

Why C is correct

SCCM, even though it has the lowest priority, is still an authorized discovery source. It can insert new records into the Windows Server table when no existing CI is identified. Priority only affects updates, not the ability to create records.

Why B is incorrect

ServiceNow (priority 100) can update records from Altiris and SCCM because it has the highest priority. The statement incorrectly claims it cannot.

Why D is incorrect

SCCM does not have the highest authority. A higher numeric value means lower priority, so SCCM cannot update records created by higher-priority sources.

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

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

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

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

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

A CMDB delivers business value when it enables better outcomes across IT and enterprise service delivery—especially when aligned with CSDM so services, offerings, and supporting technology are connected in a consumable model. Two major business values are improved operational execution and improved business continuity.

Option C is a direct business value: a trusted CMDB improves incident and change management by providing accurate CI details, relationships, and service context. This supports faster triage and assignment, better prioritization, and higher-quality impact analysis for changes. When incidents and changes are informed by dependable configuration data, organizations reduce downtime, avoid unnecessary escalations, and make safer change decisions—benefits that the business experiences as higher service quality and fewer disruptions.

Option D is also a core business value: CMDB strengthens operational resiliency by enabling clearer dependency understanding and faster response to failures. Resiliency improves when teams can quickly identify what’s impacted, understand upstream/downstream relationships, and plan mitigation steps using known service-to-technology mappings. In regulated or mission-critical environments, this translates into better continuity, reduced risk exposure, and improved compliance reporting.

Option A can be beneficial, but it is more of a technical/operational mechanism than a primary “business value” statement in Data Foundations framing. Option B is primarily the domain of IT Asset Management and financial systems; while CMDB can relate to assets, it is not the system of record for financial management. Hence, the best two business values are streamlining incident and change management and strengthening operational resiliency.

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 Health Dashboard organizes data quality into practical, action-oriented metrics:

Audits validate correctness by comparing CI values against defined expectations (rules, policies, certifications).

Duplicate CIs represent redundant records and should be reduced to improve trust and reporting accuracy.

Orphan CIs lack required relationships or key context, limiting impact analysis and service visibility.

Recommended fields are not mandatory but add diagnostic value during incidents and problem investigations.

Required fields are enforced by the platform and closely tied to Identification & Reconciliation remediation.

Stale CIs signal aging data that no longer reflects the current environment.

This mapping aligns with CMDB Data Foundations best practices and how the Health Dashboard is designed to guide prioritization and remediation.

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.

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.

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.

The CMDB is a foundational capability that enables organizations to operate IT services with confidence, resilience, and efficiency. Its value lies not in automation for its own sake or financial data management, but in how it supports service-aware operations and decision-making.

Strengthening operational resiliency (Option A) is a core value of the CMDB. By maintaining accurate configuration data and relationships, organizations can better understand dependencies, assess risk, and recover more quickly from incidents or outages. A trusted CMDB enables proactive problem management and informed change planning, directly contributing to resiliency.

Streamlining Incident and Change Management (Option B) is another primary value. Accurate CI data allows incidents to be routed automatically to the correct support groups, enables faster root-cause analysis, and supports risk-based change assessments. This reduces manual effort, improves response times, and lowers operational risk.

Option C is incorrect because automating CI relationship maintenance is a capability enabled by tools like Discovery and Service Mapping—not a value in itself. Option D is also incorrect because financial data management is the domain of IT Asset Management (ITAM) and Financial Management, not the CMDB’s core value proposition.

In summary, the CMDB delivers value by improving operational resilience and optimizing ITSM processes, making Options A and B the correct answers.

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.

When building advanced CMDB queries using CMDB Query Builder in ServiceNow, the correct approach is to model CI scope, relationships, and task context explicitly on the canvas.

To limit results to databases in a specific location, the administrator must filter the Database CI node by the Location attribute. Therefore, Option C is required to scope the query to Database CIs where Location = Seattle.

To include Incidents related to those databases, the Incident table must be added from the Non-CMDB Tables list and linked through the task_ci relationship. This is exactly what Option A provides. CMDB Query Builder separates CMDB tables (CIs) from task and transactional tables, so incidents must be explicitly added from the Non-CMDB section.

Option B is incorrect because property columns on Application Services do not scope databases or incidents. Option D is unnecessary because relationship depth alone does not include non-CMDB task data and does not filter by location.

Thus, the correct actions are A (add Incident table) and C (filter Database by location).

In CSDM 5, production line monitoring systems (such as SCADA, MES, IoT telemetry platforms, and operational monitoring tools) are technical systems responsible for operating, monitoring, and supporting services, not for designing them or consuming them. These systems directly align with the Service Delivery (Manage Technical) domain.

The Service Delivery domain is used to model how services are technically delivered and operated, including the infrastructure, platforms, and operational technologies that ensure availability, performance, and reliability. In a manufacturing context, production line monitoring systems continuously observe equipment health, throughput, alerts, and operational metrics—making them part of the technical service delivery layer.

Option A (Build and Integration) applies to CI/CD pipelines and system construction activities. Option B (Foundation) focuses on base CIs such as locations, people, and organizations. Option C (Service Consumption) models how customers or consumers use services, which is not applicable here. Option D (Design and Planning) is used for service architecture and planning artifacts, not live operational systems.

Therefore, production line monitoring systems correctly belong in Service Delivery (Manage Technical), making Option E the correct answer.

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.

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.

Data Foundations emphasizes that “ingest” must produce CMDB data that is standardized, supportable, and upgrade-safe. When introducing custom CIs, the best practice is to reuse the most appropriate existing CI class (or an approved industry-aligned model) and only add what is necessary—this keeps the data model aligned with platform expectations and reduces downstream rework.

Option B supports this directly: the CMDB CI Class Models application is intended to help teams select a suitable existing class rather than inventing new classes unnecessarily. Reusing existing classes improves consistency across integrations, Discovery/Service Mapping patterns, reporting, and CMDB Health rules—reducing technical debt and making future platform upgrades smoother.

Option A is also aligned with best practice when used correctly: once you have the right CI class, extending that class to add additional attributes (new fields) is a standard, upgrade-safe customization approach. It preserves the underlying platform data structures and avoids breaking out-of-box behaviors, identification/reconciliation practices, and CMDB Health evaluations.

Option C is not appropriate because Asset tables serve a different purpose (financial/lifecycle tracking) than CI tables (operational/service context). Mixing CI attributes into Asset classes creates confusion and process misalignment. Option D is strongly discouraged because repurposing and renaming base attributes creates long-term ambiguity, breaks shared semantics, and increases upgrade and maintenance risk.

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 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 CMDB Health Dashboard is a central component of CMDB Data Foundations insight and governance. It measures and tracks data quality using well-defined health indicators that focus on the accuracy, relevance, and usability of CI data.

Two key data quality areas included in the dashboard are Stale CIs and Duplicate CIs.

Stale CIs (Option D) refer to configuration items that have not been updated within a defined time window. These records are risky because they may no longer reflect the current state of the environment, leading to inaccurate impact analysis, poor change decisions, and misrouted incidents. Monitoring staleness helps organizations identify where discovery, integrations, or ownership processes are failing.

Duplicate CIs (Option E) occur when the same real-world asset or service is represented by multiple records. Duplicates undermine trust in the CMDB, distort reporting, and break service mappings. The CMDB Health Dashboard highlights duplicate trends and integrates with de-duplication and remediation workflows to address them.

Options A (Downgraded CIs), B (Upgraded CIs), and C (Missing CIs) are not standard CMDB Health Dashboard quality dimensions. While “missing” data may be inferred through completeness checks, Missing CIs as a category is not directly tracked.

Therefore, the correct answers are D – Stale CIs and E – Duplicate CIs, which are core CMDB Health indicators used to maintain high-quality configuration data.

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.

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.

In Data Foundations, “Ingest” is not limited to Discovery. It includes establishing reliable sources and mechanisms to populate and maintain CMDB attributes—especially those that Discovery cannot provide. Warranty expiration dates are a classic example of non-discoverable data: they typically come from procurement systems, asset repositories, vendors, or contract tools rather than from device interrogation.

The correct approach is to maintain these attributes via a scheduled data import from an authoritative external source. This ensures ongoing accuracy and consistency at scale. A scheduled import allows you to define a repeatable integration pattern, apply data quality checks, and keep warranty data current as vendors and procurement records change—without relying on manual updates that inevitably drift over time.

Option A is incorrect because the CMDB Reconciliation Engine resolves conflicts between multiple data sources and applies precedence rules; it does not create the warranty values out of thin air. Reconciliation helps decide which source wins when updates occur, but you still need a source feed providing the warranty attribute values. Option B is also not recommended because creating a new CI class just to hold non-discoverable attributes fragments the model and complicates reporting and processes. Best practice is to keep the attributes on the appropriate hardware CI classes (or related normalized structures, when applicable) and manage them through governed ingestion from authoritative systems. Therefore, C is the best method.

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.

When organizations transition from legacy CMDB status fields (such as custom install status or operational status values) to CSDM-aligned lifecycle status fields, the goal is to map old values to standardized lifecycle stages without disrupting existing processes. In ServiceNow, this is achieved through the Life Cycle Mapping table.

The Life Cycle Mapping table is specifically designed to translate legacy or custom status values into CSDM lifecycle stages and statuses. This allows organizations to preserve historical data and integrations while progressively adopting CSDM standards. By modifying this table, administrators can define how existing status values correspond to CSDM lifecycle stages such as Plan, Build, Deploy, Operate, and Retire .

The Life Cycle Stages table (Option A) defines the standard stages themselves and should not be modified, as these are core to CSDM governance. Life Cycle Stage Status (Option C) defines valid statuses within a stage and is also part of the standardized model. Life Cycle Controls (Option D) enforce governance rules but do not perform value translation.

Therefore, to safely transition from legacy status fields to CSDM lifecycle statuses, the correct and supported approach is to modify the Life Cycle Mapping table, making Option B the correct answer.