CIS Data Foundations / CSDM - ServiceNow Practice Test 2026

Correct Answer

C. 5

Source

ServiceNow Zurich Docs - IRE Duplicate Handling

If the link fails, search Google for: ServiceNow Zurich IRE duplicate threshold default value

Expert Explanation

The Identification and Reconciliation Engine (IRE) handles situations where multiple CIs in the CMDB match the same identification criteria. When this happens, the IRE updates the oldest duplicate CI with the incoming data. However, if the number of duplicates exceeds the default threshold of 5, the IRE stops updating duplicates and creates a brand-new CI instead.

This threshold exists because a high number of duplicates suggests a systemic problem with identification rules or data sources. Continuing to update one of many duplicates could propagate bad data. The threshold value is stored in the glide.identification_engine.duplicate_threshold system property and can be adjusted, but 5 is the out-of-box default.

Why the Others Are Wrong

• A. 2 - Too low. This would trigger new CI creation after just 2 duplicates, flooding the CMDB with unnecessary records and undermining the deduplication process.
• B. 3 - Not the default. ServiceNow intentionally set a higher tolerance to avoid premature CI creation while still catching problematic duplication patterns.
• D. 10 - Too high. Allowing 10 duplicates before taking corrective action would let data quality issues persist far too long, risking stale or incorrect CI updates.

Memory Tip

Think "High Five for Duplicates" - the IRE gives your CMDB a high five (5 chances) before it says "enough duplicates, I am making a new one."

Real-World Example

A CMDB Administrator notices that a Discovery pattern for Linux servers is creating duplicate CIs because the serial number field is sometimes blank. The IRE finds 3 CIs matching the same hostname rule. Since 3 is below the threshold of 5, the IRE updates the oldest duplicate. After a misconfigured data source pushes the count to 6, the IRE stops updating and creates a new CI, signaling to the admin that something needs investigation.

Correct Answer

D. Foundational Metric Results, Priorities, and Remediation Playbook URLs

Source

ServiceNow Zurich Docs - CMDB Data Foundations Dashboard

If the link fails, search Google for: ServiceNow Zurich CMDB CSDM Data Foundations Dashboard components

Expert Explanation

The CMDB and CSDM Data Foundations Dashboards are purpose-built to monitor and improve CMDB data quality. They display three distinct components that work together as a continuous improvement loop:

• Foundational Metric Results - These are scored measurements of your CMDB health, such as the percentage of CIs that have a valid relationship, the percentage of Business Services mapped in CSDM, or how many CIs have a populated Managed by group. Each metric produces a pass/fail or percentage score.
• Priorities - The dashboard ranks which failing metrics should be fixed first based on impact. This helps CMDB managers focus their limited time on the issues that will improve overall CMDB health the most.
• Remediation Playbook URLs - Each metric links to a Knowledge Base article (playbook) that provides step-by-step guidance on how to fix the specific data quality issue. These playbooks turn metric failures into actionable remediation steps.

Why the Others Are Wrong

• A. Incident, Change, and Problem Management - These are ITSM process modules. They rely on CMDB data but are not displayed as components of the Data Foundations Dashboards.
• B. CIs, Relationships, and Business Services - These are the CMDB objects being measured by the dashboard, not the dashboard components themselves. The dashboard reports on the quality of these objects through metrics.
• C. Knowledge Articles, Service Catalog Items, and Catalog Categories - These belong to entirely different ServiceNow applications (Knowledge Management and Service Catalog) and have no role in the Data Foundations Dashboards.

Memory Tip

Think "MPR - Measure, Prioritize, Remediate". The dashboard shows your Metric results (M), tells you what to fix first with Priorities (P), and gives you Remediation playbook links (R) to actually fix it.

Real-World Example

