Configuration management, in the systems-administration sense, is the practice of describing the intended state of computers and the software running on them, then using automation to bring real machines into that state and keep them there. Instead of an administrator logging in to each server and making changes by hand, a tool reads a description of how the system should look and enforces it across many machines consistently and repeatably.
A defining principle is the desired-state model. The Puppet documentation frames configuration management around “adherence to a desired state across global infrastructures,” and the CFEngine documentation explains that such a system “ensures that the actual state of a system is in compliance with the predefined model of desired state for the system. If it is not in compliance” the tool “will bring it into compliance.” The administrator declares the destination; the tool works out and applies whatever changes are needed to reach it.
Closely related is convergence: the system is nudged toward its policy on each run, so that repeated application moves a machine ever closer to compliance and an already-compliant machine is left untouched. CFEngine describes this as “not a one-off operation, but a self-repairing process should anything deviate from the policy.” Convergence depends on idempotency, the property that performing an operation many times produces the same result as performing it once, which is what makes it safe to run configuration management on a schedule.
The problem configuration management exists to solve is drift. Over time, manual fixes, ad-hoc installs, and one-off tweaks cause servers that began identical to diverge, producing fragile “snowflake” machines that are hard to reproduce or reason about. By continuously reasserting a single declared configuration, these tools detect and correct drift, keeping a fleet uniform and auditable.
Configuration management is the lineage that runs from CFEngine in the early 1990s through Puppet, Chef, Salt, and Ansible. It overlaps with, but predates, the broader idea of infrastructure as code, and it became a foundational practice of the DevOps movement, where treating system configuration as versioned, testable, automatically applied definitions is now standard.