CGOA — the exam
The Certified GitOps Associate (CGOA) is the CNCF and Linux Foundation's associate-level, knowledge-based credential for one idea, examined properly: a system's desired state lives in a versioned store, and software agents pull it automatically and reconcile reality to match, continuously. It is the narrowest exam on the whole sixteen-exam Golden Kubestronaut ladder — five domains, twenty-five competencies, no cluster, no terminal — and also one of the highest-leverage, because the reconciliation loop it certifies is the same loop underneath CAPA's Argo curriculum and a quarter of the CNPE blueprint over in Platform Engineering. This page is the hub: what the exam actually tests, the four GitOps principles worked against a real example that fails two of them, the full domain table straight from the CNCF curriculum, and what to verify before you register.
Imagine you pin a poster on the wall that says exactly how a room should look — where the couch goes, what color the walls are. Now imagine a small robot whose only job is to keep checking the room against that poster, and quietly fix anything that doesn't match, forever, without anyone asking it to. It doesn't wait for you to notice the couch got moved. It doesn't need someone to push it into the room. It just keeps looking at the poster and keeps looking at the room, and keeps closing the gap. The CGOA is a badge for understanding that robot and that poster really well — not for building the couch.
What the CGOA actually tests
☺ Like you're 10: It's a computer-based quiz about one idea — writing down what you want and letting a robot keep things matching it. No cluster, no typing commands, just questions.
CGOA is knowledge-based: multiple-choice questions, delivered online and remote-proctored, with no live cluster and no terminal in sight. It is testing whether you can hold the GitOps model in your head precisely enough to reason about it — spot the difference between drift and reconciliation, say what actually makes something a valid state store, recognize when an event-driven trigger is being mistaken for continuous reconciliation. It is associate level, and the Linux Foundation lists no formal prerequisites: nothing gates it, and it gates nothing else.
That knowledge-based framing changes how you should prepare. This is not a lab you rehearse until your hands remember it — it is thirteen definitions and four rules you should be able to produce cold, unprompted, and then apply to a described scenario you've never seen before. The single commonest question shape on this exam is a variant of "here is a workflow — is it GitOps, and if not, which principle does it break?" The next section works exactly that question.
CGOA tests a specification, not a product. The four OpenGitOps principles are the spine of the whole exam, and Argo CD and Flux are simply two implementations of them — the curriculum literally says "Git and alternatives," "ArgoCD, Flux, and alternatives." Study the tools and skip the specification, and you'll ace the 14% Tooling domain and flounder on the other 86%.
Who tends to sit it: engineers who already run Argo CD or Flux and want the formal model behind what they operate daily; release engineers and SREs who own rollback and want feedback loop and rollback as precise, testable terms rather than habits; and candidates working toward the CNPE, who get roughly a quarter of that blueprint's GitOps & Continuous Delivery domain covered by studying this exam properly. If you've already cleared the five-exam Kubestronaut foundation — see What Is Kubestronaut? and The Kubernetes Baseline You Need — you have more than enough cluster context to make the terminology click immediately.
The four GitOps principles — and what breaks them
☺ Like you're 10: There are exactly four rules for the poster-and-robot trick. Miss even one and it isn't really GitOps anymore — it just looks a bit like it.
Thirty percent of the paper — the single heaviest domain — is four principles. That sounds trivial until you notice the exam tests you on the edges, not the headline. Learn each one as a rule with a failure mode attached, not just a phrase.
- Declarative — the desired state describes the end state you want, not a sequence of steps to get there. A script of imperative commands that happens to produce the right result still fails this one, even if it's checked into Git.
- Versioned and Immutable — the desired state is stored with a complete, immutable history. A "latest config" object that gets overwritten in place, with no history to revert to, fails this one regardless of where it lives.
- Pulled Automatically — software agents autonomously pull the desired state from the store. A human clicking "deploy," or a pipeline that pushes changes into the system from outside, fails this one — even if everything else about the setup is textbook GitOps.
- Continuously Reconciled — agents continuously observe actual state and work to converge it toward desired state, indefinitely. A process that runs once per merge and then stops watching fails this one, because nothing corrects drift that happens in between runs.
Notice what the four principles don't mention: Git, Kubernetes, YAML, or pull requests. Those are conventions of the dominant implementation, not the specification. Answer exam questions at the level of the rule, not the tool.
A team wires up a CI job: every merge to main triggers a pipeline that runs kubectl apply -f manifests/ against the production cluster, using a stored kubeconfig credential. Is it GitOps? Score it against all four. Declarative — yes, the manifests describe end state, not steps. Versioned and Immutable — yes, the manifests live in Git with full history. Pulled Automatically — noContinuously Reconciled — nokubectl scale, someone patching a Deployment at 2am — sits uncorrected until the next merge. Two out of four. That is not GitOps, even though it is fully declarative, fully versioned, and lives entirely in a Git repository. Expect several questions on this exam built on exactly this half-measure.
The five official domains and their weights
☺ Like you're 10: The test has five parts and they're not the same size. The four rules and the vocabulary together are worth half the whole thing.
Everything below is the CNCF's published Certified GitOps Associate (CGOA) Exam Curriculum — domain names, percentages and competency lists exactly as printed, sorted here by weight, summing to exactly 100% (30 + 20 + 20 + 16 + 14).
| Domain | Weight | Competencies (as published) |
|---|---|---|
| GitOps Principles | 30% | Declarative · Versioned and Immutable · Pulled Automatically · Continuously Reconciled |
| GitOps Terminology | 20% | Continuous · Declarative Description · Desired State · State Drift · State Reconciliation · GitOps Managed Software System · State Store · Feedback Loop · Rollback |
| GitOps Patterns | 20% | Deployment & Release Patterns · Progressive Delivery Patterns · Pull vs. Event-Driven · Architecture Patterns (in-cluster / external reconciler, state store management) |
| Related Practices | 16% | Configuration as Code (CaC) · Infrastructure as Code (IaC) · DevOps & DevSecOps · CI and CD |
| Tooling | 14% | Manifest Format & Packaging · State Store Systems (Git and alternatives) · Reconciliation Engines (Argo CD, Flux, and alternatives) · Interoperability with Notifications, Observability & CI Tools |
Two things worth committing to memory before you study anything else. First: Principles and Terminology together are half the exam — thirteen items total (four principles, nine terms), and both are pure recall-plus-understanding with zero hands-on requirement, which is exactly why the glossary and flashcards punch far above their weight for this particular exam. Second: Tooling is the smallest domain at 14%, which surprises people who assume a GitOps exam is secretly an Argo CD exam. It isn't — the curriculum is written against the abstraction, "and alternatives" attached twice.
GitOps patterns — trigger, reconciler placement, and state store scope
☺ Like you're 10: A robot can check for changes two ways — keep glancing at the poster on its own schedule, or wait for someone to shout "it changed!" And the robot itself can either live inside the room, or sit outside watching several rooms at once.
The 20% Patterns domain is the most architectural part of the paper, and it turns on three axes the curriculum names explicitly.
| Axis | Option A | Option B | What the exam wants you to know |
|---|---|---|---|
| Trigger | Pull — the agent polls the state store on an interval | Event-driven — a webhook or notification tells the agent something changed | Event-driven is a latency optimization layered on top of pull, not a replacement for it. A correct system still converges even if every webhook is dropped. |
| Reconciler placement | In-cluster — the agent runs inside the system it manages | External — the agent runs outside and can manage many systems | In-cluster keeps credentials inside one trust boundary. External centralizes fleet visibility and control at the cost of holding credentials for many targets at once. |
| State store scope | Monorepo — one store, many apps and environments | Many repos — split by team, environment, or tenant | Store management is an explicit named competency: blast radius, review boundaries, RBAC, and how a change is promoted from one environment to the next. |
The domain also names deployment & release patterns and progressive delivery patterns — rolling updates, blue/green, canary, and the split between deploy (the code is present) and release (traffic actually reaches it). Progressive delivery is where the reconciled desired state hands off to a rollout controller like Argo Rollouts: the store says "canary this," and the rollout object watches metrics and shifts traffic in steps — still desired state, still versioned, still reconciled, just one layer more expressive than a plain Deployment.
Related Practices and Tooling
☺ Like you're 10: 30% of the test isn't really about GitOps at all — it's about the neighbor practices GitOps borrows from, and the actual tools that do the pulling and checking.
These two domains together are 30% of the paper, and candidates who study only the four principles leave that third to luck.
Related Practices — 16%, and not GitOps itself
This domain asks how GitOps relates to, overlaps with, and differs from four neighboring disciplines: Configuration as Code (config expressed as versioned files, the raw material a state store holds), Infrastructure as Code (the same idea applied to servers, networks and clusters themselves, not just what runs on them), DevOps and DevSecOps (GitOps as one concrete implementation of "you build it, you run it," with security checks as gates on the same pull request rather than a separate late-stage review), and CI and CD — where one boundary the exam likes shows up constantly: CI pushes, CD pulls. A pipeline builds, tests, and publishes an artifact, then updates the desired state in the store; the reconciler notices and converges, and the pipeline itself never holds a cluster credential. That single sentence answers questions across three different domains at once.
Tooling — 14%, broad and shallow
Manifest format & packaging: plain YAML, Kustomize overlays, Helm charts, OCI artifacts as a distribution mechanism. State store systems: Git primarily, but the curriculum is explicit that OCI registries and object storage can qualify too, judged against versioned-and-immutable, not against being Git specifically. Reconciliation engines: Argo CD (application-centric, with a UI) and Flux (composable controllers), with the exam expecting general awareness that other reconcilers exist. Interoperability: how a reconciler talks to notification systems, observability stacks, and CI tools — the feedback loop made concrete.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: mission-log
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example-org/fleet-config.git
targetRevision: main # the state store pointer — roll back by reverting here
path: apps/mission-log/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: mission-log
syncPolicy:
automated:
prune: true # deletions in the store become deletions in the system
selfHeal: true # drift is reconciled away, continuously — not onceThe same application, expressed as Flux's two-object split — a source and a reconciliation target, with the pull interval stated explicitly on each:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: fleet-config
namespace: flux-system
spec:
interval: 1m # how often the source itself is refreshed — a pull
url: https://github.com/example-org/fleet-config.git
ref: { branch: main }
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: mission-log
namespace: flux-system
spec:
interval: 10m # how often desired vs. actual is reconciled
sourceRef: { kind: GitRepository, name: fleet-config }
path: ./apps/mission-log/overlays/prod
prune: true
wait: true # feedback loop: report Ready, or fail loudly"I deployed by opening a pull request for months and never once thought about what happened after it merged. Turns out most of the CGOA terminology was just a name for things I already did — 'desired state' is my YAML, 'rollback' is my revert, 'state drift' is the time I hotfixed a container by hand with kubectl edit and watched it snap right back an hour later. Learning the vocabulary made me dramatically better at explaining incidents to people who weren't in the room when they happened."
Exam logistics — and how to verify them
☺ Like you're 10: It's an online test you take from your own computer while someone watches through your webcam. Prices and rules change, so always check the official page before you pay for anything.
The structural facts below come from the Linux Foundation's and CNCF's own CGOA pages, read in 2026. Treat every number here as a snapshot, not a guarantee.
| Item | Detail |
|---|---|
| Format | Knowledge-based, multiple-choice. No cluster, no terminal, no performance tasks — unlike the hybrid ICA or the fully performance-based LFCS on this same shelf |
| Duration | 90 minutes |
| Delivery | Online and remote-proctored from your own machine — system check, room scan, government-issued photo ID |
| Price | US$250 list, including one free retake (two attempts total). Bundles and periodic discounts often bring this below list — see Voucher & Discount Stacking |
| Eligibility window | 12 months from purchase to schedule and sit the exam |
| Certification validity | 2 years from the date you pass |
| Prerequisites | None. Nothing gates CGOA, and CGOA gates nothing else on the ladder |
| Pass mark | 75% — published in the Linux Foundation's Multiple Choice Exam FAQ, and it applies to every LF multiple-choice exam, CGOA included, even though it isn't restated on the CGOA product page itself |
| Question count | Not published by the Linux Foundation or CNCF. Treat any specific number you see elsewhere as unverified and ignore it |
This is an independent, unofficial study resource — not affiliated with the CNCF or The Linux Foundation. Price, duration, retake terms, eligibility and validity windows, proctoring rules, and even domain weights are all figures the Linux Foundation and CNCF revise without much notice. Before you register or pay for anything, read the current official Linux Foundation CGOA page and the candidate handbook yourself, end to end. If anything on this page disagrees with them, they are right and this page is stale.
↗ Official CGOA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository
How to prepare, and what comes next
☺ Like you're 10: Study the four rules and the nine words first — that's half the test — then the shapes, then the tools. After that, you either go deep into Argo, or go build.
Start with the CGOA study plan, which maps every domain above to a pacing schedule, then drill with the practice question bank and two timed papers — Mock Exam · Set 1 and Mock Exam · Set 2. For the conceptual foundation underneath the whole exam, read GitOps Philosophy and The Argo Ecosystem; for hands-on practice reconciling and un-breaking a real sync, run the stuck-sync drill and, further along, the capstone. If you want the same loop taught inside a running cluster rather than as an exam curriculum, the sibling Kubernetes course covers it end to end in GitOps on Kubernetes.
CGOA's biggest payoff outside this ladder is the overlap with Platform Engineering's CNPE: its GitOps & Continuous Delivery domain is 25% of that exam and covers substantially the same ground at hands-on rather than definitional depth. If a performance-based deep-dive into that same material is your actual goal, the fuller comparison lives on Platform Engineering's own CGOA page, and the destination exam is the CNPE exam guide.
Nothing fixes this material like breaking it on purpose. On a throwaway cluster, install Argo CD, point an Application at a public repo path with selfHeal: true, then run three small experiments and name the competency each one demonstrates: (1) kubectl scale the Deployment by hand and watch it snap back — state drift and state reconciliation; (2) revert the commit that changed the image tag and watch it converge — rollback via the state store; (3) turn automated off and sync by hand — you've just broken Pulled Automatically, and it is, technically, no longer GitOps. Thirty minutes, three domains, one cluster.
Foxy: A whole certification for one idea? That sounds like a twenty-minute quiz stretched to ninety.
Recon: BEEP. Show her the CI pipeline question, Timmy.
Timmy: Every merge runs kubectl apply from a Jenkins job. Foxy — GitOps, or not?
Foxy: Obviously yes, it's declarative YAML in Git—
Recon: BEEP. Two principles out of four. Nothing is pulling. Nothing is watching between merges. I am not involved in this pipeline at all.
Gizmo: Who cares, it deploys, doesn't it? Ship it and call it GitOps, nobody's actually going to check your terminology on a Tuesday. 😈
Nutty: The exam checks, Gizmo. Twenty percent of the paper is exactly this kind of terminology, filed and cross-referenced, waiting for someone to get sloppy.
1. Name the five CGOA domains and their weights, and which two together make up half the exam. 2. A CI job runs kubectl apply on every merge, using manifests stored in Git. Which two principles does it satisfy, and which two does it break — and why? 3. What is a "state store," and why does the curriculum keep saying "Git and alternatives"? 4. Give one advantage each for an in-cluster and an external reconciler placement. 5. In the phrase "CI pushes, CD pulls," what exactly is CD pulling, and from where? 6. What does the CGOA pass mark actually require, and where is it published if not on the CGOA exam page itself? 7. Which figure about this exam does the Linux Foundation not publish at all, and what should you do if you see a confident number for it somewhere else?
Check your answers
- GitOps Principles 30%, GitOps Terminology 20%, GitOps Patterns 20%, Related Practices 16%, Tooling 14%. Principles and Terminology together are 50% — thirteen items, all recall-and-understanding, no lab required.
- It satisfies Declarative (the manifests describe end state) and Versioned and Immutable (they live in Git with history). It breaks Pulled Automatically (the CI job is an external actor pushing in, not an agent pulling on its own) and Continuously Reconciled (it runs once per merge and does not correct drift that happens afterward).
- The system holding the declarative desired state with a versioned, immutable history. Git is the default choice, not the definition — OCI registries and other versioned stores can qualify too, which is why the curriculum names alternatives explicitly rather than naming Git as the requirement.
- In-cluster: credentials for that cluster never leave its own trust boundary, and blast radius from a compromised reconciler is one cluster. External: one control point gives fleet-wide visibility and consistent policy across many clusters, at the cost of that one point holding credentials for every cluster it touches.
- CD is pulling the desired state that CI just published to the store — the built and tested artifact reference, not raw source code — from the state store itself. CI never holds cluster credentials; it only ever writes to the store.
- A score of 75% or higher. It's published in the Linux Foundation's Multiple Choice Exam FAQ, which applies to every LF multiple-choice exam — it is not restated on the CGOA product page specifically, so you have to know to look for it there.
- The question count. The Linux Foundation and CNCF do not publish it anywhere, so any specific number quoted for it on a third-party page — including this one, if it ever appeared here — is unverified and should be ignored. Confirm exam-day specifics on the official Linux Foundation CGOA page before you register.