A CMDB Manager at a financial services company opens the Data Foundations Dashboard and sees the metric "CIs with valid Managed by group" scoring at 42%. The Priorities section flags this as the top issue because 1,200 Windows servers lack ownership. She clicks the Remediation Playbook URL, which opens a Knowledge Base article explaining how to use CI Class Manager to bulk-assign the Managed by group for the Windows Server class. Within a week, the metric improves to 89%.

Correct Answer

C. If the current CI's identifier entry fails to find a match, the IRE attempts matching using the criteria defined in the parent class's identification rules.

Source

ServiceNow Zurich Docs - Identification and Reconciliation Rules

If the link fails, search Google for: ServiceNow Zurich identification rule allow fallback parent rules

Expert Explanation

The "Allow fallback to parent's rules" option on an identification rule entry creates a hierarchical matching strategy. When the IRE processes an incoming CI:

1. Step 1: The IRE tries to match using the child class identification rule (the specific class the CI belongs to, such as Linux Server).
2. Step 2: If no match is found and fallback is enabled, the IRE moves up the class hierarchy and tries matching using the parent class identification rule (such as Server or Computer).

This is valuable because child classes often have more specific identification criteria (like a unique hardware attribute), while parent classes may use broader criteria (like hostname plus IP address). Enabling fallback ensures the IRE exhausts all matching possibilities before creating a duplicate CI.

Without this option, a failed match at the child class level would immediately result in a new CI being created, even if the parent class rules could have identified an existing match.

Why the Others Are Wrong

• A. Allows null attribute values - Null handling in identification rules is managed through separate settings like "Enforce exact count" or by marking attributes as optional. The fallback option does not control null value behavior.
• B. Uses parent's reconciliation rule priority - Reconciliation and identification are distinct processes. Reconciliation rules resolve conflicting attribute values between data sources. The fallback option only affects the identification (matching) phase.
• D. Prevents CI reclassification - Reclassification is controlled by its own settings in the IRE. It determines whether a CI can change class based on new data. The fallback option is strictly about expanding the search for matching CIs up the class hierarchy.

Memory Tip

Think of it like asking your parent for help. The child tries to solve the problem (find a match) on their own first. If they fail, they "fall back" to their parent for help using the parent's approach. Just like real life - child tries first, parent is the backup.

Real-World Example

A Discovery scan finds a new ESXi host and tries to match it using the VMware ESXi Server identification rule, which uses the BIOS UUID. The BIOS UUID field is missing from the scan data, so no match is found. Because "Allow fallback to parent's rules" is enabled, the IRE falls back to the Server class identification rule, which uses serial number plus hostname. It finds an existing CI with the same serial number and hostname, preventing a duplicate. Without fallback enabled, the IRE would have created a second CI for the same physical server.

Correct Answer

E. IRE Data Source Rule

Source

ServiceNow Zurich - IRE Data Source Rules

If the link fails, search Google for: ServiceNow Zurich IRE Data Source Rule prevent insert CMDB

Expert Explanation

The Identification and Reconciliation Engine (IRE) processes all incoming data headed for the CMDB. Within the IRE framework, Data Source Rules serve as the access control layer that determines what each data source is permitted to do.

An IRE Data Source Rule can be configured to:

• Block inserts from a specific data source (preventing new CI creation)
• Allow updates from the same source (so existing CIs still get refreshed)
• Block both inserts and updates (completely locking out a data source)

This is critical for CMDB data quality. Without Data Source Rules, any integration feeding the IRE could create unwanted CIs - leading to duplicates, junk records, and inflated CI counts. By configuring these rules, CMDB Administrators maintain control over which sources can introduce new records.

Why the Others Are Wrong

• A. Identification Rule - These rules define the matching criteria (like serial number + class) used to determine if an incoming record matches an existing CI. They answer "Is this CI already in the CMDB-" - not "Should this source be allowed to insert-"
• B. Reconciliation Rule - These set data source priority for attribute-level conflicts. If Discovery says the OS is "Windows 2022" and SCCM says "Windows 2019," the reconciliation rule decides which value wins. They do not control insert permissions.
• C. Dynamic Reconciliation Rule - An extension of reconciliation that adds conditional logic. Still focused on attribute-level data priority, not source-level access control for inserts.
• D. Data Refresh Rule - These rules define how often CI data should be refreshed and when records become stale. They deal with data freshness, not insert prevention.

