Configuration Management

---
name: configuration-management
description: "Declarative, idempotent configuration management to keep systems consistent across environments; use it to prevent drift and automate state."
metadata:
  tags: "devops, configuration-management, infrastructure-as-code, idempotent-operations, templates, environment-consistency, drift-prevention"
  source: "https://skilldb.dev/skills/devops-cloud-skills/configuration-management"
  pack: "devops-cloud-skills"
  category: "Technology & Engineering"
---

# Configuration Management

## When to use this skill
Use when the user says things like:
- "How do I configure servers with a single source of truth?"
- "I want to prevent configuration drift"
- "Create an idempotent, template-driven config"
- "Provision a new node with standard settings"


## Core Philosophy
Configuration management ensures that every system in an environment is configured
consistently, reproducibly, and automatically. Rather than logging into servers
and making manual changes, configuration is declared in code and applied
uniformly. This eliminates configuration drift — the slow divergence between
systems that should be identical — which is one of the most common sources of
mysterious production failures.

## Key Techniques
- **Declarative State**: Define what a system should look like (packages installed,
  files present, services running) and let the tool converge the system to that
  state, regardless of its current configuration.
- **Idempotent Operations**: Every configuration run produces the same result
  whether applied once or a hundred times. Running configuration management
  on an already-configured system changes nothing.
- **Role-Based Organization**: Group related configurations into roles (web server,
  database, monitoring agent) that can be composed and applied to nodes.
- **Template-Driven Configuration**: Use templating (Jinja2, ERB) to generate
  configuration files from variables, enabling environment-specific values without
  duplicating file structures.
- **Inventory Management**: Maintain a dynamic inventory of managed systems with
  metadata (environment, role, region) that determines which configurations apply.
- **Pull vs. Push Models**: Choose between agents that pull configuration periodically
  (Puppet, Chef) or a control node that pushes configuration on demand (Ansible).

## Best Practices
- Test configuration changes in a staging environment before applying to production.
- Version control all configuration code with the same rigor as application code.
- Use encrypted vaults for sensitive configuration values like passwords and keys.
- Keep roles small and focused. A role should configure one concern, not an
  entire server stack.
- Run configuration management on a schedule to detect and remediate drift
  automatically, not just during initial provisioning.
- Document role dependencies and execution order explicitly.
- Use dry-run mode to preview changes before applying them.

## Common Patterns
- **Base Role + Application Role**: Apply a base security and monitoring configuration
  to all servers, then layer application-specific roles on top.
- **Environment-Specific Variables**: Same roles applied across dev, staging, and
  production with variables controlling environment-specific settings.
- **Immutable Infrastructure**: Use configuration management to build golden images
  (AMIs, VM images) rather than configuring running servers, combining CM with
  infrastructure-as-code.
- **Compliance Enforcement**: Define security baselines as configuration roles and
  run them continuously to maintain compliance posture.

## Anti-Patterns
- Snowflake servers that were configured manually and are now too fragile to
  touch because nobody knows their exact state.
- Writing imperative scripts disguised as configuration management. Check-then-act
  patterns without idempotency lead to inconsistent states.
- Over-abstracting configurations to the point where simple changes require
  understanding multiple layers of variable inheritance.
- Not testing configuration changes before applying to production. A syntax error
  in a template can break every server in a fleet simultaneously.
- Mixing configuration management tools on the same systems, creating competing
  state definitions.
- Ignoring configuration drift between scheduled runs, allowing manual changes
  to persist until the next convergence.