Configuration
About 15% of the CIS-DF exam — see all 5 domains.
CI Class Manager
The single place to manage CMDB classes: the class hierarchy (classes that extend cmdb_ci), Basic Info (display name, description, icon; the table name cannot be changed), attributes, identification and reconciliation rules, dependent relationships, health settings and principal class designation. A child class can be added only under a class marked extendable.
IRE: identification
- Identification rules decide whether an incoming payload matches an existing CI. A rule has identifier entries, tried in priority order, each with criterion attributes that must all have values (unless null is allowed).
- Prefer independent rules (the class carries enough attributes of its own). Dependent rules identify a CI in the context of another CI through hosting or containment rules; keep dependency to one level, two at most.
- When a payload carries a known source name and source native key, the IRE can identify the CI from them.
- Identification inclusion rules limit which CIs of a class are match candidates (for example only operational CIs).
- IRE data source rules stop a specific source from inserting new CIs for a class while still allowing updates.
- With the enhanced API, items that cannot be identified yet (for example a disk whose computer has not arrived) are held as partial payloads and merged when a matching payload arrives.
- Identification Simulation lets you test how the IRE would process a payload without changing data.
IRE: reconciliation
- Static reconciliation rules say which sources may update which attributes and in what priority (a smaller number is a higher priority). A rule for a specific attribute takes precedence over an Apply to all attributes rule. Sources without a rule get the lowest priority.
- A lower-priority source can still write when it is the first to update the CI, or when the authoritative source has gone stale under a data refresh rule (Effective Duration per source and class).
- Dynamic reconciliation rules choose a value from CMDB 360 data (for example the most reported or largest value) and require CMDB 360.
CMDB 360 / Multisource CMDB
- Enabled by activating the ITOM Discovery License plugin and turning on the CMDB 360 property (off by default).
- Stores what each source reported for each CI, including values that were not selected, so you can compare sources, see which source set each attribute, revert a bad source's updates and recompute values. Classes can be excluded.
- Use it when several sources report on the same CIs and you need to see and reconcile their differences.
Sample questions from this domain
Three of the 44 in this domain, with the reasoning. The full set is in the question bank.
An administrator opens a custom class in CI Class Manager and reviews the Basic Info section. Which change does CI Class Manager prevent from being made there?
- A. Updating the class description
- B. Editing the class display name
- C. Changing the class icon
- D. Changing the class table name ✓
Why: Basic Info in CI Class Manager shows the display name, table name, description, and icon for the class. Some of these definitions can be edited, but the table name cannot, because it is the physical table created when the class was defined. The display name (the label shown on lists and forms), the description, and the class icon are descriptive metadata that the administrator can maintain from Basic Info, so they are not the restricted item.
A static reconciliation rule makes Discovery the highest-priority source for the Server class, and a Service Graph Connector is a lower-priority authorized source. Discovery has stopped scanning one data center. The team wants the connector to be allowed to update those servers once Discovery has not refreshed them for 14 days. What should be configured?
- A. A data refresh rule for Discovery on the class with an Effective Duration of 14 days ✓
- B. An identification inclusion rule that excludes servers not scanned in 14 days
- C. An IRE data source rule that stops Discovery from inserting new Server CIs
- D. A CMDB Health staleness rule on the class with an Effective Duration of 14 days
Why: Data refresh rules work together with static reconciliation rules. If the authoritative source does not update the reconciled attributes within the rule's Effective Duration, the CI is considered stale for that source and a lower-priority authorized source, here the connector, may update it. A CMDB Health staleness rule only flags old CIs for the Correctness KPI; it does not change which source is allowed to write. An identification inclusion rule limits which CIs IRE considers when matching, and an IRE data source rule controls whether a source may create new CIs, so neither lets the connector take over updates.
Retired Server CIs keep being matched by IRE when replacement hardware reports the same identifier values, so new payloads update the retired records. The team wants IRE to consider only operational Server CIs as match candidates. What should they configure?
- A. A reconciliation rule that gives Discovery priority over every other source
- B. An identification inclusion rule limiting Server matches to operational CIs ✓
- C. A data refresh rule on the Server class with a short Effective Duration
- D. A CMDB Health inclusion rule that leaves retired CIs out of the dashboard
Why: Identification inclusion rules are defined per class in CI Class Manager and restrict which CIs IRE evaluates during identification and duplicate detection, for example only CIs whose state is operational. The base system has none, so by default every CI is a candidate. Because they affect every script that calls IRE, they should be created carefully. Reconciliation rules and data refresh rules decide which source may write attributes after a CI has been matched, not which CIs can be matched. A CMDB Health inclusion rule changes which CIs are scored on the Health dashboard, not what IRE matches.