Memory Tip

Think of IRE Data Source Rules as the bouncer at the CMDB door. The bouncer checks your ID (data source) and decides: "You can come in (insert)," "You can update your info but can't bring new people (update only)," or "You're not welcome at all (blocked)."

Real-World Example

A CMDB Manager at a financial services company discovers that an old Altiris integration is inserting 200+ duplicate server CIs per week. Rather than disabling the entire integration (which still provides useful attribute updates for existing servers), she creates an IRE Data Source Rule for the Altiris data source that blocks inserts but allows updates. The duplicate CI creation stops immediately, while the 1,500 existing server CIs continue receiving attribute refreshes from Altiris.

Correct Answer

C. It opens a Knowledge Base article explaining "What is this-", "Why it matters-", and "How to fix it-"

Source

ServiceNow Zurich - CMDB Data Foundations Dashboard

If the link fails, search Google for: ServiceNow Zurich CMDB Data Foundations Dashboard remediation playbook knowledge base

Expert Explanation

The CMDB Data Foundations Dashboard presents a series of health metrics - each with a score, a trend indicator, and a Remediation Playbook URL. When an administrator clicks the Remediation Playbook URL for any metric (like "CIs with Relationships"), it opens a Knowledge Base (KB) article specific to that metric.

Each Remediation Playbook KB article follows a consistent three-section structure:

• What is this- - Defines the metric, what it measures, and how the score is calculated
• Why it matters- - Explains the business impact of a low score and the risks of not addressing it
• How to fix it- - Provides step-by-step guidance, best practices, and recommended actions to improve the score

These playbooks are instructional guides, not automated remediation tools. They empower CMDB administrators with knowledge and direction, but the actual remediation work must be performed manually or through separate tools and processes.

Why the Others Are Wrong

• A. Opens the Duplicate CI Remediator - The Duplicate CI Remediator is a standalone tool accessed through the CMDB workspace or application navigator. It is designed for merging duplicate CIs and has nothing to do with the "CIs with Relationships" metric. Remediation Playbook URLs always link to KB articles, never to specific tools.
• B. Triggers a background script to auto-generate relationships - This is a dangerous misconception. The platform does not auto-generate relationships from a dashboard click. Creating meaningful CI relationships requires understanding the actual infrastructure topology, which is done through Discovery, Service Mapping, or manual entry - not background scripts.
• D. Opens the Get Well scheduled job - The Get Well scheduled job collects and calculates health scores. It is not triggered by the Remediation Playbook URL. Re-running this job would recalculate the score with current data, but it would not remediate the underlying issue of missing relationships.

Memory Tip

Think of Remediation Playbooks as a doctor's advice sheet: when you get a bad test result (low score), the doctor gives you a pamphlet explaining What the condition is, Why it matters, and How to treat it. The pamphlet does not perform surgery - it tells you what to do. Same with playbooks: they teach, they do not automate.

Real-World Example

A CMDB Administrator named Raj notices that the "CIs with Relationships" score is only 34% on the Data Foundations Dashboard. He clicks the Remediation Playbook URL and reads the KB article. The "What is this-" section explains that this metric tracks the percentage of CIs that have at least one defined relationship (like "Runs on," "Hosted on," or "Depends on"). The "Why it matters-" section warns that without relationships, impact analysis during incidents is blind - a P1 outage on a server with no relationships means the team cannot identify which business services are affected. The "How to fix it-" section recommends running Service Mapping for top-tier application services, enabling relationship discovery in Discovery patterns, and manually adding relationships for the 150 business-critical CIs that currently have none.