› CIS-DF Hub › Part 8 › Instance & Data Health
⬡ Part 8 · Topic 4

Instance & Data Health

Instance health goes beyond CMDB data quality — it encompasses platform performance, customization hygiene, upgrade readiness, and overall instance governance. Understanding how to monitor and maintain a healthy ServiceNow instance is the capstone of the CIS-DF curriculum.

📋 5 sections ⏱ ~18 min read 🎯 ~6% exam weight 🏷 Instance Health · Governance
Section 1

Instance Health Scan

The Instance Health application is ServiceNow's built-in tool for analyzing your instance's configuration, customizations, and usage patterns against best practices. It runs a set of automated scans and produces a health score for different categories.

Navigate to: All → Instance Health (or Health → Instance Health). It provides scores across:

  • Security — are there overprivileged users, public APIs, weak ACLs?
  • Performance — slow Business Rules, inefficient queries, large tables without archiving?
  • Upgrade — customizations that will conflict with the next ServiceNow release?
  • Ownership — applications and customizations without designated owners?
📘
Core Concept — Preventive Maintenance Instance Health Scan is like a car inspection — you don't wait for a breakdown to check fluid levels. Running regular Instance Health scans surfaces issues before they become outages or security incidents. Organizations that run these scans quarterly have fewer upgrade conflicts and better performance.
Section 2

Upgrade Readiness and Customization Hygiene

ServiceNow releases major platform upgrades (e.g., Washington DC, Xanadu, Yokohama) twice a year. Customizations that modify out-of-box (OOB) records — Business Rules, UI Policies, Scripts on base tables — can conflict with these upgrades.

The Upgrade Monitor identifies:

  • Customized OOB records — any base ServiceNow record that has been modified. During upgrade, these may be overwritten or flagged as "Skipped."
  • Deprecated APIs — scripts using functions that are being removed in the new release
  • Missing validations — new security features that require opt-in configuration
⚠
Exam Trap — Customizing OOB = Upgrade Risk Every customization to an out-of-box record creates upgrade risk. Best practice is to extend rather than modify: create a new Business Rule instead of editing the OOB one; use a Dictionary Override instead of modifying the parent field definition. Customizations in customer-owned scope (u_ prefix, private scope) don't conflict with OOB upgrades.
Section 3

Table Growth and Database Monitoring

Large tables degrade query performance and increase storage costs. ServiceNow provides tools to monitor table growth and take action:

ToolPurpose
sys_db_object statisticsRow count and storage size for each table — useful for identifying tables that need archiving
Stats page (sys.stats.do)Instance-level statistics including database size, node count, memory usage
Instance Health scanFlags tables without archiving rules that have grown beyond recommended thresholds
Archive RulesThe action to take — configure archive rules on identified large tables (covered in P6T3)
Section 4

Data Governance Summary

The CIS-DF certification covers data governance across the full platform. As a capstone, here is how all the governance mechanisms fit together:

  • Import Controls — Data Policies, Dictionary Overrides, IRE Reconciliation Rules prevent bad data entering
  • Quality Monitoring — CMDB Health scoring, Data Certification detect quality issues
  • Lifecycle Management — CMDB Data Manager, Archive Rules, Purge Rules remove stale/old data
  • Security — Field-level ACLs, Reference Qualifiers, Data Policies enforce access and integrity
  • Integration Safety — Service Graph Connectors, CMDB Identification API ensure external data routes through IRE
  • Instance Health — Platform-level scans ensure the infrastructure supporting all of the above is healthy
💡
Tip — Exam Scenario Matching CIS-DF exam questions typically describe a scenario and ask which tool/feature to use. Map scenarios: "data quality" → CMDB Health; "duplicate CIs" → IRE; "stale CIs" → CMDB Data Manager; "old records slowing lists" → Archive Rules; "field values from wrong source" → Reconciliation Rules; "upgrade conflicts" → Upgrade Monitor; "external system bypassing IRE" → SGC or CMDB Identification API.
Section 5

CIS-DF Exam Preparation Summary

