Domain 1: GitOps Terminology
- Declarative configuration describes the desired end state of a system - what should exist - rather than an imperative script that lists the ordered steps to reach it.
- Desired state (also called target state) is the intended configuration recorded in a versioned definition, such as a manifest, independent of what is currently running.
- Actual state (also called live state or observed state) is what is truly running in the target environment at a given moment, and it is compared against desired state to detect differences.
- The state store is the versioned system of record that holds the desired state; in most GitOps implementations this is a Git repository, though OpenGitOps does not require Git specifically.
- Reconciliation is the continuous process of comparing actual state to desired state and taking action to converge the two, driven by a software agent rather than a human running commands.
- Drift is any difference between actual state and desired state, whether caused by a manual change, an external actor, or an environment failure.
- A feedback loop closes the gap between intent and reality: the reconciler observes actual state, compares it to desired state, and repeatedly acts until they match.
- Rollback in GitOps means reverting the desired state definition (for example, a Git revert) to a prior known-good version, which the reconciler then applies automatically.
- The agent, also called a controller or reconciler, is the software component that pulls the desired state and continuously works to make actual state match it.
- Traditional imperative operations push changes to a target using ad hoc scripts or manual commands, while GitOps operations are driven by pulling a declared, versioned state and reconciling continuously.
Domain 2: GitOps Principles
- OpenGitOps v1.0 defines exactly four principles a system must meet to be considered GitOps: Declarative, Versioned and Immutable, Pulled Automatically, and Continuously Reconciled.
- Declarative: the desired state of the entire managed system must be expressed declaratively as data, not as a sequence of imperative instructions, so it can be interpreted and applied by software.
- Versioned and Immutable: desired state is stored in a way that enforces immutability, versioning, and a complete version history, such as a Git repository, providing a full audit trail and an easy rollback point.
- Pulled Automatically: software agents automatically pull the desired state declarations from the state store, rather than an external system pushing changes into the environment.
- Continuously Reconciled: software agents continuously observe actual system state and act to apply the desired state, correcting drift automatically without waiting for a scheduled or manual trigger.
- The Declarative principle requires describing the entire system's desired state, not just a subset such as application manifests, so that drift in any component can be detected and corrected.
- The Versioned and Immutable principle is what gives GitOps auditability and safe rollback: every change is a new, immutable, versioned commit rather than an in-place edit.
- Pull-based delivery improves security because the target environment's own credentials never need to be shared with an external CI/CD system pushing changes in.
- Continuous reconciliation means the agent keeps checking and correcting even when no new commit has been made, so it also repairs unauthorized manual, out-of-band changes.
- A file merely being stored in Git does not automatically satisfy the Declarative principle; an ordered list of imperative commands committed to Git is still imperative, not declarative.
- OpenGitOps is the CNCF Sandbox project and GitOps Working Group effort that formally defines these four principles as the vendor-neutral definition of GitOps.
Domain 3: Related Practices
- Continuous Integration (CI) is the practice of frequently merging code changes and automatically building and testing them, producing verified artifacts before delivery or deployment.
- Continuous Delivery keeps every change that passes automated tests release-ready but still requires a manual decision or approval gate before it reaches production.
- Continuous Deployment removes that manual gate: every change that passes automated checks is released to production automatically.
- GitOps is one way to implement continuous delivery, and can extend to continuous deployment; it does not replace CI, which remains responsible for building, testing, and producing artifacts and manifests.
- DevOps is the broader cultural and organizational movement emphasizing collaboration between development and operations, automation, and continuous feedback; GitOps operationalizes several DevOps ideas through Git-based workflows.
- Infrastructure as Code (IaC) manages infrastructure through machine-readable definition files rather than manual processes; GitOps builds on IaC by adding automated, continuous reconciliation of that declared infrastructure.
- Progressive delivery techniques such as canary releases and blue-green deployments can be driven through GitOps by declaring the desired rollout state and letting a controller manage the transition.
- Push-based pipelines have an external CI/CD system push changes into the target environment, requiring it to hold deployment credentials; GitOps pipelines instead have an in-cluster agent pull and apply changes.
- Pull requests used for application code review are reused for operational changes in GitOps, giving infrastructure and configuration changes the same review rigor as software changes.
- DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) are commonly used to measure the delivery performance that GitOps practices aim to improve.
- Policy as code and secrets management are complementary practices often layered onto a GitOps workflow to enforce compliance and avoid storing plaintext credentials in the state store.
Domain 4: GitOps Patterns
- A monorepo stores manifests for multiple applications or services in a single repository, enabling atomic, coordinated cross-service changes in one commit and centralizing shared tooling.
- A polyrepo layout gives each application or team its own repository, naturally containing blast radius to a single service and letting standard repository-level permissions express team boundaries.
- Because most Git hosting permission models grant access at the whole-repository level, a monorepo needs extra folder-scoped tooling, such as CODEOWNERS-based required reviewers, to approximate per-team access control.
- The app repo vs config repo pattern separates application source code, built and tested by CI, from the repository of rendered or templated manifests that the GitOps agent actually watches and syncs.
- Splitting app and config repositories keeps the reconciler's watch target focused on deploy-worthy changes and avoids triggering unnecessary syncs on unrelated application-development commits.
- Environment promotion can be modeled as branch-per-environment, such as dev, staging, and prod branches, or as directory/overlay-per-environment within one branch, commonly implemented with overlays.
- The rendered-manifests pattern has CI expand templates, such as charts or overlays, into plain, fully rendered manifests before committing them, so the GitOps agent applies static, easily diffable YAML.
- Secrets in a GitOps repository are typically handled with encryption-at-rest-in-Git tools like Sealed Secrets or SOPS, or with runtime injection tools like an External Secrets Operator or Vault, rather than storing plaintext secrets.
- Multi-cluster and multi-tenancy patterns use a single set of Git repositories to declare desired state for many clusters or tenants, with the reconciler mapping each target destination to its portion of the desired state.
- Progressive delivery via GitOps declares rollout strategy and traffic-shifting steps, such as canary weights, as part of the desired state, letting a controller execute and reconcile the rollout automatically.
- Reconciliation-loop design choices, such as polling interval versus event-triggered syncs, and how aggressively to self-heal manual drift, are recurring engineering trade-offs in GitOps pattern selection.
Domain 5: Tooling
- Argo CD and Flux are the two GitOps reconciler projects that have reached CNCF Graduated status, the highest CNCF maturity level, reflecting broad production adoption.
- Argo CD is a declarative GitOps continuous delivery tool for Kubernetes; its core reconciliation unit is the Application, which ties a source (repository, path, revision) to a destination (cluster, namespace).
- Argo CD's application-controller runs as an in-cluster Kubernetes controller that continuously compares live state to desired state and executes syncs; the repo-server clones and renders manifests, and the api-server serves the UI, CLI, and API.
- Argo CD supports both manual sync, which requires explicit initiation, and automated sync, plus self-heal, which corrects manual drift back to the Git-defined state, and prune, which removes resources no longer present in the source.
- Argo CD tracks two independent statuses per Application: sync status, whether live state matches Git, and health status, whether the resource is actually functioning.
- Flux is a set of Kubernetes controllers, including source, kustomize, helm, and notification controllers, that pull declared state from Git or other sources and reconcile it into the cluster.
- Both Argo CD and Flux support common templating and packaging tools such as Kustomize, Helm, and Jsonnet as sources for the manifests they reconcile.
- Policy-as-code tools such as OPA/Gatekeeper and Kyverno are commonly layered on top of a GitOps pipeline to validate or enforce rules on manifests before or during admission.
- AppProject in Argo CD provides a logical, RBAC-scoped boundary that restricts which repositories, clusters, and resource kinds a group of Applications may use.
- Selecting GitOps tooling typically weighs criteria such as the multi-tenancy and RBAC model, multi-cluster support, templating engine support, UI/observability, and how the tool implements pull-based reconciliation and drift correction.
- The CNCF landscape and the GitOps Working Group, which authored OpenGitOps, provide the vendor-neutral frame for evaluating GitOps tools against the four core principles rather than against any single vendor's implementation.
Certified GitOps Associate (CGOA) exam tips
- Memorize the four OpenGitOps principles exactly: Declarative, Versioned and Immutable, Pulled Automatically, and Continuously Reconciled - and be ready to match a described scenario to the principle it satisfies or violates.
- Know pull vs push precisely: a GitOps agent pulls desired state from the repository, unlike traditional CD tooling that pushes changes into the environment; this distinction is heavily tested through scenario questions.
- Be able to distinguish desired/target state from actual/live/observed state in your own words, and explain reconciliation and drift as the mechanism and the problem they address.
- Argo CD and Flux are both CNCF Graduated and vendor-neutral; do not assume the exam favors one over the other - questions test general reconciler concepts (source, destination, sync, self-heal, prune) that apply to either.
- Understand how GitOps relates to but does not replace CI/CD: CI still builds, tests, and produces artifacts and manifests, and GitOps then handles the continuous-delivery and reconciliation half of the pipeline.
Study guide FAQ
What format and passing requirements does the CGOA exam have?
The CGOA is a multiple-choice, online proctored exam lasting about 90 minutes with 60 questions. It uses a scaled score and the passing score is 750 out of 1000, roughly 75%. There is no hands-on lab component.
What are the four OpenGitOps principles tested on the CGOA?
OpenGitOps v1.0 defines four principles: Declarative (desired state expressed as data), Versioned and Immutable (state stored with full history, such as in Git), Pulled Automatically (agents pull rather than being pushed to), and Continuously Reconciled (agents continuously correct drift). Expect scenario questions asking which principle a described practice satisfies or violates.
Is CGOA tied to a specific vendor or tool like Argo CD or Flux?
No. CGOA is a vendor-neutral CNCF exam built around the OpenGitOps definition of GitOps. The Tooling domain does cover Argo CD and Flux as the two CNCF Graduated reconcilers, but most of the exam tests concepts, terminology, and patterns that apply regardless of which tool implements them.
What prerequisites or experience are recommended before taking CGOA?
CGOA is an associate-level exam aimed at practitioners new to GitOps; there is no formal prerequisite certification, but familiarity with Git, basic Kubernetes concepts, and a typical CI/CD pipeline will make the terminology and patterns much easier to absorb.
How does GitOps relate to CI/CD and DevOps on the exam?
Expect questions distinguishing GitOps from CI, which still builds, tests, and produces artifacts, from continuous delivery versus deployment (a manual gate versus none), and from push-based pipelines. GitOps is presented as an operational pattern that implements continuous delivery or deployment using pull-based, declarative reconciliation.