Practice : Configuration as Code

Purpose and Strategic Importance

Configuration as Code (CaC) is the practice of defining application, platform, and infrastructure configuration in version-controlled files. It brings consistency, traceability, and repeatability to how systems are configured - reducing manual errors and enabling automation at scale.

CaC aligns configuration management with modern engineering practices. By treating configuration like software code, teams gain better visibility into changes, improve compliance, and ensure environments are predictable and secure.

Description of the Practice

  • All configuration (application settings, infrastructure parameters, deployment variables) is stored in source control.
  • Configuration files are reviewed, tested, and deployed via automated pipelines.
  • Changes to configuration follow the same governance process as code changes - pull requests, review, CI/CD.
  • Runtime systems load configuration from defined files or parameter stores, not hardcoded logic or local edits.
  • Secrets are handled via secure vaults or encrypted configuration management systems.

How to Practise It (Playbook)

1. Getting Started

  • Identify system configurations that are currently managed manually or outside version control.
  • Move these configurations into structured files (e.g. YAML, JSON, HCL, TOML).
  • Store configuration files alongside the code or in a dedicated config repo.
  • Use CI to lint and validate configurations before deploying them.

2. Scaling and Maturing

  • Parameterise configuration by environment - avoid duplicating files.
  • Introduce templating engines (e.g. Helm, Kustomize, Jsonnet) to manage complex configs.
  • Secure sensitive parameters using sealed secrets or secret management tools (e.g. Vault, AWS Parameter Store).
  • Track configuration drift with monitoring tools and ensure reconciliation via pipelines or GitOps.
  • Build tooling to validate and enforce configuration policies before changes are merged.

3. Team Behaviours to Encourage

  • Treat configuration files as first-class citizens - code, not docs.
  • Review and test configuration like any software change.
  • Own and clean up legacy or orphaned config values.
  • Collaborate on improving default configurations to raise quality across systems.

4. Watch Out For…

  • Hardcoded values or manual overrides in runtime environments.
  • Configuration that differs between environments without clear reasoning.
  • Lack of ownership - unclear who reviews or approves config changes.
  • Secrets being committed to version control - use encrypted or external secrets instead.

5. Signals of Success

  • Configuration changes are traceable to commits and approvals.
  • Runtime environments reflect what's in source control - no surprises.
  • Teams collaborate on and evolve shared config patterns.
  • Incidents caused by misconfiguration become rare and fast to diagnose.
  • Secure configuration practices are baked into pipelines and reviews.