CGOA Practice Questions

Twenty-five single-best-answer questions, built the way the real CGOA builds them: one stem, four options, exactly one option that answers this stem better than the other three. They are split across all five domains from the CGOA blueprint in rough proportion to their weight — seven on Principles, five each on Terminology and Patterns, four each on Related Practices and Tooling — so a strong or weak score in one section tells you something real about where your marks would actually land. This page is untimed and open-book on purpose: work through it slowly, read every explanation even for questions you got right, and only once these twenty-five stop surprising you should you move on to the two full, weighted, timed papers — Mock Exam · Set 1 and Mock Exam · Set 2.

How this bank is built

☺ Like you're 10: The biggest pile of questions covers the biggest part of the real test. Study in that order and you're spending your time where the marks actually are.

The CGOA curriculum weights its five domains 30 / 20 / 20 / 16 / 14, and this bank mirrors that shape rather than splitting twenty-five questions evenly into five piles of five. Principles gets the largest single share; Related Practices and Tooling — the two domains people most often skip because they don't sound like "real GitOps" — still get a full four questions each, because together they're 30% of the real paper.

GitOps Principles — 7 questions

☺ Like you're 10: Four rules, but the test cares about the edges — the workflow that follows three rules perfectly and quietly breaks the fourth.

Thirty percent of the real exam is these four rules — Declarative, Versioned and Immutable, Pulled Automatically, Continuously Reconciled — worked against the reference in the CGOA blueprint. Score each scenario against all four before you pick an answer; the trap is almost always a workflow that satisfies two or three convincingly and fails one quietly.

Q1. Which of the following most precisely defines the Declarative principle?

• A. A description of the desired end state of a system, independent of the sequence of steps used to reach it.
• B. An ordered script of commands that, when run in sequence, produces the correct result.
• C. Configuration that is written once and is never touched or updated again.
• D. Any file written in YAML, regardless of what it describes.

Q2. A team's infrastructure changes are stored as Terraform HCL and .tfvars files in Git, reviewed by pull request. A Jenkins job, running on a fixed 15-minute schedule regardless of whether Git has changed, checks out the repository and runs terraform apply using a service credential stored in Jenkins. Which principle does this setup most clearly fail?

• A. Declarative — Terraform HCL describes steps, not end state.
• B. Versioned and Immutable — Jenkins overwrites the Git history on every run.
• C. Pulled Automatically — an external system (Jenkins) applies changes from outside using its own stored credential, rather than an agent inside the system autonomously pulling and applying its own desired state.
• D. Continuously Reconciled — a fixed 15-minute schedule is not frequent enough to count as continuous.

Q3. A platform stores its entire desired-state configuration as a single object named desired-state-latest.json in an object storage bucket. Every change overwrites that object in place; the bucket retains no prior versions. Which principle does this fail, and why?

• A. Declarative — JSON cannot express desired end state.
• B. Versioned and Immutable — there is no retained history to audit, diff, or revert to; each write destroys the one before it.
• C. Pulled Automatically — object storage cannot be polled by an agent.
• D. Continuously Reconciled — the object could still be watched on an interval.

Q4. A checkout service's manifests live in Git; an in-cluster reconciler applies them with selfHeal disabled and syncs only on a manual click in the reconciler's UI. Which principle does this most directly fail?

• A. Declarative — manual syncing implies imperative operation.
• B. Versioned and Immutable — a manual click cannot be versioned.
• C. Pulled Automatically — the agent is technically pulling from Git, but only because a human triggered it; nothing is happening autonomously.
• D. Continuously Reconciled — because selfHeal is off, drift between syncs is never corrected, and a human clicking "sync" is not an autonomous, ongoing process.

Q5. In an Argo CD Application's syncPolicy, which single sync option most directly operationalizes the Continuously Reconciled principle?

• A. prune: true — removes live resources whose manifests were deleted from Git.
• B. selfHeal: true — reverts any change made directly against the live resource back to what Git specifies, on an ongoing basis.
• C. retry.limit — controls how many times a failed sync attempt is retried.
• D. revisionHistoryLimit — controls how many prior revisions are retained for rollback.

Q6. Which statement, if true of a system, would mean it fails Pulled Automatically even though it fully satisfies the other three principles?

• A. A person must click a "Sync" button in a UI every time they want the live system to move toward the desired state in Git.
• B. The reconciling agent polls the state store every 3 minutes instead of every 30 seconds.
• C. The state store retains an unlimited, uncapped commit history.
• D. A bad change is rolled back by reverting the offending commit rather than editing the live system directly.

