Module 1: Why Cicd And Gitops
4. What is GitOps
Description
You already know how to automate validations (CI) and automate deployments (CD). "GitOps" is a term you're going to hear constantly alongside those two, and one that's almost never explained precisely: it's not a tool you install, nor a product you buy. It's an operating principle: Git stops being just your code's history and becomes the single source of truth for what infrastructure —and what code— should exist right now. This lesson gives you the term's exact origin, the principle's precise definition, and why the pipeline you're going to build in this guide is a GitOps implementation, even though it never says "GitOps" in any YAML.
Connection to the module
This lesson closes out all the module's foundational theory. Lessons 2 and 3 gave you the problem and the CI/CD vocabulary; this lesson adds the missing conceptual piece to understand why Git, specifically, is the right place for that source of truth to live, and not a separate database or a standalone document. Lesson 5 closes the theory by choosing the concrete tool (GitHub Actions) that's going to implement this principle for the rest of the guide. Module 7 (lesson 4) picks this lesson back up to distinguish two technically different ways of applying the same principle: push (the one you build here) and pull (the one Kubernetes uses with ArgoCD/Flux).
Analogy: the ledger
Imagine a company where, in theory, there's an inventory: what products exist, in what quantity, in which warehouse. But in practice, that inventory lives in two different forms at once: there's a written document someone updates "whenever they remember," and there's whatever each employee remembers having moved from one warehouse to another without writing it down. The day someone asks "how many units are there, really?", the answer depends on who you ask — the document says one thing, Juan's memory says another, and nobody can say with certainty which of the two versions is the real one.
GitOps is the decision that there's only one ledger, and that ledger is Git. Not "the document and also what people remember" — only the document, versioned, with a complete history of who wrote what and when. If something isn't in Git, it doesn't count as part of the truth, no matter how sure someone is that they did it. And if something in the real infrastructure doesn't match what Git says, that's not "a second valid version" — it's drift: an error to fix, not an alternate source of truth.
The term's exact origin
GitOps isn't a concept that's "always existed" in the infrastructure industry — it has a dated origin, with a concrete name and date:
THE ORIGIN OF GitOps
Aug-2017 Alexis Richardson, CEO of Weaveworks, coins the term
"GitOps" in a series of posts on the company's official
blog, describing how Weaveworks operated Kubernetes
using Git as the central deployment mechanism
│
2017-2018 The term is quickly adopted in the Kubernetes
community — coinciding with the maturation of operators
like Flux (created by Weaveworks itself)
│
2020 The Cloud Native Computing Foundation (CNCF) accepts Flux
as a project — GitOps stops being one company's
terminology and becomes standard vocabulary for the
cloud native ecosystem
│
today GitOps is used to describe both Kubernetes' original
pull-based pattern (ArgoCD, Flux) and the push-based
pattern of a CI pipeline that applies infrastructure
— the same principle, two different technical mechanisms
(revisited in Module 7 of this guide)The takeaway worth keeping from this timeline: GitOps was born specifically in the context of Kubernetes, not Terraform or infrastructure in general. That this guide applies it to a Terraform pipeline is a legitimate, widely adopted extension of the same principle —not a deviation from the term— but it's important that you know where it comes from, because it's going to help you understand why, when someone mentions "GitOps" in an interview or a job posting, they're frequently thinking of ArgoCD or Flux first, not a GitHub Actions apply.yml.
The principle, precisely (not the tool)
GitOps is defined, in a standard way across the industry, by four properties — it's worth having these exact, because they're what determine whether something "is GitOps" or just "uses Git":
- Desired state is declared. There's no list of commands to run in order — there's a description of what should exist. You already learned this, under a different name, in
terraform-and-iac-guide(lesson 3): it's the same "declarative vs. imperative" idea. - Git is the single source of truth. Desired state lives versioned in a Git repository — not in anyone's head, not in a separate document, not in the console where someone made a "quick, just-this-once" change.
- Approved changes are applied automatically. A system —not a human typing commands— is responsible for making real infrastructure match what Git says. The human decides what change to approve (via pull request); the system decides how to apply it.
- Real state is continuously reconciled against Git. Applying once isn't enough — the system must be able to detect when reality drifts from what's declared (drift) and, depending on design, correct it automatically or at least alert on it. This guide builds the detection version (Module 5,
drift.yml); full automatic correction is outside its scope.
Notice something important: none of these four properties mentions a specific tool. GitOps isn't "using ArgoCD" or "using GitHub Actions" — it's fulfilling these four properties, no matter what tool implements it. You could, in theory, implement a rudimentary GitOps system with a cron job that runs git pull && terraform apply every five minutes — it would be crude, with no review or gates, but it would technically fulfill the four properties. What this guide builds, with GitHub Actions and act, is a much more robust and secure version of the same principle, not a different implementation of a different principle.
Why this guide's pipeline is GitOps, even though it never says "GitOps" in any YAML
Go through what you're going to build, module by module, against the four properties above:
| GitOps property | How this guide's pipeline fulfills it |
|---|---|
| Desired state, declared | The andes-cargo-infra/ HCL, inherited intact from terraform-and-iac-guide |
| Git as the single source of truth | Every infrastructure change comes in through a commit on a branch, reviewed in a Pull Request — never through a direct click in a console |
| Automatic application of approved changes | apply.yml (Module 5), triggered by push to main, with nobody typing terraform apply |
| Continuous reconciliation against Git | drift.yml (Module 5), a scheduled terraform plan that detects whether reality has drifted from what's declared |
This is, precisely, infrastructure GitOps. The difference from Kubernetes' "classic" GitOps —the one you're going to name, without building it, in Module 7— isn't in the principle: it's in the mechanism that applies the change. Here, a CI pipeline (GitHub Actions) pushes the change out when it detects a push to main — this is called push-based. In Kubernetes' model with ArgoCD or Flux, an operator running inside the cluster watches the Git repository constantly and pulls the changes in when it detects them — this is called pull-based. They're two genuinely distinct technical mechanisms, which even carry different security implications (in pull, no external party needs credentials to write to the cluster; in push, the pipeline does need credentials to write outward) — but both fulfill GitOps's four properties. Module 7 (lesson 4) picks this distinction back up with the complete technical detail.
Common mistakes
Believing "GitOps" means "having the code in GitHub" (by far the most common one). What happens: someone concludes that, since their team already versions the HCL in a repository, they're already "doing GitOps." Why it happens: the name includes the word "Git," and using version control is, without a doubt, a prerequisite. How to spot it: if your infrastructure is versioned in Git, but someone can still apply a change by running terraform apply by hand, without going through a reviewed Pull Request. How to fix it: versioning the code is property #2, but not the only one — without automatic application of approved changes (#3) and continuous reconciliation (#4), you have version control, not GitOps. The four properties have to be met together.
Thinking GitOps is exclusive to Kubernetes (scope-based, corrected in this lesson). What happens: someone, knowing the term was born in the context of Kubernetes, concludes that applying it to a Terraform pipeline "isn't real GitOps," just an incorrect appropriation of the term. Why it happens: the historical origin (Weaveworks, 2017, Kubernetes) is real and specific. How to spot it: if you think this guide's pipeline should be called something else. How to fix it: the term's origin doesn't limit its scope — the four properties that define it (declarative, Git as source of truth, automatic application, reconciliation) don't mention Kubernetes at all, and the extension to general infrastructure (Terraform, CloudFormation, any IaC) is widely accepted in the industry today. What does vary, and is worth precisely distinguishing (Module 7), is the mechanism: push here, pull in Kubernetes.
Confusing "the system applies automatically" with "nobody reviews anything" (conceptual, already seen in lesson 3). What happens: someone interprets property #3 ("approved changes are applied automatically") as if it meant there's no human control in the process at all. Why it happens: the word "automatically" sounds, on first read, like "unsupervised." How to spot it: if you think GitOps eliminates human review instead of relocating it. How to fix it: the key word in property #3 is "approved" — the human still decides which change to approve, via Pull Request, exactly as you saw in this module's lesson 3. What GitOps automates is the mechanical step of "making infrastructure match what was approved," not the decision of what to approve.
Exercises
Exercise 1 — Evaluate a scenario against the four properties. A team describes their process like this: "all our Terraform lives in a GitHub repository, and when someone wants to change something, they open a Pull Request that someone else reviews. Once approved, the person who approved it runs terraform apply from their own laptop." Which of the four GitOps properties does this team fulfill, and which doesn't?
See solution
They fulfill: (1) declared state (it's Terraform, declarative by design) and (2) Git as the source of truth with review via PR. They don't fulfill (3): applying the change is still a human typing terraform apply by hand, not an automatic system — this reintroduces exactly problem #1 from this module's lesson 2 (who ran the apply, with what credentials). They almost certainly also don't fulfill (4): without a scheduled drift-detection job, there's no continuous reconciliation. This team has "IaC with code review" — a real step of maturity over apply with no process at all — but not yet full GitOps.
Exercise 2 — Distinguish origin from scope. Explain to a colleague, in two or three sentences, why it's correct to say the Andes Cargo pipeline "does GitOps" even though the term was born specifically to describe how Weaveworks operated Kubernetes in 2017.
See solution
A complete answer sounds, roughly, like this: "GitOps isn't defined by the technology it's applied to, but by four properties: declared infrastructure, Git as the single source of truth, automatic application of approved changes, and continuous reconciliation against reality. The Andes Cargo pipeline fulfills all four, even though it applies to Terraform and not Kubernetes — the term's historical origin explains where the name comes from, not where its valid scope ends. What does change between the original Kubernetes case and this guide's case is the technical mechanism —pull vs. push— not whether it qualifies as GitOps."
Exercise 3 — Diagnose drift without using the word "drift." Explain to someone who's never heard the term what GitOps's fourth property (continuous reconciliation) means, using the example of the andes-cargo-shipment-docs bucket policy that someone might have changed manually in the console.
See solution
A complete explanation sounds, roughly, like this: "Even though the entire change process goes through Git and review, someone could always, technically, go into the AWS console and change something directly, without going through any Pull Request. A system that only applies changes when Git changes, but never compares reality against what's declared again, wouldn't find out about that direct change — it would stay invisible until someone notices by accident. GitOps's fourth property is the guarantee that, periodically, someone —an automatic job, in this case— asks again 'does what really exists still match what Git says should exist?', and flags it if the answer is no."
Summary and next step
In this lesson you learned GitOps's exact origin (Alexis Richardson, Weaveworks, August 2017, in the context of Kubernetes) and the four properties that precisely define it: declared state, Git as the single source of truth, automatic application of approved changes, and continuous reconciliation against reality. You confirmed that the pipeline you're going to build in this guide fulfills all four, even though it uses Terraform instead of Kubernetes, and even though it never says "GitOps" in any YAML file. You also previewed the distinction between push-based GitOps (this guide) and pull-based (Kubernetes with ArgoCD/Flux), which Module 7 picks back up with the complete technical detail.
Before moving on you should be able to: name GitOps's four properties unaided; explain why "having the code in GitHub" isn't, by itself, GitOps; and locate, in this guide's pipeline, which piece corresponds to each of the four properties.
This closes out all the module's foundational theory. Lesson 5 chooses, with honest market evidence, the concrete tool that's going to implement all of this: GitHub Actions — also naming its real alternatives, without pretending it "wins" everywhere.
Resources
- Weaveworks Blog — What Is GitOps, Really? — the term's origin, written by Weaveworks itself, this lesson's historical basis.
- GitHub Docs — About continuous deployment — the vocabulary of automatic change application, used in this lesson's property #3.
- CNCF — Flux — Weaveworks's original GitOps project, today graduated within the Cloud Native Computing Foundation, named (not built) in this guide's Module 7.
terraform-and-iac-guide, Module 1, lesson 3 (03-what-is-infrastructure-as-code.md) — the definition of "declarative" that underpins GitOps's property #1, already assumed in this lesson.