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

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.

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 for CMDB and CSDM, a dashboard indicator (like “Services Have Owners Identified”) highlights a data quality condition—in this case, Services missing required ownership information. The playbook-driven remediation model typically follows a practical sequence: first you identify and validate the scope of the issue, then you correct the underlying records so the metric improves and remains sustainable.

The Analyze Data play is used to break down what the dashboard is reporting into actionable detail. It helps determine which Service records are failing the ownership requirement, what ownership fields are missing (for example, service owner / business owner / technical owner depending on configuration), and where the gaps are concentrated (by business unit, environment, lifecycle stage, or service portfolio segment). This ensures the remediation effort targets the correct records and avoids inaccurate assignments.

The Fix Data play is used to perform the actual remediation—populating or correcting the owner attributes on the Service records so accountability is clear and operational processes can route approvals, escalations, and service decisions correctly. In CSDM terms, clearly assigned owners enable proper stewardship of Service Portfolio and Service Offerings and improve downstream outcomes such as incident assignment accuracy, change impact analysis, and reporting reliability.

While Govern Data supports preventing recurrence (policies, controls, ownership model, and stewardship routines) and Report Data communicates progress, the two plays directly used to remediate the dashboard issue are Analyze Data and Fix Data.

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

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.

Application Service Mapping is a critical capability in ServiceNow for enabling business-aware Change Management. Its primary value is not in identifying physical shutdown sequences or CI locations, but in translating technical changes into business impact.

When an organization plans a data center move, multiple infrastructure components—servers, databases, network devices—may be affected. On their own, these technical CIs provide little insight into business risk. Application Service Mapping connects these CIs to Application Services and Business Services as defined by the Common Service Data Model (CSDM). This relationship allows Change Managers to see which business services, customers, and processes are impacted by the planned change.

By leveraging service maps, Change Management can answer critical questions such as:

Which customer-facing services may experience downtime?

What revenue-generating or mission-critical services are at risk?

Which stakeholders must be notified or involved in approvals?

Option A is incorrect because service mapping does not determine shutdown order; that is handled by infrastructure planning. Option C focuses on physical location data, which is typically managed through Location CIs and Discovery, not service mapping.

Therefore, the correct answer is B – To understand the business impact of CIs, which aligns directly with ITIL 4, CSDM, and Change Management best practices.

Duplicate identifies data quality issues where the same asset is modeled more than once, violating CMDB trust principles.

Required ensures minimum viable CI creation and update—critical for ingestion and lifecycle integrity.

Orphan highlights broken relationships, which directly impact impact analysis, Service Mapping, and Change Management.

Stale flags CIs that are no longer being refreshed by Discovery or other sources but still exist in the CMDB.

Recommended improves completeness and usability, supporting operational and reporting use cases without being mandatory.

Audit validates data correctness by comparing CI field values against predefined templates or policies.

This exact mapping is what ServiceNow expects in CMDB Health Dashboard–related exam questions and real-world implementations.

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.

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.

Principal Classes are a key CMDB configuration concept used to control which CI classes are selectable in reference fields across ITSM processes. This helps reduce noise, prevent incorrect CI selection, and improve data quality.

In ServiceNow, Principal Classes are designated within the CI Class Manager. This tool allows CMDB administrators to manage the CI class hierarchy, define ownership, and explicitly mark classes as principal. Once a class is marked as principal, its CIs become available in CI reference fields such as those on Incident, Change, and Problem forms.

Option A (CMDB Workspace) provides operational and analytical views but does not control schema-level class behavior. Option C (System Properties) does not manage class designation. Option D (CMDB Data Manager) governs lifecycle and data quality policies, not reference field behavior.

By configuring Principal Classes in the CI Class Manager, organizations ensure that only relevant, high-value CI classes are exposed to end users, aligning with Data Foundations best practices.

Therefore, the correct answer is B – CI Class Manager.

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

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

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

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

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

Agent Client Collector

Automated agent-based solution running patterns

Import Sets

Organization-built solution using transform maps

Service Graph Connector

Pre-built store integration solutions that require minimal customization

ServiceNow Discovery

Automated agentless solution running patterns

Agent Client Collector: This is ServiceNow ' s agent-based approach. It requires a software agent to be installed on the target host to run discovery patterns locally.

Import Sets: This is the traditional, manual way to bring in data. You define the source, and the organization builds the logic (Transform Maps) to move that data into the CMDB.

Service Graph Connector: These are found in the ServiceNow Store. They are " certified " integrations built to work with specific third-party vendors (like SCCM or Jamf) with minimal setup.

ServiceNow Discovery: The classic agentless method. It probes the network and uses patterns to identify and map CIs without needing software installed on every machine.

