Which are business values of CMDB? (Choose two.)
Answer : C, D
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.
(Choose 2 options)
The following Reconciliation Rules were configured for ServiceNow, Altiris, and SCCM for the Windows Server (cmdb_ci_win_server) class:

Which statements are true?
Answer : A, C
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.
A CMDB Administrator is reviewing the health of the CMDB and notices a large percentage of the Hardware CIs are missing serial numbers. The Administrator is concerned this may cause duplicate CIs and would like to resolve the issue in a timely manner.
What structured guidelines provided by ServiceNow are available to troubleshoot and resolve the issue?
Answer : C
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.
What ensures data volume in the CMDB is manageable?
Answer : C
Managing CMDB data volume is a key Data Foundations governance objective. Over time, CMDBs naturally accumulate retired, obsolete, or decommissioned CIs. If these records are not properly managed, they degrade CMDB performance, reduce reporting accuracy, and negatively impact discovery reconciliation and health scores.
Archive Policies are the mechanism designed to address this challenge. They define when CI records should be archived or deleted based on lifecycle state, age, or retention requirements. By automating archival and cleanup, archive policies ensure that only relevant, active CIs remain in the operational CMDB, keeping data volume manageable and performant.
Business Rules (Option A) are used to enforce logic during record creation or updates, not for long-term data volume control. Scheduled Jobs (Option B) may execute tasks, but without archive policies they have no governance logic to determine what should be removed or retained.
Archive policies work in conjunction with CMDB Data Manager to enforce lifecycle-based retention and cleanup, making them the correct and verified answer.
Therefore, Option C -- Archive Policies is correct.
(Choose 2 options)
A CMDB Administrator needs to create a new CI class for an Internet of Things (IoT) Sensor in ServiceNow.
What are the recommended practices for this activity?
Answer : B, C
Creating new CI classes is a high-impact configuration activity and must follow strict Data Foundations and CSDM-aligned best practices to avoid long-term technical debt and upgrade risk.
Option B is a recommended first step. Before creating any new CI class, administrators should install or update the CMDB CI Class Models Store application and verify whether an appropriate class already exists. ServiceNow frequently delivers new CI classes through updates and class model packages, and duplicating an existing or planned class can lead to fragmentation and governance issues.
Option C is also correct. When a new class is truly required, it should be added under an appropriate parent class to inherit attributes, behaviors, and discovery patterns. For an IoT Sensor, this might be under a hardware or device-related parent class, ensuring consistency and minimizing customization.
Option A is incorrect and dangerous---deleting unused classes can break dependencies and historical data. Option D is also discouraged; modifying existing classes to repurpose them violates upgrade-safe design principles and can negatively impact discovery, integrations, and reporting.
By verifying existing models first and extending the class hierarchy correctly, organizations maintain a clean, scalable, and upgrade-safe CMDB.
Therefore, the correct answers are B and C.
A CMDB Administrator wants to improve data quality related to the CSDM.
Which action should the Administrator take to meet this goal?
Answer : A
To specifically improve data quality related to CSDM, the most effective and prescribed action is to use the CSDM Data Foundations Dashboard. In ServiceNow, this dashboard is purpose-built to assess and improve CSDM alignment, not just general CMDB hygiene.
The CSDM Data Foundations Dashboard focuses on service modeling readiness, highlighting gaps such as missing service ownership, incomplete relationships between Business Applications and Application Services, unmanaged services, and misaligned lifecycle states. It provides Get Well Playbooks that guide administrators through structured remediation using Analyze Data, Fix Data, and Govern Data plays---directly tied to CSDM outcomes.
Option C (default CMDB Health Dashboard) is valuable, but it measures generic CMDB data quality dimensions (completeness, correctness, compliance) and does not specifically evaluate CSDM constructs or service modeling maturity. Option B (ServiceNow Health Scan) provides platform-wide configuration and performance recommendations, but it is not focused on CMDB or CSDM data quality.
Therefore, to improve CSDM-specific data quality, the administrator should use the CSDM Data Foundations Dashboard, making Option A the correct answer.
A Configuration Management Governance team is transitioning from utilizing legacy CMDB status fields to CSDM lifecycle status fields.
Which table can be modified?
Answer : B
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.