Configuration Management Database (CMDB)
Purpose
The CMDB holds configuration items and their relationships so that incidents, changes, and services can be scoped to real infrastructure. CIs live in cmdb_ci and its class hierarchy, with relationships between them stored in relationship records and typed by relationship type.
Identification and reconciliation
The Identification and Reconciliation Engine is the most exam-relevant CMDB concept. When data arrives from discovery, service mapping, imports, or manual entry, identification rules decide whether it matches an existing CI; reconciliation rules then decide which source wins for each attribute and whether a new CI is created. Without identification rules, imports create duplicates rather than updating records.
CSDM and service context
The Common Service Data Model provides a common set of classes and relationships so that services, offerings, and technical components connect consistently. Service mapping builds service instances and their dependencies, which is what makes business service impact visible on incidents and changes.
CI versus asset
Assets live on the asset table and represent financial and contractual facts. CIs represent configuration and operational facts. A CI does not have to be an asset and an asset does not have to be a CI; they may be linked. Lifecycle state, install status, and operational status are distinct fields with distinct meanings.
Traps
Assuming discovery is required for CMDB data. Assuming duplicate CIs are always harmless. Assuming CI equals asset. Assuming relationship types are free text rather than defined records.
Worked example
An import brings fifty servers, three of which already exist. Identification rules match serial number, reconciliation prefers discovery over import for hardware attributes, so three records are updated and forty-seven created - not fifty new records. Rule of thumb: if the question mentions duplicates or multiple data sources, the answer involves identification and reconciliation rules.