GitOps uses Git as the single source of truth for infrastructure and application state. A controller continuously reconciles live cluster state toward what Git declares — making Git the only valid way to change production.
GitOps uses Git as the single source of truth for infrastructure and application state. A controller continuously reconciles live cluster state toward what Git declares — making Git the only valid way to change production.
Lesson outline
Traditional CI/CD pipelines push changes to production: a pipeline runs, calls kubectl apply or terraform apply, and production changes. GitOps inverts this model. Instead of the pipeline pushing to production, a controller inside the cluster pulls from Git and reconciles.
The Four GitOps Principles (OpenGitOps)
1. Declarative: the desired system state is expressed declaratively (YAML, Helm charts, Kustomize). 2. Versioned and immutable: desired state is stored in Git — providing version history, diffs, and the ability to revert. 3. Pulled automatically: software agents (Argo CD, Flux) automatically pull the desired state from Git. 4. Continuously reconciled: agents continuously compare actual state to desired state and correct any divergence.
The critical mental shift: in GitOps, you never run kubectl apply or terraform apply manually against production. Git is the only interface. Want to change a Deployment? Open a PR. Want to rollback? Revert a commit. The controller handles the rest.
| Approach | Who applies changes | Audit trail | Drift detection | Rollback |
|---|---|---|---|---|
| Traditional CI/CD push | Pipeline runs kubectl/terraform directly | CI logs (often incomplete) | None — manual changes invisible | Re-run pipeline with old tag |
| GitOps (pull) | Controller watches Git and reconciles | Git history = complete audit log | Automatic — controller detects and corrects | git revert + merge = auto-rollback |
Separate App Repo from Config Repo
GitOps works best with two repos: an app repo (source code, Dockerfile, CI pipeline) and a config repo (Kubernetes YAML, Helm values, environment configs). CI builds images and updates the config repo. The GitOps controller watches the config repo. This separation means config changes can be reviewed independently of code changes, and the controller has a clean, pure-YAML target.
Argo CD and Flux CD are the two leading GitOps controllers for Kubernetes. Both watch Git and reconcile cluster state, but they differ in architecture, UI, and operational model.
| Feature | Argo CD | Flux CD |
|---|---|---|
| Architecture | Centralized controller with web UI and API | Decentralized set of controllers (source, kustomize, helm controllers) |
| UI | Rich web dashboard with app trees and sync status | CLI-first; optional UI via Weave GitOps |
| Multi-tenancy | AppProject CRD for RBAC and isolation | Namespace-based isolation with Flux tenancy |
| Helm support | Full HelmRelease management | Full HelmRelease management |
| Notification | Argo CD Notifications (Slack, PagerDuty, etc.) | Flux Notification Controller |
| CNCF status | Graduated project | Graduated project |
| Best for | Teams wanting a rich UI and centralized view | Teams preferring GitOps-native, CLI-driven, lightweight approach |
Getting Started with Argo CD in 5 Minutes
kubectl create namespace argocd && kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml Then create an Application pointing at your Git repo and target namespace. Argo CD will sync immediately and show a visual app tree. For production, use the Argo CD Autopilot CLI to bootstrap a complete GitOps setup.
A complete GitOps workflow connects your development process to production through Git as the control plane. Understanding this flow is essential for interviews and for designing reliable delivery pipelines.
01
Developer opens PR: Code change + updated image tag in the config repo (or CI auto-updates the tag in the config repo after a successful build).
02
Review and merge: Peer review of the YAML diff. Merge to main (or an environment branch). This is the only authorized way to change production.
03
Controller detects change: Argo CD or Flux polls Git (or receives a webhook). It detects the new commit and calculates the diff between current cluster state and desired state.
04
Reconciliation: The controller applies the diff to the cluster: updates Deployments, applies ConfigMaps, creates/deletes resources as needed.
05
Health check: The controller monitors the rollout. If health checks fail (Pods crash, readiness probes fail), it can auto-rollback or alert. Argo CD shows degraded status in the UI.
06
Sync complete: Cluster state matches Git. Argo CD shows "Synced / Healthy." The Git commit hash is the deployed version — traceable in Git history.
Developer opens PR: Code change + updated image tag in the config repo (or CI auto-updates the tag in the config repo after a successful build).
Review and merge: Peer review of the YAML diff. Merge to main (or an environment branch). This is the only authorized way to change production.
Controller detects change: Argo CD or Flux polls Git (or receives a webhook). It detects the new commit and calculates the diff between current cluster state and desired state.
Reconciliation: The controller applies the diff to the cluster: updates Deployments, applies ConfigMaps, creates/deletes resources as needed.
Health check: The controller monitors the rollout. If health checks fail (Pods crash, readiness probes fail), it can auto-rollback or alert. Argo CD shows degraded status in the UI.
Sync complete: Cluster state matches Git. Argo CD shows "Synced / Healthy." The Git commit hash is the deployed version — traceable in Git history.
GitOps Does Not Cover Everything
GitOps with Argo CD/Flux covers Kubernetes workload management. It does not automatically manage cloud infrastructure (VPCs, RDS, IAM) — that still requires Terraform/Pulumi, which can also be managed in a GitOps-style with Atlantis or Terraform Cloud. A complete GitOps setup typically combines Argo CD for Kubernetes resources + Atlantis for Terraform.
One of GitOps's most powerful properties is automatic drift detection. When someone makes a manual change to the cluster (kubectl apply, editing a resource in the dashboard), the GitOps controller detects it and can automatically revert it.
GitOps Means Git is the ONLY Way to Change Production
This is not just a guideline — it is an architectural guarantee. If your Argo CD application has selfHeal: true, any manual change to a managed resource will be reverted within seconds. Many teams discover this the hard way: they kubectl apply a hotfix and watch it get reverted. The correct process is always: open a PR, merge, let the controller apply.
Drift detection operates on a sync interval (default 3 minutes for Argo CD) or via webhooks for near-instant detection. The controller compares the live resource manifest against the desired state from Git. Any difference is flagged as "OutOfSync."
Argo CD sync policies
GitOps is increasingly expected knowledge for DevOps/Platform/SRE roles. System design questions about deployment pipelines should mention GitOps. Behavioral questions may probe how you handle production incidents without bypassing the GitOps workflow.
Common questions:
Strong answer: Explaining the pull vs push distinction clearly. Knowing the four OpenGitOps principles. Understanding selfHeal and its implications. Having a concrete answer for "how do you handle emergencies in GitOps." Knowing the difference between Argo CD and Flux.
Red flags: Thinking GitOps and CI/CD are the same thing. Not knowing what drift detection means. Suggesting kubectl apply in production as a routine operation. Confusing Argo CD (Kubernetes GitOps) with GitHub Actions (CI/CD).
Quick check · GitOps Principles
1 / 3
Key takeaways
💡 Analogy
GitOps is like a building's automated climate control system. You set the thermostat (Git declares desired temperature). The HVAC system (controller) continuously monitors the actual temperature (cluster state) and adjusts heating/cooling to match. If someone opens a window (manual kubectl change), the HVAC compensates and returns to the set temperature. You never "manually control" the HVAC — you only adjust the thermostat. The thermostat history (Git log) shows every setting change, who made it, and when.
⚡ Core Idea
Git is the single source of truth. Controllers continuously reconcile actual state to match Git. Manual changes are either forbidden or automatically reverted. The Git history IS the deployment audit log.
🎯 Why It Matters
Without GitOps, production state drifts from what CI last deployed — manual hotfixes, dashboard edits, and kubectl commands accumulate silently. GitOps makes production state observable, reproducible, and auditable. Rollbacks become trivial (git revert). New environments are created by pointing the controller at the same Git repo.
Related concepts
Explore topics that connect to this one.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.