Q7. Which of the following is NOT required by the Continuously Reconciled principle?

• A. That the agent periodically or continuously compares live state against desired state.
• B. That drift is corrected without a human having to re-trigger the process each time.
• C. That reconciliation happen with zero latency, instantaneously, on every single change to the live system.
• D. That the loop keeps running indefinitely, rather than stopping after a single successful pass.

GitOps Terminology — 5 questions

☺ Like you're 10: Nine words, worth a fifth of the whole test — and the exam checks whether you know exactly what each one means, not just whether you've heard it before.

Twenty percent of the paper is nine terms: continuous, declarative description, desired state, state drift, state reconciliation, GitOps managed software system, state store, feedback loop, rollback. These questions test the precise boundary of each — the place where an everyday habit ("I fixed it by editing the live thing") turns out not to match the term you'd reach for first.

Q8. A team keeps its Kubernetes manifests as signed OCI artifacts in a container registry rather than in a Git repository. Every push creates a new immutable tag, and full pull history is retained. Does this qualify as a valid state store under the CGOA curriculum?

• A. No — only Git repositories can be GitOps state stores.
• B. Yes — the definition requires only that desired state be stored with versioning and immutability; Git is the common implementation, not the requirement.
• C. No — OCI registries can only store container images, never configuration.
• D. Yes, but only if the reconciler in use is specifically Argo CD.

Q9. A Deployment's live replica count reads 6. The manifest for that Deployment, committed in Git, specifies replicas: 3. What term precisely names this condition, independent of how it was caused?

• A. Rollback
• B. State drift
• C. Feedback loop
• D. State reconciliation

Q10. A bad image tag reaches production. The on-call engineer runs kubectl set image deployment/checkout checkout=app:v41 directly against the live cluster, restoring the previous good tag by hand. In strict GitOps terms, was this a rollback?

• A. Yes — the running system now matches the previous good state.
• B. No — a rollback is an operation performed on the state store, typically by reverting the offending commit; this was a manual, out-of-band change to the live system, and it will itself register as state drift the moment the reconciler next compares live state to the still-broken desired state in Git.
• C. Yes, because kubectl is the standard tool for performing GitOps rollbacks.
• D. No, because rollbacks can only be performed with helm rollback.

Q11. In OpenGitOps terminology, what is the primary purpose of a feedback loop?

• A. To let a human review a pull request before it merges.
• B. To automatically squash and compress historical commits in the state store.
• C. To report the outcome of reconciliation — success, failure, or drift detected — back to an operator or another system, so that action can be taken.
• D. To rate-limit how frequently a reconciler is permitted to pull from the state store.

Q12. A reconciler is configured to run terraform plan && terraform apply once every 24 hours via a cron job, regardless of whether the state store changed. Compared to a reconciler that polls the state store every 3 minutes and applies only when a difference is detected, which statement best captures the terminology distinction the CGOA curriculum draws around the word continuous?

• A. Both are equally "continuous" — the word simply means "automatic," and both run without a human triggering them.
• B. "Continuous" describes an ongoing, unattended process that keeps operating rather than one that runs once and stops; a once-daily batch job sits much closer to periodic batch reconciliation than to the tight, always-operating loop the term is meant to describe, even though both jobs are automatic in the sense that nobody clicks a button.
• C. "Continuous" specifically means a polling interval of three minutes or faster; anything slower does not count.
• D. "Continuous" only applies to observability pipelines, not to reconciliation engines.

GitOps Patterns — 5 questions

☺ Like you're 10: A checking-robot can wait for a phone call or just keep glancing on its own, and the robot itself can live inside the room it watches, or sit outside watching several rooms at once.

The 20% Patterns domain is the most architectural section of the exam — pull versus event-driven triggers, where the reconciler lives, how the state store is scoped, and how progressive delivery hands off from the reconciler to a rollout controller. See the CGOA blueprint for the full three-axis table these questions are drawn from.

Q13. A reconciler polls its Git source every 3 minutes and is configured to receive a webhook from the Git host that triggers an immediate sync on push. The firewall rule permitting that webhook is accidentally removed, and delivery starts failing silently. What happens to the correctness of the system?

• A. The system is no longer GitOps-compliant, because event-driven triggering is one of the four required principles.
• B. The system still converges — worst case within the next poll interval — because the webhook is a latency optimization layered on top of the underlying pull loop, not a replacement for it.
• C. The system stops reconciling entirely until the webhook is restored.
• D. The system automatically rolls back to the last state that was successfully applied via webhook.

Q14. A platform team runs one central Argo CD instance outside all managed clusters, holding a service-account credential for each of forty spoke clusters it manages from that single point. Which trade-off does this architecture most directly accept?