In ServiceNow, the Compliance dimension of the CMDB Health Dashboard is driven by Data Certification. To surface meaningful compliance results—such as identifying servers that are not on the latest patch—the platform requires a combination of Certification Policies, Data Filters, and Scheduled Jobs.

Certification Policies define what data must be validated and which attributes are subject to compliance checks (for example, patch level, OS version, or last update date). Data Filters scope the population—such as server classes only—ensuring the compliance evaluation targets the correct CIs. Scheduled Jobs automate when certifications run, keeping compliance scores current and reflective of the latest state.

Options A and C are incorrect because audits and stale/orphan/duplicate checks relate to other health dimensions (correctness and completeness), not compliance. Option B focuses on service modeling and group alignment, which does not directly drive compliance scoring for patch currency.

Therefore, configuring Certification Policies, Data Filters, and Scheduled Jobs is required to accurately measure and display patch compliance on the CMDB Health Dashboard.

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

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 ServiceNow, Dynamic CI Groups are a core Data Foundations capability used to automatically manage CI membership based on rules rather than manual maintenance. When Technology Management Service Offerings (Technical Service Offerings) are related to Dynamic CI Groups, ServiceNow uses those relationships to synchronize operational support attributes to the member CIs.

The two CI attributes that are intentionally designed to sync in this model are the Managed by Group and the Support Group. These groups directly influence operational ownership and support routing, which is why they are automatically aligned when Dynamic CI Groups are used. This ensures that incidents, changes, problems, and operational tasks are routed consistently as CI membership changes over time.

The Support Group defines who provides day-to-day operational support and is critical for Incident and Request Management workflows. The Managed by Group represents the team responsible for the technical lifecycle and operational health of the CI. Synchronizing these attributes eliminates manual updates and reduces misrouted tickets, which is a key goal of Configuration Management maturity.

The Approval Group (Option A) is not synced because approvals are process-driven and often context-specific rather than CI-driven. Similarly, the Owned by Group (Option C) represents accountability or financial ownership, which is intentionally decoupled from dynamic operational grouping to avoid unintended governance changes.

Therefore, the correct answers are B (Managed by Group) and D (Support Group).

The Identification and Reconciliation Engine (IRE) is a core platform capability in ServiceNow and does not require CMDB 360 / Multisource CMDB to function. Even without the ITOM Discovery license, organizations can still define and use IRE reconciliation rules across multiple data sources.

IRE rules are source-aware and can evaluate attributes based on source precedence, regardless of whether CMDB 360 is enabled. CMDB 360 enhances visibility, governance, and monitoring of multiple sources, but it is not a prerequisite for reconciliation logic itself.

Option A is incorrect because purchasing ITOM Discovery is not mandatory to use multisource reconciliation. Option C is also incorrect because CMDB 360 / Multisource CMDB is a licensed add-on, not a universally available platform feature.

Therefore, the Data Owner can proceed by configuring IRE reconciliation rules directly, making Option B the correct answer.

In Data Foundations, “Govern” is about putting repeatable, controlled mechanisms in place to keep CMDB data healthy over time. Duplicate CI cleanup is a governance activity because duplicates degrade trust, break reporting, create incorrect service impacts, and cause operational confusion (for example, incidents linked to the wrong CI). The preferred approach is to use the guided and purpose-built de-duplication experience designed for CMDB administrators rather than relying on generic task lists or ad-hoc work.

The de-duplication dashboard in CMDB Workspace is the preferred place because it centralizes duplicate identification, prioritization, and remediation in a single operational experience. It typically provides visibility into suspected duplicates, helps users review records side-by-side, and supports controlled actions (such as merge/retire workflows, depending on configuration) while maintaining auditability. This aligns with Data Foundations’ emphasis on standard processes and consistent remediation patterns rather than one-off manual fixes.

“My Tasks” is a generic work queue and does not provide the purpose-built context or tooling required to confidently resolve duplicates in a safe, repeatable way. A standalone “de-duplication task module” may exist as a navigation entry, but the recommended operational method is to use the workspace dashboard where duplicate remediation is organized and guided as part of CMDB health and governance. Therefore, the correct answer is the de-duplication dashboard on CMDB Workspace.

In a healthcare environment, identifying who is impacted during a critical incident is essential to patient safety and continuity of care. Within the Common Service Data Model (CSDM), the most effective way to determine impacted users is through Service Offerings, particularly when they are defined by department or location.

Service Offerings represent how a service is consumed by specific user groups. In this case, a patient management system may have different offerings for departments such as Emergency, Inpatient Care, or Outpatient Services, or be scoped by hospital location. These offerings explicitly define consumer context, allowing incident responders to immediately identify which clinicians, staff, or facilities are affected.

