Free Practice Questions for ServiceNow CIS-DF Exam

This question tests understanding of how theIdentification and Reconciliation Engine (IRE)evaluates incoming CI data againstIdentification Rulesand theirpriority orderinServiceNow.

From the identification rule shown:

Serial number (+ type)→ Priority 100

Serial number→ Priority 200

Name (Hardware)→ Priority 300

MAC address + name (Network Adapter)→ Priority 400

For a CI to beidentified and matched, the incoming record must satisfyone complete identifier entryexactly as defined for that class.

CI1 (Name match only)

Although thenamematches an existing Hardware CI,name aloneis alow-priority identifier (300)and isnot sufficientto uniquely identify a Hardware CI unless no higher-priority identifiers existandthe identifier entry criteria are fully satisfied. In practice, Hardware identification relies onserial number–based identifiers, not name-only matching, to avoid false positives. Therefore, CI1cannot be confidently matchedand is inserted as anew record.

CI2 (IP address match)

IP address is not part of any Hardware identification ruleshown. IP address is typically used for discovery correlation or network relationships, not as a primary Hardware identifier. Since no identifier entry includes IP address, CI2does not match any valid identification ruleand is also inserted as anew record.

Becauseneither CI satisfies a valid identifier entry,both records are inserted as new CIs.

InServiceNow, eachCMDB Health metriccan independently definewhich CIs are in scopefor evaluation. This scoping is controlled primarily throughHealth Inclusion Rules, not CMDB Groups.

In this scenario, theDuplicatemetric evaluates all60,000 Server CIs, indicating no inclusion rule is restricting its scope. In contrast, theOrphanmetric evaluates only50,000 Server CIs, which means10,000 servers are intentionally excludedfrom that metric’s evaluation.

This difference is explained by aHealth Inclusion ruleconfigured specifically for theOrphan metricon 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 theOrphan metric having a Health Inclusion rule configured, makingOption Bthe verified answer.

Within theCommon Service Data Model (CSDM), regulatory, security, and compliance-related information—especially forPII and PCI—must be modeled at thebusiness and information level, not at the infrastructure or service offering level. The correct location for this data isBusiness Applications combined with Information Objects.

Business Applicationsrepresent the logical applications that support business capabilities and processes. Since compliance obligations (such as GDPR, PCI-DSS, or HIPAA) are assessed based on how the business uses data—not how many servers host the application—this is the correct anchor point for audit-relevant context.

Information Objectsare explicitly designed to capturewhat data is processed, stored, or transmittedby an application, including data classifications such as PII, PCI, PHI, or confidential business data. They allow organizations to document regulatory scope, retention rules, encryption requirements, and audit controlswithout overloading CI recordsor polluting infrastructure classes.

Option A is incorrect because Technical Service Offerings and Groups focus on operational support and service delivery, not regulatory data context. Option C is also incorrect because Customer Service Offerings describe how services are consumed, while databases are technical components; neither is the authoritative place for compliance definitions.

Therefore,Business Applications and Information Objectsare the correct CSDM constructs to support audits and regulatory compliance, makingOption Bthe correct answer.

TheCMDB Health Dashboardorganizes data quality into practical, action-oriented metrics:

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

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

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

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

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

Stale CIssignal aging data that no longer reflects the current environment.

This mapping aligns withCMDB Data Foundationsbest practices and how the Health Dashboard is designed to guide prioritization and remediation.

In CSDM,Technology Services(and their Service Offerings) representhow technical capabilities are delivered and consumedby internal teams. When a server team requests a catalog item for infrastructure services (e.g., VM provisioning, storage, OS builds), the role responsible forinitiating the request and defining requirementsis theTechnology 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 Ownersfocus on how applications are delivered and supported, not on defining infrastructure catalog items.Enterprise Architectsprovide standards and guidance but do not initiate or define catalog request requirements.

Thus, the correct role isB – Technology Service Owners.

This scenario hinges on how theIdentification and Reconciliation Engine (IRE)inServiceNowevaluatesidentification rules.

The identification rule for theApache Web Serverclass includesVersionas part of theidentifier criteria, along with Class and Configuration file. Identification rules must matchall criterion attributes exactlyfor 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, theVersion attribute changes. Because Version is part of the identifier, the incoming recordno longer matchesthe existing CI’s identifier entry. As a result, the IREcannot identify the existing CIas the same configuration item.

When identification fails and no matching identifier entry is found, the IRE proceeds toinsert a new CI recordrather 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 occursafter 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 abest practice caution:volatile attributes (such as Version)should generallynot be used as identifier attributes, as they can cause unintended CI duplication during upgrades.

Service Graph Connectorsare a keyData Foundations ingestion capabilityinServiceNow. They provideout-of-the-box, upgrade-safe integrationsthat ingest data into the CMDB using theIdentification and Reconciliation Engine (IRE), ensuring data quality and source governance.

Two primary categories of Service Graph Connectors are:

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

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

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

Therefore, the correct connector categories areCloudandObservability, makingOptions A and Bthe correct answers.

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.

TheCommon Service Data Model (CSDM)prescribes anincremental, maturity-based rollout approachto reduce risk and ensure sustainable adoption. The recommended order isCrawl, Walk, Run, Fly, which aligns implementation effort with increasing organizational capability and value realization.

Crawlfocuses on foundational data hygiene: core CI classes, identification rules, reconciliation, basic Discovery ingestion, and CMDB Health basics.

Walkintroduces service context, includingBusiness Services, Application Services, and relationships that enable impact analysis for Incident and Change.

Runexpands into operational excellence withService Mapping, service offerings, advanced governance, and process automation.

Flyrepresents optimization and scale, leveraging analytics, AI/ML, proactive operations, and cross-domain integration (e.g., SecOps, APM, CSM).

This progression ensures teams do not over-model early or introduce complexity before data quality and governance are established. The other options describe generic project lifecycles or organizational categorizations, not the CSDM-recommended adoption path.

Therefore, the correct answer isD – Crawl, Walk, Run, Fly.

Automatic relationship creation is fundamental to maintaining aservice-aware and trustworthy CMDB. InServiceNow, this capability is primarily delivered byDiscoveryandService Mapping.

Discovery(Option C) automatically identifies infrastructure components—such as servers, network devices, and storage—and createstechnical relationshipsbetween 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 creatingapplication- and service-level relationships. It maps how application components interact across servers, databases, and middleware, resulting in accurateApplication Servicemodels 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 areService MappingandDiscovery, makingOptions B and Ccorrect.