Skip to main content
This lesson explains how Infrastructure-as-Code (IaC) and Configuration-as-Code (CaC) relate and how they cooperate in a GitOps workflow. We’ll cover definitions, differences, recommended tools, and a practical GitOps pattern for deploying infrastructure and application configurations from Git.
GitOps treats Git as the single source of truth: make changes by updating Git and let automation (CI/CD or a GitOps controller) reconcile those changes against your environments.

​
At a glance

IaC and CaC are complementary:
  • IaC provisions and maintains infrastructure resources (cloud services, clusters, networks).
  • CaC configures operating systems, runtime services, and application settings on that infrastructure.
  • In GitOps you typically use IaC to create the platform (clusters, VPCs, storage) and CaC to deploy and configure applications inside that platform (Kubernetes manifests, Helm charts, or configuration management scripts).

​
Key differences (quick reference)

​
Common tools and examples

Useful references:

​
How IaC and CaC fit together in a GitOps workflow

A typical GitOps deployment separates concerns while keeping everything declarative in Git:
  1. Author IaC to provision and update foundational resources:
    • Create/modify Terraform or Pulumi modules to provision clusters, VPCs, and storage.
    • Apply via CI/CD pipelines or an IaC operator.
  2. Store application configuration (CaC) in a Git repo watched by a GitOps controller:
    • Kubernetes manifests, ConfigMap/Secret YAMLs, or Helm charts live in a Git repository.
    • A GitOps controller (Argo CD, Flux) continuously reconciles cluster state with repo state.
  3. Reconcile and observe:
    • CI/CD and GitOps controllers ensure the environment matches the desired state in Git.
    • Rollbacks are performed by reverting commits in Git; automated reconciliation enforces the change.

​
Practical example (end-to-end)

  • Provision infrastructure with IaC:
    • Use Terraform to create an AWS EKS cluster, VPC, subnets, and IAM roles.
  • Deploy and configure applications with CaC:
    • Commit Helm charts or Kubernetes manifests to a gitops-apps repo.
    • The GitOps controller (Argo CD / Flux) watches gitops-apps and applies manifests to the EKS cluster.
  • Manage non-Kubernetes hosts:
    • Use Ansible to provision OS settings, install monitoring agents, and configure bastion hosts; store playbooks in Git and run via CI/CD.
This separation allows platform teams to own and version IaC while application teams manage CaC for their services, with Git enabling auditability and safe rollbacks.

​
Workflow checklist

  • Use Git as the source of truth for both infrastructure and configuration.
  • Separate IaC and CaC repositories or directories to isolate responsibilities.
  • Automate applying IaC changes (CI/CD, Terraform Cloud) and CaC reconciliation (Argo CD, Flux).
  • Add CI checks (linting, tests) to prevent bad manifests from being applied.
  • Tag or version releases so rollbacks are simple and auditable.

​
Analogy

  • IaC is building the house: foundation, framing, wiring.
  • CaC is furnishing and operating the house: appliances, thermostat settings, installed software.
By keeping both infrastructure and configuration declarative in Git and automating their application, GitOps delivers reproducibility, observability, and safer rollbacks across both IaC and CaC changes.

Watch Video