• A. Higher per-sync latency, because external reconcilers are structurally unable to use webhooks.
• B. A larger blast radius if the central instance's credentials are ever compromised, in exchange for one consistent control point and fleet-wide visibility across all forty clusters.
• C. Loss of the Pulled Automatically principle, because a central reconciler always pushes into its targets.
• D. Inability to use selfHeal or prune sync options on any managed cluster.

Q15. A platform splits environment promotion across three separate repositories — platform-config-dev, platform-config-staging, platform-config-prod — instead of using one repository with per-environment overlays. What does this design most directly buy the team?

• A. It removes the need for a reconciler entirely, since each repository is its own environment.
• B. Tighter, independently scoped review and RBAC boundaries per environment, at the cost of an explicit promotion step — a PR, a copy, a merge — to move a change from one repository to the next.
• C. Automatic, simultaneous rollback across all three environments whenever one of them fails.
• D. Exemption from the Versioned and Immutable principle for the dev repository specifically, since it changes most often.

Q16. In the Rollout manifest below, which single step is the concrete implementation of the feedback loop terminology competency?

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-svc
spec:
  replicas: 8
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 3m }
        - analysis:
            templates:
              - templateName: error-rate-under-threshold
        - setWeight: 60
        - pause: { duration: 5m }
  selector:
    matchLabels: { app: checkout-svc }

• A. setWeight: 20
• B. pause: { duration: 3m }
• C. analysis — it observes a real, live outcome (the measured error rate) and reports that outcome back into whether the rollout proceeds, holds, or aborts, which is exactly what a feedback loop does.
• D. replicas: 8

Q17. A new service version is fully running in the cluster — every Pod is Ready — but sits behind a feature flag configured to route 0% of production traffic to it. Using the deploy/release distinction the CGOA curriculum draws from progressive delivery, has this version been released?

• A. Yes — if the Pods are Running and Ready, the version has been released.
• B. No — the code is present and has been deployed, but release is specifically about traffic reaching users, and at 0% traffic it has not yet been released.
• C. Yes, because feature flags fall outside the scope of GitOps and therefore don't affect release status.
• D. It's impossible to deploy a version in Kubernetes without simultaneously releasing it.

Related Practices — 4 questions

☺ Like you're 10: Sixteen percent of the test isn't GitOps at all — it's the neighboring habits GitOps borrows from and depends on, like where secrets live and which half of the pipeline is allowed to touch production.

This domain covers Configuration as Code, Infrastructure as Code, DevOps/DevSecOps and CI/CD — not as GitOps mechanics, but as the practices GitOps sits alongside and relies on. Candidates who study only the four principles leave this sixth of the paper to luck.

Q18. A team keeps a ConfigMap describing feature-flag values in Git, and separately keeps a Terraform module describing a managed Postgres instance in Git. Which of the two is Configuration as Code rather than Infrastructure as Code, and why does the distinction matter for GitOps?

• A. The ConfigMap is CaC — application-level runtime configuration — and the Terraform module is IaC — the infrastructure the application runs on. GitOps can reconcile both, but they typically live in different repositories with different reviewers and different blast radii if something goes wrong.
• B. Both are IaC, since every Kubernetes object is technically infrastructure.
• C. Both are CaC, since both are declarative files stored as text.
• D. Neither qualifies as "as code" practice, since only imperative shell scripts count.

Q19. A Kubernetes Secret manifest, committed to the state-store repository, contains a database password in plaintext:

apiVersion: v1
kind: Secret
metadata:
  name: checkout-db
type: Opaque
stringData:
  password: hunter2          # plaintext, committed, and in the full commit history forever

What practice does this violate, and what is the GitOps-correct fix?

• A. Nothing is violated — the repository is private, so plaintext secrets are acceptable inside a private GitOps state store.
• B. It violates DevSecOps practice: anyone with read access to the repository — and its full commit history, since Git never truly deletes a committed value — can retrieve the live credential. The fix is to commit only a reference or an encrypted value, using a tool such as External Secrets, Sealed Secrets, or SOPS, and never the plaintext.
• C. It violates the Declarative principle, because secrets cannot be expressed declaratively.
• D. It violates Versioned and Immutable, because secrets must specifically never be versioned.

Q20. Which statement correctly places the boundary between CI and CD in a GitOps pipeline?

