Configuration Management
In plain English
Plain definition
Configuration Management tracks, controls and verifies the state of infrastructure and software configuration items over time, using declared desired-state definitions, drift detection and auditable change history to keep systems consistent and recoverable.
Technical Definition
Configuration Management (CM) is a discipline and set of tools that define, apply, enforce and audit the state of configuration items—servers, network devices, application settings, operating system parameters and infrastructure resources—against a declared baseline. A CM system typically stores configuration as version-controlled artefacts (manifests, playbooks, modules or declarative files), applies them idempotently to target hosts, detects drift when actual state diverges from the declared baseline, and produces an audit trail of what changed, when and by whom. CM is distinct from provisioning (creating a resource) and orchestration (sequencing work across resources), though tools in this category often perform all three.
Operational Relevance
Operations teams rely on Configuration Management to keep fleets of servers or services consistent without manually logging into each one. Typical operational uses include:
- Enforcing baseline security settings (permissions, service states, patch levels) across many hosts.
- Detecting and remediating configuration drift after ad hoc manual changes.
- Reproducing an environment reliably for disaster recovery or scaling events.
- Providing an auditable record of configuration change for compliance reviews.
Without CM, teams depend on undocumented tribal knowledge and manual runbooks, which increases the risk of inconsistent environments and untraceable changes.
Architecture Relationship
Configuration Management sits between provisioning and application deployment in most operational architectures. Provisioning tools (or infrastructure-as-code systems) create the compute, network and storage resources; Configuration Management then applies and maintains the software and settings on those resources; deployment or release tooling delivers application artefacts on top. CM agents or agentless runners typically communicate with a central control node or pull configuration from a version-controlled repository, and many systems integrate with monitoring and alerting to surface drift as an operational signal rather than a silent divergence.
Example
A platform team declares that every application server must run a specific logging agent version with a defined configuration file. The Configuration Management tool checks each server against this declared state on a scheduled interval; if a server’s logging agent has been manually reconfigured or is missing, the tool reapplies the declared configuration and records the correction in its run log, giving the team a verifiable history of the deviation and remediation.
Common Misunderstanding
A frequent misunderstanding is treating Configuration Management as equivalent to Infrastructure as Code (IaC). IaC defines and provisions the existence and shape of infrastructure resources (for example, creating a virtual machine or network); Configuration Management defines and maintains the state inside or on top of resources that already exist (for example, ensuring a package is installed and a service is running). The two are complementary and are often used together, but conflating them leads teams to assume that provisioning a resource automatically guarantees its internal configuration is correct and enforced—it does not, unless a CM layer is also applied and continuously verified.
Related Terms
- Infrastructure as Code
- Configuration drift
- Desired state
- Idempotency
- Change management
Further Reading and Verification
Before relying on Configuration Management claims for a specific platform or product version, confirm the current documentation for that tool, since implementation details, supported configuration formats and drift-detection behaviour vary by vendor and release.
- Confirm the exact Configuration Management tool and version in use in your environment before applying any baseline.
- Validate in an isolated or non-production environment first, and confirm permissions before applying any declared-state change.
- Review the audit or run log after each application to confirm the observed result matches the declared configuration, and retain the previous configuration artefact so a change can be reverted if the applied state causes unexpected behaviour.