Part 4 Full Quiz — IRE: Identity & Reconciliation Engine
18 questions (15 topic questions + 3 cross-topic integration) covering IRE architecture, identification rules, reconciliation rules, and deduplication. Multiple exam traps included. Select an answer to reveal the explanation.
[TRAP] What is the root cause?
B is correct and this is the most important IRE TRAP on the exam. Table API writes directly to the CMDB tables, completely bypassing IRE. No identification (dedup check), no reconciliation (field authority), and no deduplication runs. Every integration that uses Table API creates raw inserts — when the same CI is sent twice, two records get created. The fix: ALL integrations must use the IRE API (IdentificationEngineScriptableAPI in scripts, or the REST IRE endpoint) so that identification, reconciliation, and deduplication run for every CI write.
What is the cmdb_ire_event table and how should this be used for troubleshooting?
B is correct. The cmdb_ire_event table is the primary diagnostic tool for all IRE ingestion issues. Every CI write through IRE generates an event record. When the status is "Failed", open the record to see: which phase failed (Phase 1: Identification, Phase 2: Reconciliation, Phase 3: Deduplication), the CI payload that was sent, and the specific error reason. From there you diagnose whether the problem is a missing Identification Rule, a bad payload, or a configuration issue. You do NOT resubmit directly from the table (C) — fix the root cause and re-run the integration.
Which sequence correctly describes IRE's three-phase pipeline?
C is correct. IRE runs in exactly this order: Phase 1 — Identification (does this CI already exist? Match the payload against Identification Rules to find or create the CI). Phase 2 — Reconciliation (which source owns each field? Apply Reconciliation Rules to determine which values to keep). Phase 3 — Deduplication (are there now duplicate CIs? Detect and flag duplicates via the cmdb_dedup table). Remember this sequence — questions often mix up the order as a trap.
[TRAP] What does IRE do with this Identifier Entry?
B is correct — critical exam TRAP. Within a single Identifier Entry, ALL fields use AND logic — every field must be non-NULL and match for the entry to be evaluated. If ANY field in the entry is NULL in the incoming payload, IRE skips the entire Identifier Entry and moves to the next one. It does NOT do partial matching (A). It does NOT treat NULL as wildcard (C). This is why Identification Rules typically have multiple Identifier Entries: Entry 1: serial_number + manufacturer; Entry 2: ip_address + mac_address — fallback entries for when primary fields aren't provided.
Which Identifier Entry does IRE use to identify this CI?
B is correct. Multiple Identifier Entries use OR logic — IRE evaluates them in priority order and stops at the first one that produces a match. Entry 1 has non-NULL values (serial_number + manufacturer both provided) so it IS evaluated, but finds no match. IRE moves to Entry 2. Entry 2 (ip_address + mac_address) produces a match — IRE identifies this as an existing CI and updates it. This is why multiple entries are configured as cascading fallbacks for different data sources that provide different identifiers.
What is the purpose of a Lookup Rule in IRE Identification?
B is correct. A Lookup Rule is used for dependent CIs — CIs that can only be uniquely identified in the context of their parent. A network adapter on a storage array cannot be identified by its MAC address alone (same address might appear on different arrays), but it CAN be identified as "adapter slot 2 on storage array SN-XXXX". The Lookup Rule first identifies the parent CI (the array), then identifies the child CI (the adapter) relative to the parent. This is essential for component CIs like CPU slots, network adapters, and disk drives.
Which built-in ServiceNow utility allows you to simulate IRE identification against a CI payload without writing real CIs?
A is correct. ServiceNow provides the Test Identification utility (navigate to CMDB → Administration → Test Identification). You paste a CI payload (JSON) and select a CI class — it runs the identification logic dry-run and shows you: which Identifier Entry matched, which existing CI was found (if any), and what the result would be (insert vs. update). This is the correct tool for validating Identification Rules before production use. CMDB Health (B) shows health metrics, not rule testing. There is no built-in "IRE Simulation Mode" API flag (C).
Which source's value will be stored in os_version?
B is correct. The default CMDB Data Source Priority order is: Manual (1st) > ServiceNow Discovery (2nd) > Service Graph Connectors (3rd) > Other integrations (4th). In priority-based reconciliation, the highest-priority source wins. Manual edits made by a human in the CMDB form are considered most authoritative because they represent deliberate human overrides. This default can be changed per field via custom Reconciliation Rules. No conflict resolution queue exists — the priority rule resolves it automatically (D is wrong).
What does IRE do with the third-party tool's os_version value?
B is correct. The Staleness Period defines how long a source "owns" a field after writing it. If Discovery's Staleness Period on os_version is 48 hours and it has been more than 48 hours since Discovery last wrote the field, Discovery's ownership expires. The lower-priority third-party tool can now write its value. Staleness Period is evaluated per field, per CI — not per CI as a whole (important exam trap). This mechanism prevents stale data from a dead source from blocking updates indefinitely.
[TRAP] What is the outcome?
B is correct — important TRAP. "Fully Authoritative" means that source owns the field absolutely — it overwrites all other sources including manual edits. If Discovery is set as Fully Authoritative for serial_number, then every time Discovery runs, Discovery's value wins, regardless of what a human typed. The default priority order (Manual > Discovery) is overridden by the Fully Authoritative mode. This is by design — useful for fields like serial_number where Discovery is the ground truth. If you need to protect manual edits, don't use Fully Authoritative for that field, or exclude it from the rule.
[TRAP] What happens to os_version?
B is correct — NULL handling TRAP. IRE's reconciliation logic ignores NULL values from sources. If a source sends NULL for a field, IRE treats it as "source is not providing data for this field" and does NOT overwrite the existing value with NULL. The existing "Windows Server 2019" value is preserved. This prevents accidental data wipe-outs when integrations send incomplete payloads. The Staleness Period is NOT reset by a NULL update — the previous write's timestamp remains active. This is a frequently-tested exam scenario.
[TRAP] What should the admin do FIRST before running the remediation playbook?
B is correct — the most important deduplication rule. If you merge duplicates without fixing the root cause, the same integration or Discovery run that created duplicates will create new ones again immediately. The remediation is permanent but pointless without root cause resolution. Common root causes: (1) integration using Table API instead of IRE API, (2) Identification Rule missing or misconfigured for the CI class, (3) integration not providing key identifier fields. Fix the root cause → verify no new duplicates are being created → then run the remediation playbook. Backup (A) is good practice but not the first step in the IRE workflow.
When a Merge remediation playbook runs, which CI becomes the Master CI?
B is correct. IRE uses a deterministic Master CI selection algorithm based on: (1) number of relationships to other CIs, (2) reference count from other tables (incidents, changes, etc.), (3) age (older CIs preferred). Record A wins on all three criteria — it has 15 relationships, is referenced by Change Records, and is 2 years old. The Master CI is kept; the duplicate (Record B) is merged into it. The Master CI's sys_id is preserved so existing references (like the Change Records) continue to work. IRE does NOT create a new third record (D).
Which remediation actions should be taken for each group?
B is correct. IRE provides four Remediation Playbooks: Merge (combine two duplicate CIs into one master), Keep Primary (flag one CI as the winner but don't merge), Flag (mark as needs review), and Dismiss (declare these are NOT duplicates — removes from dedup queue). For confirmed duplicates: Merge. For false positives (different CIs incorrectly flagged): Dismiss. For uncertain pairs: investigate first, then decide. Merging false positives (A) is irreversible and destructive. Deleting from cmdb_dedup (D) doesn't resolve the duplication — it just removes the detection record.
[TRAP] Is this statement correct?
B is correct — high-frequency exam TRAP. The statement in the scenario is FALSE. Staleness Period is a property of a Reconciliation Rule field entry, not a CI lifecycle setting. It defines: "After source X writes field Y, how long does source X's write remain authoritative before a lower-priority source can overwrite it?" Example: Discovery's serial_number write is authoritative for 72 hours. After 72 hours, even lower-priority sources can update serial_number. It has NOTHING to do with CI retirement. CI retirement is a separate CMDB process entirely (CMDB Discovery Schedules → CI status management, not Reconciliation Rules).
What does IRE do when the payload's lookup identifier field is null?
C is correct. IRE processes Identification Rules in priority order. If a rule's lookup identifier field is null or absent in the payload, that rule cannot match — IRE moves to the next rule. If no rule matches, behavior depends on whether 'create if no match' is enabled. cmdb_ire_event (B) logs events but does not halt the entire run. Automatic IP fallback (D) only happens if an IP-based Identification Rule exists and is configured.
Which value wins for cpu_count, and why?
B is correct. IRE Reconciliation Rule priority: LOWER number = HIGHER authority. Priority 10 (Discovery) beats priority 30 (Import Set) beats priority 60 (SGC). Discovery's value of 8 wins cpu_count. This deterministic model prevents last-write-wins chaos (A). Averaging (C) is not an IRE behavior. This is one of the most-tested IRE concepts on the CIS-DF exam.
Which official CMDB Health KPI dimension is most directly improved by this deduplication work?
C is correct. CMDB Health has three official KPIs: Completeness, Correctness, and Compliance. Correctness has two sub-metrics: Duplicate (eliminated by deduplication) and Staleness (eliminated by refreshing or retiring stale CIs). Deduplication directly improves the Duplicate sub-metric under Correctness. This connects Part 4 (IRE Deduplication) with Part 5/6 (CMDB Health). Completeness (A) measures field population — merging duplicates doesn't add field values.