You've now covered all 24 topic areas of the CIS-DF curriculum. The highest-weight areas to focus on in final review:

  1. IRE — Identification Rules, Identification Entries, Reconciliation Rules, what bypasses IRE
  2. CMDB Health — scoring dimensions, inclusion rules, Workspace tabs
  3. Import Pipeline — Import Sets, Transform Maps, coalesce, Service Graph Connectors
  4. Data Policies vs. UI Policies — enforcement scope differences
  5. Asset vs. CI — what each tracks, Discovery only updates CIs, reconciliation scenarios
  6. Lifecycle states — lifecycle_stage vs. lifecycle_stage_status vs. operational_status
  7. CMDB Data Manager — Retire vs. Archive vs. Delete
  8. Dependency View / Unified Map — cmdb_rel_ci, upstream/downstream, impact analysis
Exam Quick Reference

Final Exam Traps — Instance & Data Health

  • Instance Health scan ≠ CMDB Health scan — Instance Health is about platform configuration; CMDB Health is about CI data quality
  • Customizing OOB records = upgrade risk; extend or scope instead
  • u_ prefix fields and private-scope customizations don't conflict with OOB upgrades
  • Archive Rules → any table; CMDB Data Manager → CI tables only
  • Scenario "data doesn't update correctly from import" → likely missing Reconciliation Rule (last writer wins)
  • Scenario "duplicate CIs created by import" → import bypasses IRE; use SGC or CMDB Identification API
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Instance & Data Health Quiz 1 / 4

An organization runs an Instance Health scan and finds several issues. One issue states "Out-of-box Business Rule 'Before Update on Incident' has been modified." Why is this flagged as a problem?

💡 Explanation

B is correct. Instance Health flags OOB record modifications because they create upgrade risk. When ServiceNow releases an upgrade, it may update OOB records to fix bugs or add features. If the OOB record was modified (customized in-place), the upgrade may overwrite those customizations, silently breaking the custom logic. Best practice: never modify OOB records directly. Instead, deactivate the OOB record and create a new custom record with your logic, or use scoped application customizations (u_ prefix fields, private scope) that ServiceNow won't overwrite during upgrades.

An Import Set integration loads server data from an external CMDB into ServiceNow. Every time the import runs, it overwrites the support_group field on CIs, even though Discovery should be the authority for this field. What is the root cause?

💡 Explanation

B is correct. Without a Reconciliation Rule for the support_group field, IRE applies last-write-wins logic — whichever source most recently wrote to the field wins. If the Import Set runs after Discovery, it overwrites Discovery's correct value. The fix: create a Reconciliation Rule specifying Discovery (or the appropriate authoritative source) as having the highest priority for support_group. With a properly configured Reconciliation Rule, IRE will protect Discovery's value from being overwritten by lower-priority sources like Import Sets, regardless of execution order.

What is the key difference between Instance Health and CMDB Health in ServiceNow?

💡 Explanation

B is correct. These are completely separate diagnostic tools with different scopes. Instance Health scans the ServiceNow platform configuration: are OOB records modified (upgrade risk)? Are security settings correctly configured? Are there performance anti-patterns? Is the instance ready for upgrade? It's a platform health tool. CMDB Health evaluates the quality of CI data: are required fields populated (Completeness)? Are values accurate (Correctness)? Is data current (Staleness)? Are there duplicates? It's a data quality tool. A healthy instance can have poor CMDB data, and excellent CMDB data can exist on a poorly configured instance.

A developer creates a custom field on the Incident table named "resolution_code" using the standard UI. The upgrade to the next ServiceNow version adds a new OOB field also named "resolution_code" to Incident. What happens?

💡 Explanation

C is correct. Custom fields in ServiceNow should always use the u_ prefix (e.g., u_resolution_code). The u_ prefix is reserved for customer customizations and ServiceNow guarantees it will never use u_ prefixed names for OOB fields. This guarantees custom fields never conflict with OOB fields added in future upgrades. Without the u_ prefix, a custom field named "resolution_code" could conflict with an OOB field of the same name introduced in any future release. Instance Health scans flag custom fields without u_ prefix as an upgrade readiness issue for exactly this reason.

Score: 0 / 4
← Back to CIS-DF Hub