CGOA — Certified GitOps Associate

The Certified GitOps Associate (CGOA) is the CNCF and Linux Foundation’s associate-level credential for one idea, examined properly: a system’s desired state lives in a versioned store, and software agents continuously pull it and reconcile reality to match. It is the narrowest exam on the cloud-native shelf and, for a platform engineer, one of the highest-leverage — because it maps almost exactly onto the 25% GitOps & Continuous Delivery domain of the CNPE. Here: what it is, whether it’s worth your money, the five official domains and weights from the CNCF curriculum, the substance behind each, and a study plan built from lessons already on this site.

What the CGOA is — and who it is for

☺ Like you’re 10: It’s an online multiple-choice test about one idea — writing down what you want and letting a robot keep things matching it. No cluster, no typing commands.

The CGOA is knowledge-based: multiple-choice questions in an online, remote-proctored session, with no terminal and no live cluster. It certifies that you understand the vocabulary, principles, patterns and tooling landscape of GitOps well enough to design and reason about a GitOps system — not that your fingers can drive argocd at speed.

The scope is unusually tight. Where CNPA sweeps across six domains of platform engineering and CNPE asks you to build under a clock, CGOA drills one topic deeper than either: distinguish state drift from state reconciliation, say what makes a state store valid, explain why an event-driven trigger is not continuous reconciliation.

Knowledge-based, not hands-on

The study regime is therefore retrieval, not reps. You should be able to define every curriculum term in one sentence, unprompted, and to spot a described system that fails one of the four principles. The commonest question shape is “here is a workflow — is it GitOps, and if not, which principle does it violate?” Practise that and much of the paper answers itself.

Who should sit it

• Platform and DevOps engineers who run Argo CD or Flux and want the scaffolding behind what they operate daily.
• Release engineers and SREs who own deployment and rollback — the Rollback, Feedback Loop and progressive-delivery competencies are your day job, formalised.
• Application developers who deploy through a config repo and want to know what happens after the merge.
• Architects and consultants who must answer “should we do GitOps?” credibly — including when the answer is “not yet.”
• CNPE candidates locking down a quarter of that blueprint.

Why a platform engineer would take it — and when to skip it

☺ Like you’re 10: A big chunk of the harder platform exam is exactly this topic — so studying for the small badge does double duty. But if you already know it cold, the badge won’t teach you much.

Be honest about the return: CGOA is a narrow associate credential and nobody gets hired on it alone. Its value to a platform engineer is overlap and structure.

The overlap with the CNPE is enormous

The CNPE’s Domain 2 — GitOps & Continuous Delivery — is 25% of that exam, joint-largest, and it is the same material: declarative desired state, reconciliation and drift, Argo and Flux, application and infrastructure deployment, safe rollouts. Studying CGOA is not a detour from CNPE prep; it is a quarter of it, examined in a form that tells you whether you actually learned it. The difference is doing versus defining — the CNPE is performance-based, so it makes you configure a canary on a live cluster against the clock; the CGOA is knowledge-based, so it makes you say precisely what a canary is. You want both. The overlap runs into CNPA too: its curriculum names GitOps outright in two of six domains — Platform Engineering Core Fundamentals (36%, “Continuous Delivery and GitOps”) and Continuous Delivery & Platform Engineering (16%, “GitOps Basics and Workflows” plus “GitOps for Application Environments”) — and puts the reconciliation loop those depend on in a third, Platform APIs and Provisioning Infrastructure (12%).

When to skip it

Skip it if any of these are true. You already run GitOps at scale and can teach it — if you can explain the four principles cold and have debugged an OutOfSync app at 3am, spend the money on a performance exam instead. You need exactly one certification for a job filter — an associate GitOps badge is a weaker signal than CKA or CNPE; get the one that opens the door. You don’t work with Kubernetes — the curriculum is tool-agnostic, but the practising ecosystem is Kubernetes-shaped, and studying without a cluster to try things on is joyless.

Take it if you want a fast, cheap forcing function to master a topic that is 25% of the CNPE and roughly the same share of your working life. Just don’t mistake it for a career milestone — the certifications overview shows where it really sits.

The five official domains & their weights

☺ Like you’re 10: The test has five parts, and they’re not equal. The four rules of GitOps are the biggest part all by themselves.

These come straight from the CNCF’s published Certified GitOps Associate (CGOA) Exam Curriculum — the domain names, the percentages and the competency lists below are that document, not a paraphrase. Two housekeeping notes: we sort the domains by weight, where the official PDF prints them in a different order, and the five weights sum to exactly 100% (30 + 20 + 20 + 16 + 14), so nothing is unaccounted for. The bars are drawn to scale:

Every competency, domain by domain

The full curriculum — five domains, twenty-five competencies, exactly as the CNCF publishes them, with the pages here that cover each:

Reading the shape of this blueprint

Three things jump out. First: principles and terminology together are 50%. Four principles and nine terms — thirteen things — are worth half your score, and it is pure understanding-plus-recall, no lab required.

Second: tooling is the smallest domain at 14%, which surprises people who assume a GitOps exam is an Argo CD exam. Note too that the curriculum says “and alternatives” for both state stores and reconciliation engines: it is written against the abstraction, not the market leaders.

Third: 16% is not GitOps at all. Related Practices asks about CaC, IaC, DevOps/DevSecOps and CI/CD as disciplines in their own right — how GitOps relates to, overlaps and differs from each. Candidates who study only GitOps leave that sixth of the paper to luck; IaC & control planes and configuration & packaging cover it.

What you actually need to know

☺ Like you’re 10: Here’s the real substance — the words, the four rules, the shapes a GitOps setup can take, and the tools that do the work.

Terminology you must be able to define cold

Twenty percent of the paper is nine words. Learn them as a chain, because they describe one loop: a declarative description of the desired state lives in a state store; a reconciler performs state reconciliation against the running GitOps managed software system; when reality diverges you have state drift; the whole thing is continuous — always operating, not merely frequently triggered — and a feedback loop reports what happened so a human or machine can act; when a change is bad, rollback restores a previous desired state in the store.

Two of those trip people up. State store is not a synonym for “Git” — it is any system storing desired state with versioning and immutability. And rollback is an operation on the store: revert the commit, let the reconciler converge.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: checkout
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/platform-config.git
    targetRevision: main          # the state store pointer — roll back by reverting here
    path: apps/checkout/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: checkout
  syncPolicy:
    automated:
      prune: true                 # deletions in the store become deletions in the system
      selfHeal: true              # drift is reconciled away, continuously
  revisionHistoryLimit: 10        # retained history supports rollback

The four principles, and what breaks them

The 30% domain is four bullets, which makes it look trivial. It isn’t — you are tested on the edges. Declarative means the desired state describes the end state, not a sequence of steps; an imperative script that produces the right result still fails. Versioned and Immutable means a complete, immutable version history — a mutable “latest” bucket overwritten in place fails. Pulled Automatically means agents pull on their own; a human clicking “sync” fails, as does a pipeline pushing in. Continuously Reconciled means agents observe actual state and converge it toward desired state, indefinitely.

Note that the principles say nothing about Git, Kubernetes, YAML or pull requests — those are conventions of the dominant implementation. Answer at the level of the specification. GitOps workflows walks all four with worked failure modes.

Patterns — pull vs event-driven, and where the reconciler lives

The 20% patterns domain is the most architectural part of the exam. Three axes matter.

The same domain names deployment and release patterns and progressive delivery patterns: rolling updates, blue/green, canary, and the separation of deploy (the code is present) from release (traffic reaches it). Progressive delivery is where the reconciler hands off to a rollout controller — the desired state says “canary this,” and Argo Rollouts or Flagger executes it while watching metrics:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
spec:
  replicas: 6
  strategy:
    canary:
      steps:
        - setWeight: 10           # 10% of traffic to the new version
        - pause: { duration: 5m }
        - analysis:               # automated gate: metrics decide, not a human
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause: { duration: 5m }
  selector:
    matchLabels: { app: checkout }
  # spec.template (the pod template) is omitted here for brevity — a real
  # Rollout needs one, or a spec.workloadRef pointing at an existing Deployment

Two things to carry into the exam. The rollout object is still desired state in the store — progressive delivery does not break GitOps, it is expressed within it. And the analysis step is the feedback loop competency made concrete: the system observes the result and acts, which is why observability also appears in the tooling domain. Both patterns are unpacked in CI/CD & progressive delivery and release engineering.

Tooling — manifests, stores, engines, interoperability

The 14% is broad but shallow. Manifest format and packaging: plain YAML, Kustomize overlays, Helm charts, OCI artifacts as a distribution format. State store systems: Git primarily, but also OCI registries and object storage, judged against the versioned-and-immutable requirement. Reconciliation engines: Argo CD (application-centric, with a UI) and Flux (composable controllers), plus awareness that others exist. Interoperability: how the reconciler talks to notification systems, observability stacks and CI tools. Here is the same app in Flux, with source and interval explicit:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: platform-config
  namespace: flux-system
