Configuration Management Database (CMDB)

A configuration management database is the record of what exists in an IT estate and how the pieces depend on each other. Its entries are configuration items — in a definition a vendor guide attributes to ITIL 4, “any component that needs to be managed in order to deliver an IT service” — and the relationships between them are the part that earns the database its keep.

The stated purpose is decision support: the goal is “to give you the information needed to make better business decisions and run efficient ITSM processes,” and the named uses are “impact analysis, root cause analysis, legal compliance.” Strip that down and one question is doing most of the work. Before changing this thing, what else does it touch?

Impact analysis depends on coverage, accuracy, and freshness together. Maintaining those properties requires technical collection and reconciliation as well as owners who can confirm relationships and resolve conflicting claims.

Why the record drifts, structurally

Data gets into a CMDB by three routes, described in the same guide as “manual input, integrations (API-driven, SCCM), and discovery tools that conduct automated scans of all IP addresses in an organization’s network.” Compare that list with how the estate actually changes: pipelines apply infrastructure code, cloud APIs create and destroy resources, and orchestrators reschedule workloads. Unless an integration is built to call the database, none of those changes consult or update it.

API-driven integration can reduce the delay between a change and its record. Without that path, discovery or manual updates may leave a gap whose importance depends on change rate and the decisions being made. Make collection delay and failure visible. A recently collected value may still be wrong at its source, and a missing resource will not acquire a verification timestamp merely because all known records were checked.

Connecting it is necessary and not sufficient, which is the other half of the honest account. The same resource arrives from several sources under different names, so writes have to be matched against what is already there and conflicts resolved by a stated rule rather than appended. A write that fails has to be retried, or the pipeline has succeeded while the record has not. Changes made outside the pipeline — a console edit during an incident, a workload the orchestrator moved — still happen, so something has to compare the database against the estate periodically and report the difference. A tool that has an API is not a synchronized inventory; a tool whose API is called, reconciled, retried and audited is closer to one.

Missing items and stale relationships create different gaps. Comparing independent inventories can reveal missing items; validating dependencies can reveal incorrect edges. Both can remain unnoticed if coverage and confidence are hidden. Record which parts of the estate have not been observed rather than allowing the absence of an entry to imply the absence of a dependency.

Use partial dependency evidence with visible limits

A partial graph can help locate known consumers and owners. It becomes misleading when users treat it as complete and stop investigating dependencies it never collected.

For example, a graph might show three consumers while a fourth was added through an unobserved route. Consulting it as the entire dependency set understates the change’s impact. Having no graph does not guarantee that asking around would find the fourth consumer either. Combine known edges with the collection scope, independent evidence, and additional investigation proportional to the change’s risk. This example illustrates a failure mode, not a claim that partial information is always worse than none.

A blast radius assessment should state what evidence supports it and what remains unknown. Preserve each relationship’s source, observation time, and verification status, as well as coverage gaps. These fields help assess confidence but do not prove completeness. Confirm important relationships with the responsible teams or runtime evidence when the decision requires it.

Where cloud inventories fit, and where they do not

Cloud providers offer services that solve part of this properly, because they sit inside the system that makes the change. AWS Config “provides a detailed view of the configuration of AWS resources in your AWS account,” including “how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.” Azure Resource Graph is described as extending Azure Resource Management “by providing efficient and performant resource exploration,” with “the ability to query at scale across a given set of subscriptions.”

These have the property a CMDB lacks: the authority that changes the resource is the authority that records it, so provider change events and automated collection remove most of the manual registration. That is a different claim from being complete and instantaneous, and the documentation of both services says so. What AWS Config shows you depends on which resource types it supports and which ones you told it to record, and on the recording frequency you chose — continuous, or a daily snapshot. Azure Resource Graph serves queries from an index that is updated as resources change, with a full scan behind it to catch what a change notification missed, so a very recent change may not be visible yet. Neither is a lie; both mean the same practical thing. Before you rely on an inventory for a change decision, check what is in scope, how it is being recorded, and when each record was last observed; someone still has to own the recording scope, the permissions, and the health of collection. They are also narrower in a second way. They know about resources in one provider, not about the business service those resources implement, not about the on-premises database the service calls, and not about who is accountable for it.

So the useful arrangement is not to choose. Let provider inventories be authoritative for what exists and how it is configured, and let the service management record carry what they cannot know — which service this belongs to, who owns it, what it promises, and which business process stops if it stops. Where the estate is created by infrastructure code, the run that creates a resource is the natural place to register that mapping, because the resource identifier and the service it belongs to are both in hand at that moment. It is not the only place, and treating it as such leaves the mapping frozen at birth. Ownership changes, services get split, resources are moved between them, and some are created outside the pipeline — so the same mapping has to be updatable by later events and checked periodically against reality. Registration at creation removes the initial gap; the rest is kept true by the update and reconciliation paths above.

Keep it small enough to be true

Trying to maintain detail without a clear use can increase cost and leave stale fields. A useful filter: an item belongs in the record only if some decision reads it. If no change assessment, no incident triage, and no compliance report consults an attribute, maintaining that attribute buys nothing and adds a field that can be wrong.

That filter may leave services, owners, dependencies, and resource mappings supported by maintained inventories. Keep configuration drift separate from CMDB drift: the former compares declared and actual state, while the latter compares recorded and actual state. Passing one comparison does not prove the other is correct. A tool’s observations of live properties can nevertheless be reused to check both baselines, within its supported scope.

How this record fits with requests, incidents, and change authorization in one operating model is worked through in The Change That Was Approved After It Shipped.

References

• Atlassian, What is a CMDB?
• AWS, What Is AWS Config?
• Selecting which resources AWS Config records
• Microsoft Learn, Azure Resource Graph overview
• AWS CloudFormation — Drift detection

Vendor guides describe their own implementation of ITIL practices, and product behavior depends on the configured model and release.