CGOA: The Certified GitOps Associate Exam, Domain by Domain

The Certified GitOps Associate was launched in February 2024 by Linux Foundation Training & Certification together with the Continuous Delivery Foundation and CNCF. It is an online, proctored, multiple-choice exam of 90 minutes, priced at $250 for the exam alone, with no prerequisites, one free retake, a 12-month eligibility window and a certification valid for two years. Neither a question count nor a pass mark is published.

Five domains: GitOps Principles 30 %, GitOps Terminology 20 %, GitOps Patterns 20 %, Related Practices 16 % and Tooling 14 %. Read that list twice if you came here from Argo CD. Half the exam is the principles and the vocabulary around them, a fifth is patterns that name no product, and every reconciliation engine in existence shares one 14 % domain with manifest packaging, state stores and notification tooling.

The blueprint itself tells you where the material comes from: the Principles domain lists the four OpenGitOps principles by name, the Terminology domain lists the OpenGitOps glossary entries, and the Tooling domain names reconciliation engines as “ArgoCD, Flux, and alternatives”. In other words the syllabus is public and vendor-neutral: the principles and the glossary are short, free documents maintained by the CNCF GitOps Working Group. Gnoseed is not affiliated with CNCF, the CD Foundation or the Linux Foundation and neither sells nor proctors this exam. Verify the figures above against the official exam page before you book.

Principles and Terminology together are 50 %, and both are drawn from two short public documents. That sounds like the easiest half of any CNCF exam until you notice that a multiple-choice question can only test a definition by finding its edges — and the OpenGitOps definitions have sharp ones.

Four worth knowing exactly. “Continuous” means reconciliation keeps happening, not that it is instantaneous — so a five-minute interval is continuous and a webhook is an optimisation. A state store need not be Git: the glossary defines it as any system storing immutable, versioned desired-state declarations, with Git as the canonical example, which is why an OCI registry qualifies. Desired state is defined by completeness — the configuration sufficient to recreate the system so that instances are behaviourally indistinguishable, which is also why GitOps doubles as a disaster-recovery story. And the feedback loop is meant in the control-theory sense: how previous attempts to apply the desired state affected the actual state.

The principles themselves reward the same care. “Versioned and immutable” requires a complete version history, not merely a version number; “pulled automatically” puts software agents in charge of fetching, which is what separates GitOps from a pipeline that runs kubectl apply; and “continuously reconciled” is about observing actual state and acting, not about deployment frequency.

The GitOps track was written to teach the tools people actually run, so most of it sits outside the CGOA blueprint, and it would be dishonest to present the whole thing as exam prep. The Tooling domain covers reconciliation engines as engines, manifest formats and packaging, state store systems and interoperability with notification, observability and CI tools. It does not cover repo-server internals, what Redis caches, ApplicationSet generators, sync waves, resource hooks or hook deletion policies.

So five modules — Argo CD Core, Repo & App Patterns, Sync Strategies, Argo Rollouts and Flux & Multi-cluster — are mostly beyond what CGOA asks, together with the tool-specific half of Practical Tips. All five are excellent material for operating a cluster, and the four Argo ones — Argo CD Core, Repo & App Patterns, Sync Strategies and Argo Rollouts — are the study plan for the Certified Argo Project Associate exam instead. Flux belongs to neither blueprint.

The three modules that map onto the weight are GitOps Principles, which carries the principles and the glossary terminology, Delivery & Architecture Patterns for the 20 % patterns domain — progressive delivery, canary versus blue-green, pull versus event-driven, in-cluster versus external reconcilers, repository structure and state-store choices — and GitOps & Adjacent Practices for the 16 % that is not really about GitOps at all.

One boundary is worth drawing precisely, because the two sit next to each other. The Patterns domain names progressive delivery patterns, and that pattern layer is in Delivery & Architecture Patterns — what a canary is, what blue-green costs, what an analysis gate adds over a timed pause. The Argo Rollouts module is the layer below it: setWeight, previewService, AnalysisRun statuses, the CLI. CGOA asks about the first and not the second.

Sixteen per cent of the paper is configuration as code, infrastructure as code, DevOps and DevSecOps, and CI and CD — and how they map onto GitOps. None of these is a GitOps feature. You are expected to know the CNCF's own definitions: infrastructure as code as the practice of storing the definition of infrastructure in files; DevSecOps as a cultural merger of development, operational and security responsibilities; continuous delivery as automation into an acceptance environment, with continuous deployment going the step further to production.

The mapping questions are the interesting ones. IaC gives you a declarative definition under version control; GitOps adds an agent that keeps reconciling it, which is why an apply in a pipeline converges only while the pipeline runs and drift between runs goes unnoticed. That distinction is the single most exam-shaped idea in the domain.

It is also why the study plan on this page spans three decks. The GitOps deck now carries the mapping cards, while the Terraform track is where infrastructure as code becomes concrete and the GitHub Actions track is where CI stops being an abstraction. If you already write both daily, skip them.