spec:
  interval: 1m                    # how often the source is refreshed (pull)
  url: https://github.com/acme/platform-config.git
  ref: { branch: main }
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: checkout
  namespace: flux-system
spec:
  interval: 10m                   # how often desired vs actual is reconciled
  sourceRef: { kind: GitRepository, name: platform-config }
  path: ./apps/checkout/overlays/prod
  prune: true
  wait: true                      # feedback loop: report Ready, or fail

One boundary the exam likes: CI pushes, CD pulls. The pipeline builds, tests, publishes an artifact and updates desired state in the store; the reconciler inside the target notices and converges, and the pipeline never holds cluster credentials. That sentence answers questions in three domains. Secrets follow the same logic — the reference goes in the store, never the plaintext, which is what External Secrets, Sealed Secrets and SOPS are for, and it is the DevSecOps half of Related Practices in the concrete. See secrets management.

How to prepare using this site

☺ Like you’re 10: Every part of the test already has a page here. Read them in weight order and you’ve read the syllabus.

This course was written for the CNPE, whose Domain 2 is this exam’s entire subject, so CGOA is unusually well covered. Study in weight order: principles and terminology first (50% of the paper, and they make everything else legible), then patterns, related practices and tooling.

Domain-by-domain study map

A two-week pace

Two focused weeks is enough for anyone who has used a GitOps tool; stretch to three if this is new.

Exam logistics — and how to verify them

☺ Like you’re 10: It’s an online test you take from home with someone watching through your webcam. Prices and timings change, so always check the official page before you pay.

Some facts about the CGOA are structural and safe to state; others are exactly the sort the Linux Foundation revises without announcement. This page separates them deliberately.

What the official pages state

Every figure in this table is taken from the Linux Foundation’s own CGOA exam page or the CNCF’s CGOA certification page, read in 2026 — both are linked below. Nothing here is inferred from other exams.

What is not published — and what still moves

The number people ask for constantly and that is not stated by the Linux Foundation or the CNCF is the question count. Third-party sites quote confident figures for it; those figures are unverified, so this page declines to repeat them. If you see a question count anywhere, check whether its source is the Linux Foundation — usually it isn’t.

The pass mark is a different case: it is published, just not on the CGOA product page. The Linux Foundation’s Multiple Choice Exam FAQ states that “a score of 75% or above must be earned to pass the Multiple Choice Exam”, and that applies to every Linux Foundation multiple-choice exam — CGOA included. So plan for 75%, and note that not knowing how many questions there are means you cannot count how many you can afford to lose.

One format point that is safe: because this is a knowledge-based multiple-choice exam rather than a performance-based one, the documentation allowance does not apply. The “you can browse kubernetes.io during the exam” rule that everyone repeats belongs to the hands-on Kubernetes exams; treat CGOA as closed-book and confirm the permitted-resources rules in the candidate handbook before you sit.

↗ Official CGOA page — Linux Foundation ◆ CNCF certification page ◆ Official CNCF curriculum repository ◆ OpenGitOps — the principles themselves

Where it sits in the ladder — and what to do next

☺ Like you’re 10: This is a small first badge. From here you either go deeper into building platforms, or wider across the other badges.

CGOA sits on the associate rung, next to KCNA (Kubernetes fundamentals), KCSA (security fundamentals) and CNPA (platform engineering fundamentals). None of them gate anything. The certifications overview lays out the whole shelf and the routes through it.

Go deep — the CNPE

The natural sequel. You now own a quarter of the CNPE blueprint conceptually; what remains is the other four domains and the hands. Start with the lab track, then the practice task bank — beginning with the GitOps set, where you’ll be pleasantly fast — then a timed mock exam. Keep Know It Cold open while you drill; its Argo CD and Flux manifests are the ones you’ll be writing against the clock.

Go wide, or go build

To broaden, CNPA is the obvious companion — GitOps is named in two of its six domains and the reconciliation loop in a third, so a chunk of the revision is already done — and the Kubernetes administrator track (CKA, then CKS) is what most platform roles actually screen for. To build, extend the reconciled foundation: put Crossplane claims under the same reconciler so infrastructure is GitOps too, add a policy that blocks the shortcut you keep taking, and give one team a self-service path that is nothing but a folder in the config repo. That last one is where GitOps stops being a deploy tool and becomes a platform.