Configuration Management Database (CMDB) Fundamentals
What the CMDB is for
A CMDB is a database of records describing the components of an IT environment and the relationships among them. Its purpose is not inventory for its own sake but decision support: impact analysis, incident and change triage, asset reconciliation, and service reporting. Candidates should be able to distinguish the CMDB (the store) from configuration management as a process (identify, control, status accounting, verification).
Concepts to name
- CI (configuration item): any component under configuration control that must be managed to deliver a service.
- Attributes: descriptive fields on a CI (name, class, environment, owner, support group, install status).
- Classes and class hierarchy: CI types, often extending a base class, with inheritance of attributes.
- Relationships: typed, directional links between CIs.
- Authoritative sources and data ownership: each attribute should have a designated system of record.
- Reconciliation and de-duplication: merging records from discovery, imports, and manual entry.
Traps
Questions often test whether the CMDB is a system of record for everything (it is not - it federates and references authoritative sources), and whether discovery alone keeps it accurate (it does not; process and ownership do). Another trap is treating CI and asset as synonyms: assets emphasize financial and contractual lifecycle, CIs emphasize configuration and service context, even when the same physical thing is both.
Rule of thumb
If a field cannot be tied to a named owner, a source system, and a consumer decision, it does not belong in the CMDB. Scope by service, not by "everything we can discover."