Key takeaways
- GitOps Principles is 30% of the exam and has only four topics: declarative, versioned and immutable, pulled automatically, continuously reconciled.
- The OpenGitOps glossary is the single best reading; many options differ by one term such as drift, desired state or state store.
- Continuous means reconciliation keeps happening, not that it is instantaneous; a state store does not have to be Git.
- Tooling questions are about categories of tools, with Argo CD and Flux as the named reconcilers, not product syntax.
- At 75% you need about 45 of 60 correct, with roughly 90 seconds per question.
On this page
What CGOA tests, in numbers
CGOA is delivered online with a remote proctor. It has 60 questions, 90 minutes and a 75% pass mark; the list price is $250 and the certification is valid for 2 years. The five domains below come from the CNCF curriculum.
| Domain | Weight | Curriculum topics |
|---|---|---|
| GitOps Terminology | 20% | Continuous; declarative description; desired state; state drift; state reconciliation; GitOps managed software system; state store; feedback loop; rollback |
| GitOps Principles | 30% | Declarative; versioned and immutable; pulled automatically; continuously reconciled |
| Related Practices | 16% | Configuration as code; infrastructure as code; DevOps and DevSecOps; CI and CD |
| GitOps Patterns | 20% | Deployment and release patterns; progressive delivery; pull vs event-driven; architecture patterns |
| Tooling | 14% | Manifest format and packaging; state store systems; reconciliation engines; interoperability with notifications, observability and CI |
The four principles, and what breaks each one
OpenGitOps defines four principles for the desired state of a GitOps-managed system. Questions often describe a setup and ask which principle it satisfies or violates, so learn each principle together with a setup that breaks it.
| Principle | Meaning | A setup that breaks it |
|---|---|---|
| Declarative | The desired state is expressed declaratively | A shell script in Git that runs kubectl commands in order |
| Versioned and immutable | The desired state is stored with immutability, versioning and a complete history | Configuration edited in place on a shared drive without history |
| Pulled automatically | Software agents pull the desired state from the source | A CI job that pushes manifests to the cluster only after a commit |
| Continuously reconciled | Agents continuously observe actual state and try to apply the desired state | A one-off apply with no agent watching for drift |
The glossary terms worth knowing word for word
The GitOps Terminology domain lists nine terms, and the OpenGitOps glossary defines most of them. Options often differ by a single word, so learn the definitions precisely.
- Continuous: reconciliation continues to happen; it does not have to be instantaneous.
- Declarative description: the desired operating state without the procedure to reach it, separating configuration from commands, API calls and scripts.
- Desired state: all configuration data sufficient to recreate the system; it generally excludes persistent application data such as database contents.
- Drift: the actual state has moved, or is moving, away from the desired state.
- Reconciliation: making actual state match desired state, triggered by any divergence, not only by a new commit.
- State store: a system for storing immutable versions of desired state, with access control and auditing; Git is the common example, not a requirement.
- Feedback: how earlier attempts to apply the desired state affected the actual state; an agent may add resources, roll back or alert a human.
Related practices: where GitOps starts and stops
Related Practices is 16% of the exam and asks how GitOps fits beside configuration as code, infrastructure as code, DevOps, DevSecOps and CI/CD. The usual question is where continuous integration ends and GitOps delivery begins. In a GitOps setup, CI builds and tests an artifact and updates the desired state; a reconciler pulls that state and applies it. CI does not push to the cluster.
- A developer merges a change; CI builds, tests and publishes an image.
- CI or a person updates the image reference in the desired-state repository.
- The reconciler notices the new version on its next poll or webhook and applies it.
- If someone changes the cluster by hand, the reconciler detects drift and, if configured, reverts it.
Patterns and tooling
Pattern questions ask which approach fits a situation: how releases are rolled out, whether reconciliation is pull-based or event-driven, and where the reconciler runs. Tooling questions ask what each category of tool contributes. The documented behaviour of the two reconcilers the curriculum names is a useful set of concrete examples.
| Behaviour | Argo CD | Flux |
|---|---|---|
| How often it checks the source | Polls Git every 3 minutes by default (120 seconds plus up to 60 seconds of jitter) | Set by the required interval field on each Kustomization |
| Deleting resources removed from Git | Automated sync does not delete them unless pruning is enabled | prune is a required boolean on each Kustomization |
| Reverting manual changes in the cluster | Live changes do not trigger automated sync unless self-heal is enabled | Each interval applies the Kustomization again, correcting drift in the process |
Traps in the options
Most CGOA options are reasonable statements about software delivery. Only one matches the OpenGitOps definitions. These are the patterns behind most wrong answers.
- Equating GitOps with Git: any state store that keeps immutable, versioned, auditable desired state qualifies.
- Calling a push pipeline GitOps because the manifests live in Git.
- Reading continuous as instantaneous.
- Assuming reconciliation runs only after a commit; drift triggers it too.
- Putting database contents into desired state.
- Calling a versioned script declarative.
A two-week CGOA plan
CGOA rewards precise vocabulary more than volume, so the plan starts with the principles and the glossary and then moves to scenarios. GoldenKube has 280 CGOA questions; bookmark every question where two options both sounded right, because those are the term pairs you still confuse.
| Days | Work | Milestone |
|---|---|---|
| 1-2 | Read the principles and the glossary; questions on principles and terminology | You can state all four principles from memory |
| 3-5 | Related practices: CaC, IaC, DevOps, DevSecOps, CI and CD | You can draw where CI ends and the reconciler starts |
| 6-8 | Patterns and tooling; optionally run Argo CD or Flux on a local cluster and cause drift | You can explain pruning, self-heal and polling in your own words |
| 9 | First timed mock exam | Weakest domain identified |
| 10-13 | Due reviews and bookmarks, then new questions in the weakest domain | No domain below the pass mark on new questions |
| 14 | Second timed mock and a final read of the principles | Two mocks above the pass mark |
The terms in one worked example
Definitions stick better when they describe one system you can picture. Take a team that keeps the manifests for a web service in a Git repository and runs a reconciler in the cluster. Every glossary term in the curriculum maps onto something in that setup, and walking through it once makes most terminology questions easier to answer.
Two details in this example catch people out. First, the manual scale is drift even though no file changed, so reconciliation is triggered by divergence, not only by commits. Second, whether the reconciler reverts the manual change depends on its configuration: Argo CD does not act on live changes unless self-heal is enabled, while a Flux Kustomization corrects drift on every interval.
| Term | In the example |
|---|---|
| Declarative description | The Deployment, Service and ConfigMap files say what should run, not how to start it |
| Desired state | All of those files together, enough to recreate the service; the database contents are not part of it |
| State store | The Git repository, with history, access control and review on every change |
| Pulled automatically | The reconciler in the cluster fetches the repository; nothing outside pushes to the cluster |
| Drift | Someone scales the Deployment by hand, so the cluster no longer matches the files |
| Reconciliation | The reconciler notices the difference and applies the files again, with or without a new commit |
| Feedback loop | The reconciler reports the result; if a rollout fails it can alert a human or roll back |
| Rollback | Reverting the commit returns the desired state to the previous version, and the reconciler follows |
Frequently asked questions
Is CGOA a hands-on exam?
No. CGOA is multiple-choice and tests concepts: the principles, the terminology, patterns and the role of tools. Running Argo CD or Flux on a local cluster still helps, because seeing a reconciler correct drift makes the terms concrete.
Do I need to know Argo CD or Flux in detail?
The curriculum names reconciliation engines such as Argo CD and Flux under Tooling, but it does not list product commands or fields. Know what a reconciler does, how it is triggered and the main design choices such as pruning, self-healing and polling intervals; leave product syntax to CAPA.
What is the single most useful reading for CGOA?
The OpenGitOps principles and glossary. The principles fit on one page, and the glossary defines most of the terms in the GitOps Terminology domain, including desired state, drift, reconciliation, state store and feedback loop.
How long should I study for CGOA?
The Linux Foundation does not publish a recommended preparation time. The two-week plan here assumes a few hours a week and some delivery experience; people new to CI/CD and infrastructure as code should add a week for the Related Practices domain.
What is the difference between CGOA and CAPA?
CGOA is about GitOps as a practice, independent of any tool. CAPA is about the Argo project: Argo CD, Workflows, Rollouts and Events, with product-level detail. The comparison page shows how they fit together.
Does CGOA count toward Golden Kubestronaut?
Yes, CGOA is on the Golden Kubestronaut list and has no prerequisite.
Is GitOps the same as continuous deployment?
Not exactly. Continuous deployment describes releasing every change automatically; GitOps describes how the desired state is stored, pulled and reconciled. A GitOps system can deploy continuously, but it can also wait for a human to merge a change. The Related Practices domain asks about this boundary.
Sources
Every exam fact on this page comes from these pages, read on the date shown.
- Linux Foundation: Certified GitOps Associate (CGOA) certification page, checked
- CNCF curriculum: CGOA Curriculum (PDF), checked
- Multiple-choice exam instructions, Linux Foundation certification docs, checked
- Multiple-choice exam FAQ, Linux Foundation certification docs, checked
- OpenGitOps: GitOps Principles (open-gitops/documents), checked
- OpenGitOps: Glossary (open-gitops/documents), checked
- OpenGitOps project site, checked
- Argo CD docs: FAQ, checked
- Argo CD docs: Automated sync policy, checked
- Flux docs: Kustomization, checked