Free Practice Questions for ServiceNow CIS-DF Exam

Business Application records represent logical applications from a portfolio, ownership, investment, risk, and lifecycle perspective. They are principally used by Application Portfolio Management and Enterprise Architecture to support application rationalization .

Rationalization enables an organization to evaluate applications based on factors such as business value, technical fitness, cost, risk, lifecycle status, capability alignment, and functional redundancy. Decision-makers can then determine whether an application should be invested in, tolerated, migrated, consolidated, replaced, or retired.

Application availability is normally monitored through operational Application Services and their supporting infrastructure rather than through the logical Business Application record. Change impact analysis also relies mainly on Application Services, service maps, and relationships to affected infrastructure CIs.

Because Business Applications belong to the Design and Planning context and provide strategic portfolio information, application rationalization is the appropriate business-decision use case

Bottom of Form

The Management tab provides the direct administrative path to CMDB Data Manager. Under Management tools, the administrator can open Data Manager to create, edit, review, publish, and track lifecycle policies. ServiceNow’s documented procedure for creating a policy begins by selecting CMDB Workspace > Management > Data Manager > Policies .

The Home tab also provides access through its Quick Links section. The Data Manager quick link opens the same policy-management capability and allows authorized administrators to create, review, publish, and monitor policies.

The My Work tab is used primarily to review and process tasks generated after policies run; it is not the policy-configuration entry point. CMDB 360 is used for multisource data visibility, while Insights focuses on analytical and adoption information. Therefore, the two tabs providing access are Management and Home.

=========

CMDB 360, also known as Multisource CMDB , provides attribute-level visibility into the data contributed by different discovery and integration sources. It enables an administrator to examine which source supplied a particular attribute, compare competing values, identify missing source contributions, and understand how reconciliation selected the final value stored on the CI.

The guide explains that CMDB 360 reveals gaps in attribute data and differing attribute values across sources. These insights help administrators diagnose reconciliation conflicts, inappropriate source precedence, incomplete integrations, and inconsistent discovery results.

CMDB 360 is not itself the mechanism used to ingest records. Service Graph Connectors, IntegrationHub ETL, Import Sets, and Discovery perform ingestion. CMDB 360 instead preserves and exposes the source- level contributions after ingestion so that data owners can investigate and improve multisource data quality.

=========

The Related items panel displays records associated with the selected CI, including active incidents, problems, changes, and other task-related information. This allows the Service Desk Manager to move from the CI’s topology to the operational records currently affecting or involving that CI.

The Overview panel presents summarized CI information. The Attributes panel displays field values belonging to the CI. The Application services panel identifies service associations and dependencies, but it is not the primary panel for listing related Incident and Problem records.

Unified Map is intended to combine CI details, relationships, service context, and operational information in a single graphical experience. Its filtering capabilities also allow users to focus on relevant CI types and business-critical elements when analysing a service or CI topology.

Therefore, Related items is the panel that provides the required active task information.

=========

In Data Foundations, “Insight” is about using health metrics to understand whether the CMDB is trustworthy and operationally usable. The CMDB Health Dashboard organizes health into scorecards that group related checks. When leadership asks for Duplicate CIs, Orphan CIs, and Stale CIs, they are asking about the CMDB’s ongoing hygiene and adherence to governance expectations—not simply whether fields are filled in.

These three metrics align best with Compliance because they represent whether CI records comply with rules that keep the CMDB clean and current over time:

Duplicate CIs indicate the identification and governance controls are not consistently preventing multiple records for the same real-world item.

Orphan CIs indicate relationship governance gaps—records exist without expected relationships or context, reducing their operational value and often signaling incomplete ingestion or lifecycle control issues.

Stale CIs indicate lifecycle management gaps—records are not being updated, attested, retired, or archived appropriately, which increases risk and noise in operational processes.

By contrast, Completeness focuses on whether required attributes are populated (owners, support group, environment, etc.). Correctness focuses on whether values and relationships are accurate and logically valid. While duplicates/orphans/stale can affect correctness indirectly, the dashboard’s grouping for these hygiene and lifecycle-oriented measures is best represented by Compliance, which is why B is the correct answer.

Data Refresh Rules allow a lower-priority source to update an attribute when the higher-priority authoritative source has not refreshed that attribute within a configured period. This prevents CI data from remaining indefinitely outdated merely because the preferred source has stopped reporting.

Reconciliation rules establish the normal source priority and determine which authorized source wins when multiple sources report values for the same attributes. The guide confirms that source precedence is assigned through reconciliation rules. Data Refresh Rules supplement that precedence by defining a freshness exception: after the higher-priority source becomes inactive for the configured interval, a lower-priority source may supply a more current value.

Identification Rules determine whether an incoming payload matches an existing CI. Health Inclusion Rules control which CIs participate in CMDB Health calculations. Neither addresses temporary source inactivity or freshness-based update authorization.

=========

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

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

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

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

=========

Identification rules are configured through CMDB CI Class Manager . These rules define how the Identification and Reconciliation Engine determines whether an incoming CI already exists or whether a new CI record should be created. For server records, identification rules usually rely on attributes such as serial number, name, hostname, hardware identifiers, or other class-specific criteria. If these rules are weak or missing, duplicate server records can be created during Discovery, Service Graph Connector imports, or other integrations. The CMDB Health Dashboard detects health issues such as duplicates, but it is not where identification rules are configured. CMDB Workspace provides operational access to CMDB capabilities, but CI Class Manager is the correct configuration location. CMDB Data Manager governs lifecycle policies, not IRE identification logic. Therefore, the correct answer is B.

=========

In Data Foundations, a low “Unique Locations” result indicates the CMDB contains duplicate Location records (or inconsistent location usage) that reduce data reliability for operational reporting and service analytics. This sits under “Insight” because the dashboard is highlighting a measurable quality issue, and the playbook provides a structured remediation path to restore confidence.

The recommended playbook-aligned process is to review the duplicate locations, determine which one is correct per the organization’s naming and data standards, then re-point dependent records (CIs) to the correct Location before removing the duplicate. That sequence is essential: if you delete a duplicate location without first updating related CIs, you risk leaving CIs with missing/invalid location references, creating new completeness and correctness issues.

Option C matches best practice: validate which location record should remain, update all affected CIs (and any other dependent records) to use the correct location, and then delete (or retire/merge, depending on process controls) the duplicate record. Option B is risky because it skips validation and dependency updates. Option D defeats the purpose of “Unique Locations” by allowing ongoing inconsistency. Option A is not the best fit because “Duplicate CI Remediator” is oriented toward CI duplicates; Location is typically a reference/organization data domain and is handled through the specific remediation steps for that data set. Therefore, C is the recommended process.