Skip to content

GitOps

Core (the deploy model most Kubernetes-native shops converge on). · prereq 04 (Orchestration · Kubernetes & Helm), 15 (CI/CD), 19 (Secret Management) — GitOps operators reconcile into a Kubernetes cluster, sit downstream of a CI pipeline that builds and tests, and need a secrets strategy that doesn't put plaintext secrets in the git repo they read from. · ~1 day (4 reference submodules — what GitOps is, pull vs. push reconciliation, ArgoCD & FluxCD, and drift/rollback). Reality check: this is the 80/20 on-ramp; real fluency (running ArgoCD or Flux against a multi-cluster, multi-team fleet) is built on the job.

Module 15 (CI/CD) covers a pipeline that pushes a change out to a cluster. GitOps asks a sharper question: what if git itself — not the pipeline, not a human running kubectl apply — is the single source of truth for what should be running, and something else's whole job is making the cluster match it?

TL;DR — in 30 seconds:

  • GitOps stores the desired state of infrastructure/deployments declaratively in git, and an in-cluster operator continuously reconciles the live state to match it — nobody pushes changes directly to the cluster.
  • This is pull-based: the operator inside the cluster pulls from git and applies, rather than a pipeline outside the cluster pushing credentials in — a meaningfully different trust and access model than push-based CI/CD deploys.
  • ArgoCD and FluxCD are the two dominant GitOps operators for Kubernetes; both give you drift detection (the live state silently diverges from git → flagged or auto-reverted) and rollback by revert (undo a deploy by reverting the git commit, not by remembering what to run).

Learning objectives

By the end, the junior can:

  • Explain what "git as the single source of truth" means for infrastructure, and why an in-cluster operator reconciling to it is a different model than a pipeline running kubectl apply.
  • Explain the pull vs. push distinction between GitOps and traditional CI/CD deploys, and why pull-based reconciliation needs no cluster credentials outside the cluster.
  • Compare ArgoCD and FluxCD at a concept level — what each is, and that both implement the same GitOps pattern via different tooling.
  • Explain drift detection and why a GitOps operator flags or reverts changes made outside git.
  • Explain rollback-by-revert: why undoing a deploy is "revert the git commit," not "remember and re-run the previous command."
Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

1. Learn · acquire the concept

No external course — read this brief, then go deeper in the four reference pages below.

Mental model (20 minutes):

flowchart LR
    A["Git repo<br/>desired state, declarative"] -->|"operator pulls"| B["GitOps operator<br/>ArgoCD · FluxCD"]
    B -->|"reconcile"| C["Live cluster state"]
    C -.->|"drift detected"| B
    B -.->|"flag or auto-revert"| C
  • Git is the source of truth — the desired state of what should be running lives in a git repo as declarative manifests, not in a person's head or a pipeline's runtime logic.
  • An operator pulls, it isn't pushed to — ArgoCD or FluxCD runs inside the cluster and periodically pulls from git, comparing desired state to live state. Nothing outside the cluster needs cluster-admin credentials to deploy.
  • Reconciliation is continuous — the operator doesn't just apply once; it keeps comparing, so a manual kubectl edit that drifts the cluster away from git gets flagged (or auto-reverted, if configured).
  • Rollback is a git operation — because the live state always tracks git, rolling back means reverting the commit that introduced the bad change; the operator reconciles the cluster back to match on its own.

Go deeper: What GitOps is · Pull-based vs. push-based deploys · ArgoCD and FluxCD · Drift detection and rollback by revert

Check yourself — a CI/CD pipeline runs kubectl apply against production from a GitHub Actions runner. What does GitOps change about this picture?

GitOps moves the deploy step from push (the runner, outside the cluster, holds credentials and pushes changes in) to pull (an operator running inside the cluster pulls from git and applies). Nothing outside the cluster needs direct write access to it — the pipeline's job stops at "get the change merged into git," and the operator takes it from there.

Check yourself — someone runs kubectl edit directly against a cluster managed by ArgoCD or Flux, bypassing git entirely. What happens?

The next reconciliation loop compares live state to git, finds the manual edit doesn't match the declared state, and — depending on configuration — either flags the drift or automatically reverts the cluster back to what git says it should be. The manual change doesn't persist because git, not the live cluster, is the source of truth.

Done when: you can explain, in order, why GitOps is pull-based, what a reconciliation loop actually does, and why rollback becomes "revert the commit" — before moving to Pair.

2. Pair · passive → active

