Free CGOA (Certified GitOps Associate) practice: the 5 official domains, exam-style questions, a timed practice exam and more.
Play the CGOA map → · Official CGOA exam page
Desired state, state drift, reconciliation, state store, feedback loop, rollback
Declarative, versioned and immutable, pulled automatically, continuously reconciled
Configuration as Code, Infrastructure as Code, DevOps and DevSecOps, CI and CD
Deployment, release and progressive delivery patterns, pull vs event-driven, architecture
Manifest formats and packaging, state stores, reconciliation engines, integrations
Answer: The aggregate of configuration data sufficient to recreate the system. It excludes persistent application data such as database contents.
Answer: How the running system currently is. Reconciliation compares actual with desired state.
Answer: Actual state moving away from desired state. Drift can come from manual changes, failures or other actors.
Answer: The process of ensuring actual state matches desired state. It is triggered whenever there is a divergence.
Answer: A system storing immutable versions of desired state declarations. Git is the canonical example; access control and auditing are required.
Answer: Reconciliation keeps happening — not that it must be instantaneous. The glossary defines "continuous" to match industry use.
Answer: Configuration describing the desired operating state without the procedure to reach it. It separates configuration from implementation.
Answer: How previous attempts to apply desired state affected actual state, informing the next action. GitOps follows control theory and operates in a closed loop.
Answer: Runtime environments with the resources under management; Management agents within each runtime; Policies controlling access to repositories and runtimes. These three parts are listed in the OpenGitOps glossary.
Answer: Software agents fetch desired state from the state store themselves. Agents must be able to access the state store at any time.
Answer: Any divergence — a new desired state or unintended drift. This is what distinguishes GitOps from trigger-driven CI/CD.
Answer: Declaring a previous desired state (e.g. reverting a commit). The agent then reconciles to it.
Answer: Immutable history, access control, auditing and review workflows. Pull requests add review before desired state changes.
Answer: The rows stored in a production database. Persistent application data is generally excluded.
Answer: Software that observes actual state and applies desired state. Argo CD and Flux controllers are reconcilers.
Answer: A target runtime (e.g. staging, production) with its own desired state. Environments are usually separate folders, overlays or repos.
Answer: Four. Declarative, Versioned and Immutable, Pulled Automatically, Continuously Reconciled.
Answer: Principle 1: Declarative. A system managed by GitOps must have its desired state expressed declaratively.
Answer: Versioned and Immutable. Desired state is stored immutably, with complete version history.
Answer: Declarative. Imperative steps describe how, not what.
Answer: Versioned and Immutable. Changes must go through the versioned, immutable state store.
Answer: Pulled Automatically. Agents should pull desired state rather than having it pushed in.
Answer: Continuously Reconciled. Agents continuously observe actual state and attempt to apply desired state.
Answer: The runtime does not need to expose credentials or inbound access to an external pusher. Credentials stay inside the environment being managed.
Answer: You can see exactly what changed and when, and revert to a known-good version. Version history is an audit trail.
Answer: A Kubernetes Deployment manifest. It describes the end state.
Answer: No — the principles apply to any system whose desired state can be declared and reconciled. Kubernetes is the most common target because its API is declarative.
Answer: No — any state store that is versioned and immutable with access control can work. OCI registries and buckets are used too.
Answer: The agent recreates it. Actual state is driven back to desired state.
Answer: Changes only through commits/PRs; protected branches; no force-pushes. History must be complete and tamper-evident.
Answer: Secrets would be exposed — encrypt them (e.g. SOPS, Sealed Secrets) or reference an external store. Desired state can include references to secrets without the plaintext.
Answer: Webhooks that notify the agent to pull sooner. A notification still results in the agent pulling.
Answer: All four must hold together for a system to be GitOps. OpenGitOps defines GitOps as the set of these principles.
Answer: They become drift — capture the fix in the state store or the agent will revert it. Many teams pause auto-sync deliberately during incidents and then commit the fix.
Answer: Report the failure through feedback and keep trying/alerting. Feedback closes the loop for humans and automation.
Answer: Reviewers see the intended end state, not a sequence of side effects. Diffs of desired state are meaningful in pull requests.
Answer: A given version of desired state never changes; new changes create new versions. Tags and commits identify exact states.
Answer: Declarative (together with a versioned state store). If the full desired state is declared, a new environment can be reconciled from it.
Answer: In the state store (e.g. a commit changing replicas). Otherwise it is drift and will be reverted.
Answer: Both observe actual state, compare with desired state and act — GitOps applies it to the whole system. Kubernetes is itself built on reconciliation loops.
Answer: Managing infrastructure through machine-readable definition files. Terraform, OpenTofu, Pulumi and Crossplane are common tools.
Answer: GitOps adds versioned storage, pull-based delivery and continuous reconciliation to IaC definitions. IaC alone may still be applied manually or by push.
Answer: Managing application and system configuration as versioned files. Same review and history practices as application code.
Answer: Integrating security practices into the whole development and operations lifecycle. Security checks run in pipelines and as policies.
Answer: Pull requests, signed commits and policy checks on desired state before it is applied. Every change is reviewable and auditable.
Answer: Tested, versioned artifacts (images) and updates to desired state. CI builds; the GitOps agent deploys.
Answer: Keeping software always in a releasable state and delivering it through automation. GitOps is one way to implement CD.
Answer: Every change that passes the pipeline goes to production automatically. Continuous delivery may keep a manual approval before production.
Answer: Small, frequent changes with automated tests. Smaller changes are easier to review and roll back.
Answer: Different change cadences and access rights; CI updates config without touching app code. It is a common pattern, not a principle.
Answer: Expressing rules (security, compliance) as versioned code that is evaluated automatically. OPA/Gatekeeper and Kyverno are examples.
Answer: Linters and policy checks (e.g. kubeconform, conftest, kyverno CLI). Shift-left validation catches errors early.
Answer: Gradually exposing a new version while measuring it, with automatic rollback. Canary, blue-green and feature flags are progressive delivery techniques.
Answer: Argo Rollouts; Flagger. Both automate traffic shifting and analysis.
Answer: A runtime switch that turns functionality on or off without redeploying. It decouples release from deployment.
Answer: Deployment puts code into an environment; release exposes it to users. Progressive delivery and feature flags exploit the difference.
Answer: Polling adds some latency but catches drift and missed events. Most tools combine both: webhooks for speed, a polling interval as the safety net.
Answer: A central management cluster runs the reconciler for many target clusters. Central view, but the hub holds credentials to every spoke.
Answer: Smaller blast radius and no inbound credentials from outside. Each cluster pulls its own desired state.
Answer: A pull request that updates production’s desired state (e.g. image tag). The same artifact moves through environments.
Answer: Branches drift apart and merges become error-prone; folders/overlays are easier to compare. Directory-per-environment keeps all environments visible in one place.
Answer: All environments and apps in one repository, separated by directories. Polyrepo splits by team or app instead; both are valid.
Answer: An image automation controller detects new tags and commits the update to Git. Flux image automation and Argo CD Image Updater do this.
Answer: Comparing metrics of the new version against thresholds or the baseline to decide promotion. Failing analysis triggers an automatic rollback.
Answer: Encrypted (SOPS, Sealed Secrets) or referenced from an external secret manager. The repository may be widely readable.
Answer: Ordering mechanisms such as sync waves (Argo CD) or dependsOn (Flux Kustomization). Reconcilers apply in a defined order.
Answer: Proving production matches the approved, versioned configuration. Drift is visible in the reconciler’s status.
Answer: A webhook or event tells the reconciler that new desired state exists. The reconciler still pulls the state itself.
Answer: GitRepository. Kustomization and HelmRelease consume sources such as GitRepository and OCIRepository.
Answer: Kustomization (kustomize.toolkit.fluxcd.io). It is Flux’s own CRD, distinct from Kustomize’s kustomization.yaml.
Answer: HelmRelease. HelmRepository or OCIRepository is the chart source.
Answer: Application. ApplicationSet generates many Applications.
Answer: Helm charts; Kustomize overlays; Plain YAML. Reconcilers render them into Kubernetes manifests.
Answer: SOPS. Flux decrypts SOPS natively; Argo CD via plugins.
Answer: A SealedSecret that only the in-cluster controller can decrypt into a Secret. The encrypted SealedSecret is safe to commit; only the cluster holds the private key.
Answer: notification-controller (Provider and Alert resources). It also handles incoming webhooks (Receiver).
Answer: flux bootstrap. Flux then manages itself from the repository.
Answer: Argo CD; Flux. Both are graduated CNCF projects.
Answer: Exposing metrics and events about sync status and reconciliation errors. Alert on failed or long-pending reconciliations.
Answer: State drift. Drift is the gap between actual and desired state; reconciliation is what removes it.
Answer: Revert the change in the state store and let the reconciler apply it. Desired state is the source of truth; changing the cluster directly would just be drift.
Answer: Declarative; Versioned and immutable; Pulled automatically; Continuously reconciled. OpenGitOps v1.0.0 defines exactly these four principles.
Answer: Cluster credentials stay inside the cluster instead of in the external CI system. With pull, the agent reaches out; no outside system needs write access to the environment.
Answer: Continuously reconciled. Drift with no new commit would never be corrected — reconciliation must be continuous.
Answer: Build and test, publish the artifact, then update the desired state (e.g. bump the image tag). CI produces artifacts and changes the state store; the GitOps agent handles deployment.
Answer: Infrastructure as Code. IaC defines infrastructure in versioned files; GitOps can then reconcile it.
Answer: It catches drift and missed webhooks, keeping reconciliation continuous. Event-driven gives speed; the periodic loop is the safety net.
Answer: Progressive delivery (canary with automated analysis). Argo Rollouts and Flagger implement this pattern on top of GitOps.
Answer: Argo CD; Flux. Jenkins is CI; Prometheus is monitoring. Argo CD and Flux are CNCF graduated GitOps tools.
Answer: An OCI registry holding versioned, immutable artifacts. Any store with versioned, immutable history works; Flux and Argo CD can read OCI artifacts.