Option D (Affected CI related list) identifies technical impact but does not translate that impact into user or consumer context. Option A provides historical insight but does not identify current impacted users. Option C (service environment) helps differentiate production vs non-production but does not identify who is impacted.

By leveraging Service Offerings by Department or Location, the provider can quickly notify the right users, prioritize response based on clinical impact, and coordinate mitigation effectively—aligning with CSDM and ITIL best practices.

Therefore, the correct answer is B – Service Offerings by Department or Location.

In the CSDM Walk stage, an organization has moved beyond basic data hygiene (Crawl) and has established foundational service models, especially Business Services and their relationships to underlying technical components. One of the most important and immediate benefits of reaching this stage is the ability to perform reliable impact analysis across ITSM processes.

When Business Services are correctly defined and related to Application Services, applications, and infrastructure CIs, the CMDB becomes a decision-support system rather than just a data repository. This enables impact assessments for Incident, Problem, and Change Management, which is exactly what Option C describes. For example, when an incident is logged against a CI, ServiceNow can automatically determine which Business Services are impacted and who the affected stakeholders are. Similarly, during Change Management, planners can assess downstream risk by identifying which business-facing services could be disrupted.

Option A is more aligned with advanced operational governance and support model optimization, which typically appears later as organizations mature toward the Run stage. Option B relates to Application Portfolio Management (APM) acceleration, which benefits more from accurate application ownership and lifecycle data rather than core Walk-stage service modeling.

Therefore, the correct and CSDM-aligned benefit at the Walk stage is enabling impact assessments for incident, problem, and change on Business Services, making Option C the verified answer.

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

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

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

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

Therefore, Option D – Attestation is the correct answer.

In CSDM, Technology Services (and their Service Offerings) represent how technical capabilities are delivered and consumed by internal teams. When a server team requests a catalog item for infrastructure services (e.g., VM provisioning, storage, OS builds), the role responsible for initiating the request and defining requirements is the Technology Service Owner.

Technology Service Owners understand the operational capabilities, constraints, SLAs, and fulfillment workflows required to deliver infrastructure services. They define catalog requirements such as options, approvals, fulfillment tasks, and guardrails—ensuring the request aligns with standardization, security, and operational readiness.

Application Service Owners focus on how applications are delivered and supported, not on defining infrastructure catalog items. Enterprise Architects provide standards and guidance but do not initiate or define catalog request requirements.

Thus, the correct role is B – Technology Service Owners.

The CMDB Data Manager capability in ServiceNow is designed to support CMDB governance, specifically around data lifecycle management. Its primary purpose is to ensure that CI records are retained, archived, and deleted in accordance with defined retention policies, regulatory requirements, and organizational data governance standards.

As CMDBs mature, they naturally accumulate obsolete, retired, or decommissioned CIs. If these records are not properly managed, they negatively impact CMDB health, reporting accuracy, discovery reconciliation, and performance. CMDB Data Manager addresses this by automating the archival and deletion of records once lifecycle conditions and retention thresholds are met.

Option A is incorrect because encryption of archived records is handled by platform-level security and data protection features, not CMDB Data Manager. Option B is also incorrect because relationship rule enforcement is managed through CSDM guidance, CMDB relationship rules, and identification/reconciliation logic—not by CMDB Data Manager.

By automating retention-based archival and cleanup, CMDB Data Manager helps organizations maintain a lean, compliant, and high-quality CMDB, which directly supports CMDB Health metrics such as correctness and compliance.

Therefore, the correct and verified answer is Option C.

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.

Within the Common Service Data Model (CSDM), service types are clearly defined to separate business-facing value, application logic, and technical enablement. Correct classification is foundational to impact analysis, ownership, reporting, and service visibility.

An Application Service is a logical representation of a deployed application or system stack. It models how an application runs, including servers, databases, middleware, and integrations. Application Services are typically created and maintained through Service Mapping and are primarily consumed by IT operations, DevOps, and support teams.

A Technology Management Service (also called a Technical Service) represents shared technical capabilities such as databases, authentication platforms, messaging systems, or cloud infrastructure. These services are published to Service Owners, not business users, and underpin one or more Application Services or Business Services. They are critical for understanding technical dependencies and risk but are not business-facing.

A Business Service is published to Business Users and directly supports business capabilities and outcomes. It represents what the business consumes , such as “Online Banking,” “Order Fulfillment,” or “Employee Onboarding.” Business Services sit at the top of the CSDM hierarchy and are the anchor point for SLAs, experience, and value measurement.

Correctly distinguishing these service types ensures alignment with CSDM best practices, enables accurate impact analysis, and prevents common CMDB anti-patterns such as exposing technical services to business users or misrepresenting application stacks as business value.