Your enterprise customer has a 5-year-old ServiceNow instance with a CMDB that no teams trust or use.

Why This Matters in an Interview

In a production CMDB with trust issues, symptoms like poor health scores mask root causes: uncontrolled data ingestion without governance, misconfigured Identification/Reconciliation Rules leading to duplicates/orphans, and absent ownership. Diagnosis must triangulate sources—run CMDB Health queries, trace data lineage via ECC Queue/Import Sets, audit rule execution logs, and interview data stewards. Good candidates list dashboard fixes; great ones map to business impact (e.g., failed changes cost $50k/month) and baseline ROI metrics like post-fix compliance >85%.

The Solution

Diagnosis Approach: Query CMDB Health for orphans/duplicates; review Identification Rules order; trace via 'CMDB Data Manager' for conflicts.

// Problem: Diagnose why active Linux CI shows 'Retired' (stale import overrides Discovery)
// Run in Background Scripts or Script Include

var ciSysId = 'sys_id_of_linux_ci'; // e.g., from CMDB query
var grCI = new GlideRecord('cmdb_ci_linux_server');
if (grCI.get(ciSysId)) {
    gs.info('CI Name: ' + grCI.getValue('name') + ', Install Status: ' + grCI.getValue('install_status'));
    // Check last update sources
    var health = new GlideRecord('cmdb_health_detail');
    health.addQuery('ci_sys_id', ciSysId);
    health.addQuery('type', 'IN', 'Completeness;Correctness');
    health.query();
    while (health.next()) {
        gs.info('Health Issue: ' + health.getValue('short_description') + ' (Value: ' + health.getValue('value') + ')');
    }
    // Trace data sources via transform map history
    var mapRun = new GlideRecord('sys_transform_map_run');
    mapRun.addQuery('target_sys_id', ciSysId);
    mapRun.orderByDesc('sys_created_on');
    mapRun.setLimit(5);
    mapRun.query();
    while (mapRun.next()) {
        gs.info('Last Transform: ' + mapRun.getValue('name') + ' on ' + mapRun.getValue('sys_created_on'));
    }
} else {
    gs.error('CI not found');
}
// Output reveals Excel import overrode Discovery, setting install_status=Retired

3 Solution Options:

1. Cleanup Sprint (Quick Win): Use CSDM-driven purge (delete orphans), fix rules. Trade-off: Fast (4 weeks), but no prevention—reverts without governance.
2. Service Graph + AIOps: Enable Connectors for auto-recon, AI health scoring. Trade-off: Accurate (80%+ health), high license cost, 12-week impl.
3. Governance Overhaul: Data Certification campaigns, steward RACI, custom BR for source precedence. Trade-off: Sustainable, requires culture change (6 months).

Senior Considerations

• Why not just 'run Discovery': Ignores multi-source chaos; great answer specifies Data Precedence rules (glide.servicenow.source.precedence) to prioritize Discovery > Connectors > Imports.
• Production Safeguards: Staged rollout—dev clone > test with 10% CIs > prod shadow instance; monitor via IRB for relationship breaks; rollback via CMDB Workspace audit logs.
• Edge Cases: Handles CSM/VRM classes exempt from cascade delete (cmdb.dependent.ci.cascade.op.enabled=false); VMware orphans via Exclusion table.
• Metrics & Great Answer: 'Fix the rules' alone is a good answer; a great one commits to measurable targets (quarterly health score, change lead time) on an exec dashboard tied to ITFM cost savings—proving ROI.
• Transformation: Train via Playbooks, align to CSDM 4.0, integrate Service Mapping for top-down validation.

Total approach restores trust via evidence-based fixes, not syntax.