Configuration Items and the Configuration Management System
From CI to CMS
A single CI record is only useful in context. The Configuration Management System (CMS) is the broader set of tools, data, and processes that hold configuration information - the CMDB is one component within it, alongside discovery tools, asset repositories, and federated data sources. Questions often ask where a given capability lives: discovery and reconciliation belong to the CMS layer, while the CI records themselves live in the CMDB.
Concepts to name
- CI lifecycle: identification, registration, attribute maintenance, verification, retirement.
- Identification and naming: unique identifiers, naming conventions, and avoiding duplicate records.
- Verification and audit: comparing recorded state to actual state and correcting drift.
- Federation: pulling data from authoritative sources rather than duplicating it.
- Configuration baseline: a recorded, approved state used for comparison after change.
- Service context: grouping CIs into business and technical services so impact can be traced.
Traps
Examiners like the distinction between discovery (observation of what exists) and reconciliation (deciding which record is correct and merging). Another trap: assuming every discovered component must become a CI - components outside service scope may be excluded. Also watch for questions implying the CMS is a single product; it is a system of systems.
Worked example
A server is discovered with a new hostname after a rebuild. Discovery creates a candidate record; reconciliation matches it to the existing CI by serial number, updates the hostname attribute from the authoritative source, and preserves the relationship to its hosting service. The CI is updated, not duplicated - and the baseline is refreshed so the next change can be compared.
Rule of thumb
One real-world thing, one CI record, one owner, one authoritative source per attribute.