Drive the onboarding-tutor:

  • "Give me a CI/CD pipeline that runs kubectl apply from a runner and make me redesign it as a GitOps pull-based flow, naming exactly what moves and what credentials are no longer needed outside the cluster."
  • "Quiz me on the difference between ArgoCD and FluxCD, and make me explain what's actually the same between them (the GitOps pattern) versus what differs (the tooling)."
  • "Give me a scenario where someone runs a manual kubectl command against a GitOps-managed cluster, and make me predict exactly what the operator does next."
  • "Walk me through a bad deploy that needs to be undone, and make me explain rollback as a git operation, not as 're-running the previous deploy command'."
  • "Quiz me on why a GitOps repo shouldn't contain plaintext secrets, and make me connect this to what module 19 (Secret Management) already taught about keeping secrets out of git."

Common gotchas

  • Manually patching the live cluster to "fix it quickly." Fix: the fix doesn't persist — the next reconciliation either flags or reverts it. Make the change in git and let the operator apply it.
  • Treating ArgoCD/FluxCD as "just another CD tool that also uses git." Fix: the defining trait is pull-based reconciliation from a source of truth, not merely "git is involved somewhere in the pipeline" — a push-based pipeline that happens to read a git repo is not GitOps.
  • Putting plaintext secrets in the GitOps repo. Fix: use the secrets patterns from module 19 (Secret Management) (Sealed Secrets, External Secrets, or a secret store reference) — a GitOps repo is git, and git history is forever.
  • Assuming rollback means remembering what the previous kubectl apply command was. Fix: rollback is reverting the git commit; the operator reconciles the cluster to match on its own.

Done when: you can explain why a manual cluster fix doesn't stick under GitOps, and why rollback is a git operation, without notes.

3. Do · produce an artifact

Exercise — a GitOps adoption writeup:

  1. Pick a deployment from an earlier module (e.g. something deployed in module 04 (Kubernetes)) as your subject.
  2. Write gitops-plan.md naming: which operator you'd use (ArgoCD or FluxCD) and one concrete reason for that choice over the other; what git repo structure holds the desired state; and how secrets referenced by that deployment stay out of the repo (tie this to module 19 (Secret Management)'s patterns).
  3. Add a section describing what happens, step by step, if someone manually edits the live deployment outside of git — name the reconciliation behavior specifically (flagged vs. auto-reverted) and what configuration controls that choice.
  4. Add a section describing how you would roll back a bad deploy under this model — name the specific git operation, not a kubectl command.

Done when: gitops-plan.md names a specific operator with a specific reason, describes reconciliation behavior for a manual out-of-band edit precisely, and describes rollback as a git-level action.

4. Prove · understanding gate

Mandatory. Pass bar in the Socratic gate.

  1. Source of truth: Why is git, not the live cluster, the source of truth in a GitOps model?
  2. Pull vs. push: What specifically changes about credential exposure when a deploy moves from a push-based pipeline to a pull-based GitOps operator?
  3. Drift: What does the operator do when the live cluster diverges from what's declared in git, and what controls whether it's flagged or auto-reverted?
  4. Rollback: Why is "revert the git commit" a stronger rollback story than "re-run the previous deploy command"?
  5. Verification: Which specific claim in your writeup did the tutor suggest, and how did you verify it was correct — by checking documented ArgoCD/Flux behavior, not by trusting the explanation?

Pass bar: you can defend every choice in your writeup by the specific guarantee it provides — not just "it's best practice" — and show how you verified a tutor-suggested detail against real documentation. "It works but I can't say why" = back to Pair.

5. Retain · fight forgetting

This module has no generated Anki deck yet. Recall by re-reading the four reference pages and re-running the Do exercise's writeup against a different deployment until you can name the operator choice, the drift behavior, and the rollback story from memory, unprompted. Done when you can name all three, cold, for any deployment someone hands you.

Key takeaways

  • Git is the single source of truth — the desired state of infrastructure/deployments lives in git as declarative manifests; nothing else decides what should be running.
  • GitOps is pull-based: an in-cluster operator pulls from git and reconciles, rather than an external pipeline pushing changes in with cluster credentials.
  • ArgoCD and FluxCD are the two dominant operators implementing this pattern for Kubernetes — same pattern, different tooling.
  • Drift detection means any out-of-band change to the live cluster gets flagged or reverted, because git — not the live state — is authoritative.
  • Rollback is a git operation — revert the commit, and the operator reconciles the cluster back to match; there's no "remember the previous command" step.

Go deeper — curated resources

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

  • Docs · Argo CD documentation — Argo Project. The canonical reference for ArgoCD's application model, sync policies, and reconciliation behavior. Free.
  • Docs · Flux documentation — CNCF / Flux project. The canonical reference for FluxCD's GitOps toolkit and reconciliation model. Free.
  • Guide · GitOps — What is GitOps? — gitops.tech (OpenGitOps community). A vendor-neutral explanation of GitOps principles, including pull-based reconciliation and drift correction. Free.

Gate log (mentor fills on pass)

  • Date passed:
  • Passed by: / checked by:
  • Weak spots noticed (feeds system improvement):