• A. CI and CD are the same process, and the two terms are interchangeable in a GitOps context.
• B. CI builds, tests, and publishes an artifact, then updates the desired state in the store to reference it. CD is the reconciler pulling that updated desired state into the running system — meaning the CI system never needs a standing credential to the production target.
• C. CD always runs before CI, since a cluster must already exist before any image can be built.
• D. CI becomes optional in a mature GitOps pipeline, since the reconciler is capable of building its own images.

Q21. A Kubernetes Claim custom resource requests a managed cloud database. A controller watches that Claim and provisions the real cloud infrastructure to match it, continuously correcting drift if someone changes the database configuration out-of-band through the cloud console. What does this pattern demonstrate about the reach of GitOps?

• A. GitOps principles apply only to application workloads running inside a cluster — infrastructure provisioning is an unrelated practice.
• B. The same declarative-pull-reconcile loop extends to infrastructure provisioning once the infrastructure is represented as a Kubernetes API object — a CRD-and-controller pattern — which is exactly why Infrastructure as Code appears as a Related Practice rather than as a separate certification.
• C. This pattern only functions if the cloud provider itself runs Argo CD internally.
• D. Continuous reconciliation is architecturally impossible for anything located outside a single cluster's own workloads.

Tooling — 4 questions

☺ Like you're 10: The smallest slice of the test, and on purpose — it's about the boxes tools fit into, not about memorizing every flag a command takes.

Fourteen percent, and deliberately shallow: manifest format and packaging, state store systems, reconciliation engines, and interoperability with the rest of the platform. The curriculum names Argo CD and Flux specifically but always with "and alternatives" attached — these questions test the underlying category, not brand trivia.

Q22. A team distributes an application as a Helm chart pushed to an OCI-compliant registry, then references that chart by digest — not by a mutable tag like latest — from an Argo CD Application. Which guarantee does referencing by digest specifically protect?

• A. It has no practical effect — Argo CD treats tag references and digest references identically.
• B. It ensures the exact chart content actually deployed cannot silently change underneath the recorded reference — the same immutability guarantee a Git commit SHA provides, applied here to an OCI-based state store.
• C. It automatically converts the Helm chart into an equivalent Kustomize overlay.
• D. It disables the prune sync option for that specific Application.

Q23. A team wants their desired state expressed as small, independently composable controllers — one watching Git sources, one performing Kustomize builds, one handling Helm releases, one sending notifications — rather than as a single application-centric object with a built-in web UI as the primary interface. Whose design philosophy does this describe?

• A. Argo CD — object-centric, and ships an opinionated UI as its primary interface.
• B. Flux — a set of composable, single-purpose controllers (source, kustomize, helm, notification, and more) that are combined rather than presented as one monolithic tool.
• C. Neither — this describes Tekton, a CI pipeline tool, not a GitOps reconciler.
• D. Neither — this describes Backstage, a developer portal, not a reconciler.

Q24. The CGOA curriculum's Tooling domain names "Git and alternatives" for state store systems, rather than naming Git alone. Which is the correct reading of that phrasing?

• A. Git is deprecated within the CGOA curriculum, and alternatives are now the preferred choice.
• B. Any storage system whatsoever qualifies as a valid state store, regardless of whether it retains version history.
• C. The specification is written against the abstraction — versioned, immutable storage of desired state — rather than against one specific product; OCI registries or object storage with versioning enabled can also qualify.
• D. "Alternatives" refers only to different Git hosting providers, such as GitHub versus GitLab versus Bitbucket — not to non-Git storage systems at all.

Q25. A reconciler is configured to post a message to a chat channel every time a sync fails, and to export sync-duration and drift-detection metrics to a metrics backend for dashboarding. Which named tooling competency does this configuration exercise?

• A. Manifest format and packaging.
• B. State store systems.
• C. Interoperability with notification, observability, and CI tooling — the reconciler's job doesn't end at applying a change, it also has to tell the rest of the platform what just happened.
• D. Reconciliation engine selection.

Scoring yourself, and what to do with a miss

☺ Like you're 10: Getting it wrong isn't the problem — not knowing why you got it wrong is. Every miss fits into one of four boxes, and each box has its own fix.

Count your correct answers and divide by 25 to get a rough percentage — this bank is too small to be a statistically precise rehearsal of the real paper, but it's plenty large enough to tell you whether a domain needs more reading before you attempt Mock Exam · Set 1.

When you miss one, resist the urge to just note the correct letter and move on — that teaches you almost nothing. File it instead:

Whichever domain produced the most misses, weigh that against its blueprint weight before deciding where to spend the next study session — a rough score in the 30%-weighted Principles domain costs far more than the same rough score in the 14%-weighted Tooling domain. The CGOA study plan lays out exactly how to sequence reading, this bank, and the two mock exams across the days you have.