Certifications · CGOA · Mock Exam · Set 1

CGOA Mock Exam · Set 1

Fifty multiple-choice questions, weighted question-for-question to the five domains of the official CGOA curriculum — fifteen on GitOps Principles, ten each on GitOps Terminology and GitOps Patterns, eight on Related Practices, seven on Tooling. This is the first of two CGOA papers on this course: it leans on definitions and the four OpenGitOps principles applied to short scenarios, the way the real associate-level paper does, before Set 2 pushes harder into layered "is this actually GitOps" traps. The CGOA is a knowledge-based exam — no cluster, no terminal, nothing to break — so this is a question paper you sit cold, in one block, with no notes open. Answer first, then read the explanation directly beneath your choice; it is doing as much teaching as the question itself, and the domain tag on every item tells you exactly which page to reread if you miss it.

How this paper is weighted

☺ Like you're 10: The questions are shared out the same way the real test shares out its marks — the biggest topic gets the most questions, and here the split happens to come out in nice round numbers.

The CGOA's five official domain weights — 30, 20, 20, 16, 14 — sum to exactly 100%, and against fifty questions they divide with no rounding at all: 15, 10, 10, 8, 7, which also sum to exactly 50. That tidiness is a coincidence of picking fifty rather than some other paper size, not a property of the exam itself — don't read anything into it beyond "the arithmetic happened to be clean this time." What it does mean is that this paper's proportions track the real blueprint precisely, question for question, so your score by domain is a faithful little mirror of where the real 100% goes.

Sit it like the real thing

☺ Like you're 10: No notes, no open tabs, one sitting, straight through — and never leave a question blank, because a guess has a real chance of being right and a blank one never does.

The CGOA is delivered online and remote-proctored, closed-book, with no documentation allowance — unlike the hands-on Kubernetes exams, there is no "browse the docs while you work" concession here, because there is no terminal to work in. Sit this paper the same way: close every other tab, set a single timer, and commit to an answer on every item even when you're genuinely unsure. Nothing published states whether Linux Foundation multiple-choice exams penalize a wrong guess beyond simply not earning the point — treat that as unconfirmed rather than fact — but the practical advice holds regardless: eliminate what you can, then commit. Never leave a question blank.

The paper — 50 questions across three blocks

☺ Like you're 10: Fifty questions, three blocks, every domain mixed into every block — read the question, pick one answer (or two, when it says so), then check yourself before moving to the next.

Each question names its domain in parentheses so you can total your score by domain afterward — the real exam won't label them, so once you've sat this cold, consider a second pass with the labels covered to see how many you can still place from content alone. A few questions are marked (Select TWO); full credit there needs both correct letters.

Block 1 — Q1–17

Q1 (GitOps Principles). Which of the four OpenGitOps principles specifically requires that a system's desired state describe its end state, rather than a sequence of imperative steps for reaching it?

• A. Continuously Reconciled
• B. Pulled Automatically
• C. Declarative
• D. Versioned and Immutable

Check the answer

C. Declarative means the description states what the end state should look like, not how to get there step by step. A shell script that produces the correct result through an ordered sequence of commands still fails this principle, because a reconciler can't diff a sequence of steps against reality — only a stated end state.

Q2 (GitOps Terminology). What is "state drift," precisely?

• A. The deliberate act of updating desired state in the store
• B. The condition where a system's actual running state diverges from its declared desired state
• C. A synonym for rollback
• D. A metric describing how long a pipeline takes to run

Check the answer

B. Drift is specifically the gap between what's declared and what's actually running — the thing state reconciliation exists to close.

Q3 (GitOps Patterns). What distinction does the curriculum draw between "deploy" and "release" in its deployment and release patterns competency?

• A. They are synonyms with no meaningful difference
• B. "Deploy" means new code is present and running somewhere in the system; "release" means traffic is actually routed to it — a canary can be fully deployed while only partially released
• C. "Deploy" applies only to infrastructure, "release" only to application code
• D. "Release" always happens before "deploy" in a correct pipeline

Check the answer

B. Separating deploy from release is exactly what makes progressive delivery possible: the new version can exist in the system well before it receives meaningful traffic.

Q4 (Related Practices). What is the core relationship the curriculum draws between GitOps and Infrastructure as Code?

• A. They are unrelated disciplines tested separately with no overlap
• B. IaC is the broader practice of describing infrastructure declaratively; GitOps is one operational pattern for continuously delivering that declarative config from a versioned store via a pulling, reconciling agent
• C. IaC replaces the need for a state store entirely
• D. GitOps applies only to Kubernetes workloads, and IaC applies only to cloud infrastructure, so they never overlap

Check the answer

B. IaC is the "what" — infrastructure described in code; GitOps is one particular "how" for delivering and continuously enforcing that description, and it works equally on application manifests and infrastructure config.

Q5 (Tooling). What does the Tooling domain's "manifest format and packaging" competency cover?

• A. Only raw, unpackaged YAML — Helm and Kustomize are out of scope
• B. Multiple ways of expressing and packaging desired state — plain YAML, Kustomize overlays, Helm charts, and OCI artifacts as a distribution format among them
• C. Only proprietary, closed-source packaging formats
• D. Only container image formats, unrelated to Kubernetes manifests

Check the answer

B. The competency is deliberately broad — it's testing whether you know the landscape of ways desired state gets expressed and packaged, not one specific tool.

Q6 (GitOps Principles). A team's desired state lives in an S3 bucket, and each new deployment simply overwrites the previous object at the same key — no prior version is retrievable afterward. Which principle does this violate?

• A. Declarative
• B. Versioned and Immutable
• C. Pulled Automatically
• D. Continuously Reconciled

Check the answer

B. Versioned and Immutable requires a complete, retrievable history of every past version — overwriting the same key in place destroys exactly that history.

Q7 (GitOps Terminology). What, exactly, is a "state store"?

• A. Specifically and only a Git repository
• B. Any system holding the declarative desired state with the versioned-and-immutable property intact — Git is the common choice, not the only one that qualifies
• C. A synonym for the Kubernetes API server
• D. A caching layer used purely for read performance

Check the answer

B. "Git and alternatives" is how the curriculum itself frames it — an OCI registry or comparable versioned, immutable object store can also serve as a state store.

Q8 (GitOps Patterns). In a progressive-delivery canary managed by a controller like Argo Rollouts, where does the rollout's step-by-step traffic-shifting definition itself live, in a GitOps-compliant setup?

• A. Hardcoded inside the rollout controller's binary, outside of Git entirely
• B. As desired state in the state store, exactly like any other GitOps-managed resource — progressive delivery is expressed within GitOps, not a break from it
• C. In a spreadsheet a release manager updates by hand each time
• D. It cannot be expressed declaratively under any circumstances

Check the answer

B. A Rollout object is desired state like any other manifest — versioned, pulled, and reconciled the same way.

Q9 (Related Practices). Where does the boundary between CI and CD typically fall in a GitOps-shaped pipeline?

• A. CI builds, tests and publishes an artifact and updates desired state in the store; CD — the reconciler — notices that change and pulls and applies it. CI pushes, CD pulls, and the CI system never needs cluster credentials
• B. CI and CD are the same pipeline stage with no meaningful boundary
• C. CD always runs before CI in a correct pipeline
• D. Neither CI nor CD interacts with a state store

Check the answer

A. That sentence — CI pushes, CD pulls — is one of the highest-leverage things to have automatic for this exam; it resolves several questions across Related Practices and Patterns at once.

Q10 (Tooling). What is the significance of the Tooling domain's curriculum repeatedly saying "and alternatives" after naming Git and after naming Argo CD/Flux?

• A. It's boilerplate phrasing with no real meaning for the exam
• B. It signals the exam is written against the underlying abstraction — a state store, a reconciliation engine — rather than naming one specific product as the only correct answer
• C. It means the exam never actually asks about Git, Argo CD, or Flux by name
• D. It means only cloud-hosted tools count as valid answers

Check the answer

B. Studying the specification, not the market leaders, is exactly what this phrasing is telling candidates to do.

Q11 (GitOps Principles). An operations engineer manually runs kubectl apply -f from their own laptop every time a colleague tells them a merge has landed. Which principle is missing?

• A. Declarative
• B. Versioned and Immutable
• C. Pulled Automatically
• D. Continuously Reconciled

Check the answer

C. Pulled Automatically means an agent inside the system pulls the change itself. A human running kubectl apply, even from a correct, versioned source, is still an external actor pushing.

Q12 (GitOps Terminology). What does "rollback" mean, precisely, in a GitOps system?

• A. SSHing into the running system and manually restoring the previous configuration by hand
• B. Reverting the desired state in the state store to a previous version and letting the reconciler converge the system to match it
• C. Deleting the whole namespace and starting over from nothing
• D. Pausing the reconciler indefinitely

Check the answer

B. Rollback is an operation on the store, not on the running system directly — revert the commit, and the reconciler does the rest.

Q13 (GitOps Patterns). What does an "automated analysis" step in a progressive-delivery rollout — checking a canary's success-rate metrics before increasing its traffic weight — most directly demonstrate, in CGOA terms?

• A. State drift
• B. The feedback loop competency — the system observes an outcome and acts on it, rather than a human watching a dashboard and deciding by eye
• C. Rollback
• D. A state store

Check the answer

B. An automated gate that reads metrics and decides whether to proceed is the feedback loop made concrete — observe the result, act on it.

Q14 (Related Practices). Why does secrets management in a GitOps workflow typically store only a reference to a secret — say, an External Secrets Operator pointer — rather than the plaintext value, in the state store?

• A. Because plaintext secrets are technically impossible to represent in YAML
• B. Because the state store is versioned and often broadly readable for review, so committing plaintext puts the secret in a permanent, widely accessible history; a reference lets the real secret live in a dedicated secret manager instead
• C. Because Kubernetes Secrets can never be created by a controller
• D. Because DevSecOps forbids the use of Kubernetes Secrets outright

Check the answer

B. The reference-not-plaintext pattern is the concrete DevSecOps half of Related Practices — it follows directly from the state store being versioned and reviewable.

Q15 (Tooling). Beyond Git, which of the following could plausibly still qualify as a GitOps state store?

• A. Nothing else — Git is the only system that ever satisfies the definition
• B. An OCI-compliant artifact registry or comparable versioned, immutable object store, provided it satisfies the same versioning and immutability requirements Git does
• C. An in-memory cache with no persistence between restarts
• D. A live, mutable database table overwritten in place on every write

Check the answer

B. The definition is about properties — versioned, immutable, holds a declarative description — not about a specific product.

Q16 (GitOps Principles). An agent syncs a system's desired state once, immediately after a merge to main, and does not check again until the next merge. If someone manually edits a Deployment's replica count in the interim, nothing corrects it. Which principle is missing?

• A. Declarative
• B. Versioned and Immutable
• C. Pulled Automatically
• D. Continuously Reconciled

Check the answer

D. Continuous means the loop is always operating and capable of correcting drift at any time — a sync that fires once per merge and then stops watching fails this even though the pull itself was automatic.

Q17 (GitOps Principles, Select TWO). A pipeline runs terraform apply automatically as a CI job step triggered on every merge to main, applying an immutable, versioned Terraform configuration stored in Git. It does not run again until the next merge, and drift introduced by hand in between is never detected or corrected. Which TWO OpenGitOps principles does this workflow fail?

• A. Declarative
• B. Versioned and Immutable
• C. Pulled Automatically
• D. Continuously Reconciled
• E. None of the four — this workflow already satisfies all of them

Check the answer

C and D. The configuration itself is genuinely declarative and genuinely versioned and immutable — those two are fine. But CI pushes the change in as an external actor rather than an in-system agent pulling it (C), and the pipeline only acts once per merge with no ongoing drift correction in between (D). This exact half-measure — declarative and versioned, but pushed and one-shot — is the classic distractor shape on this exam.

Block 2 — Q18–34

Q18 (GitOps Principles). An Argo CD Application has automated sync disabled entirely; new commits to the tracked branch sit unreconciled until an engineer opens the UI and clicks Sync. Self-heal remains enabled and continues correcting drift for the rest of the day once that sync happens. Which principle does this setup violate?

• A. Declarative
• B. Versioned and Immutable
• C. Pulled Automatically
• D. Continuously Reconciled

Check the answer

C. A human triggering every sync by hand is the external-actor problem again, even though the change itself is correctly declarative, versioned, and — once applied — continuously reconciled thanks to self-heal.

Q19 (GitOps Terminology). Which term names the property that the whole GitOps loop is "always operating," rather than merely "triggered often"?

• A. Feedback loop
• B. Continuous
• C. State reconciliation
• D. Desired state

Check the answer

B. "Continuous" is the word doing that specific work in the curriculum — always capable of acting, not merely acting on a fixed schedule.

Q20 (GitOps Patterns). What is the fundamental architectural difference between an "in-cluster" and an "external" reconciler?

• A. In-cluster reconcilers cannot use Git as a state store; external ones can
• B. An in-cluster reconciler runs inside the system it manages, typically scoped to one cluster; an external reconciler runs outside, often managing many target systems from a single control point
• C. External reconcilers are inherently faster at every workload
• D. In-cluster reconcilers require no credentials of any kind

Check the answer

B. Placement, not speed or credential requirements, is the axis the curriculum tests — where the reconciler runs relative to what it manages.

Q21 (Related Practices). How does Configuration as Code differ from Infrastructure as Code, as the curriculum uses the two terms?

• A. They are identical with no meaningful distinction drawn
• B. IaC typically describes provisioning infrastructure resources — networks, compute, storage; CaC typically describes configuring the software running on top of that infrastructure — both can travel through the same GitOps loop
• C. CaC applies only to Windows-based systems
• D. IaC cannot be versioned in a state store

Check the answer

B. The distinction is about layer — infrastructure versus the software configured on it — not about tooling or mechanism, which can be shared between the two.

Q22 (Tooling). What is a defining architectural difference commonly cited between Argo CD and Flux as reconciliation engines?

• A. Argo CD cannot reconcile Helm-packaged applications under any configuration
• B. Argo CD is commonly described as application-centric with a built-in web UI; Flux is commonly described as a set of smaller, composable controllers with no bundled UI of its own — both satisfy the same underlying reconciliation loop
• C. Flux cannot be used against a Kubernetes cluster
• D. Argo CD requires a paid license before it can reconcile any resource

Check the answer

B. Shape and presentation differ; the loop underneath — pull, compare, converge — is the same competency being tested either way.

Q23 (GitOps Principles). A CI job runs terraform apply on every merge, and a separate nightly cron job also runs a diff against the same configuration and auto-corrects any drift it finds. Does continuous, indefinite reconciliation alone make this system GitOps-compliant?

• A. Yes — reconciling indefinitely is all that's required
• B. No — it still fails Pulled Automatically, because an external actor (CI, then cron) pushes the change into the system rather than an agent inside the system pulling and applying it itself
• C. Yes, because cron jobs count as automatic by definition
• D. No — it fails Declarative, because CI pipelines are inherently imperative

Check the answer

B. Continuous reconciliation is necessary but not sufficient — all four principles have to hold together, and this system is still push-based no matter how often it corrects drift.

Q24 (GitOps Terminology). What is a "feedback loop," in GitOps terminology?

• A. The mechanism by which the result of a reconciliation attempt — success, failure, drift detected — is reported back so a human or another automated process can act on it
• B. A synonym for state drift
• C. The Git commit history itself
• D. A CI pipeline's build cache

Check the answer

A. Reconciling without reporting the result leaves nobody able to act on a failure — the feedback loop is what closes that gap.

Q25 (GitOps Patterns). Which is a genuine trade-off of choosing an external, rather than in-cluster, reconciler architecture?

• A. It cannot express desired state declaratively
• B. Centralized fleet visibility and one control point for many clusters, at the cost of that external system holding credentials for every managed target — a larger blast radius if it's ever compromised
• C. It removes the need for a state store entirely
• D. It automatically satisfies Continuously Reconciled in a way an in-cluster reconciler cannot

Check the answer

B. The trade is visibility and central control against a wider blast radius — a real architectural decision, not a free upgrade.

Q26 (Related Practices). A CodeBuild-style CI job pushes a built artifact and a config-repo update, and a separate reconciler in the target cluster never holds cluster credentials at all. What does this arrangement best demonstrate?

• A. A misconfigured pipeline that isn't really doing CI/CD
• B. A correct application of the "CI pushes, CD pulls" boundary the curriculum treats as good practice — CI's job ends at updating the store, not at applying it
• C. A DevSecOps anti-pattern that should be flagged
• D. An arrangement that's impossible to implement with real tooling

Check the answer

B. Keeping cluster credentials out of the CI system entirely is exactly the boundary this domain rewards understanding.

Q27 (Tooling). Under "interoperability," what is a reconciliation engine typically expected to connect to, beyond the state store and the managed cluster themselves?

• A. Nothing — reconciliation engines operate in total isolation from everything else
• B. Notification systems (alerting on sync failure), observability stacks (emitting metrics or events about reconciliation health), and CI tooling at the publish/update-the-store boundary
• C. Only an organization's HR system
• D. Only billing and invoicing platforms

Check the answer

B. Interoperability is specifically about the reconciler's neighbors — where it reports, and where the pipeline that feeds it lives.

Q28 (GitOps Principles). Which change would take a fully GitOps-compliant Argo CD-managed system and break exactly one of the four principles, without touching the other three?

• A. Deleting the Git repository entirely
• B. Manually running kubectl set image against a running Deployment while self-heal remains disabled, so the change is never corrected
• C. Switching the manifest format from plain YAML to a Helm chart
• D. Renaming the default branch from master to main

Check the answer

B. Because self-heal is off, that manual edit persists as uncorrected drift — a clean failure of Continuously Reconciled alone. Declarative, versioning and the original pull are all still intact for everything else about the system.

Q29 (GitOps Terminology). What is the "GitOps managed software system"?

• A. Specifically and only applications deployed to Kubernetes
• B. The running system — application, infrastructure, or both — whose actual state a reconciler is responsible for keeping aligned with the desired state in the store
• C. Only the Git hosting platform itself
• D. A synonym for "state store"

Check the answer

B. It's the target, not the tool — whatever the reconciler is actually converging toward the desired state.

Q30 (GitOps Patterns, Select TWO). A platform team stores GitOps desired state for forty application teams in a single monorepo, with one shared review process for every change of any kind. Which TWO consequences follow directly from that choice, compared to giving each team its own repository?

• A. Every change, regardless of team or risk level, shares the same audit history and review boundary — which can bottleneck low-risk changes behind unrelated high-risk ones
• B. It becomes technically impossible to run a reconciler against the store
• C. A single accidental bad merge has a larger potential blast radius than in a system partitioned by team-owned repos
• D. Rollback stops being possible entirely
• E. It automatically makes the system non-declarative

Check the answer

A and C. State-store scope is an explicit competency precisely because of trade-offs like these — a monorepo centralizes review at the cost of blast radius and review-boundary bottlenecks. It doesn't affect whether a reconciler can run (B), rollback (D), or declarativeness (E) at all.

Q31 (GitOps Principles). A team argues that because their pipeline is triggered by a Git webhook the instant a commit lands, rather than on a polling interval, it must be more GitOps-compliant than a polling-based reconciler. Is this correct?

• A. Yes — pull-based systems must poll, so any webhook-triggered system is push-based and therefore not GitOps at all
• B. Not necessarily — an event-driven trigger is typically an optimization on top of a still-pulling agent; what the principles require is that the agent itself performs the pull and apply and keeps reconciling afterward, not how it learned a change occurred
• C. Yes, because webhooks are inherently more secure than polling
• D. No — GitOps requires polling and forbids the use of webhooks entirely

Check the answer

B. The trigger mechanism (poll vs. event) is a patterns-domain detail; what the principles actually require is that the agent itself fetches and applies the state.

Q32 (GitOps Terminology, Select TWO). Which TWO statements accurately distinguish "declarative description" from "desired state," as the curriculum uses the terms?

• A. The declarative description is the artifact — the YAML, for instance — that expresses the desired state; the desired state is the target condition that description specifies
• B. They are exact synonyms with no distinction the curriculum draws
• C. A declarative description can exist without ever being applied, describing a desired state that hasn't yet been reconciled
• D. Desired state can only ever exist inside a Kubernetes cluster
• E. A declarative description must always be written in YAML specifically

Check the answer

A and C. The description is the written artifact; the desired state is what it means. A commit sitting unmerged in a pull request describes a desired state nothing has reconciled yet — the two ideas are related but not identical.

Q33 (GitOps Patterns). A rolling-update deployment pattern, by definition, does what during a rollout?

• A. Replaces all instances of the old version simultaneously with the new one
• B. Gradually replaces instances of the old version with the new one, typically maintaining some minimum available capacity throughout
• C. Runs the old and new version indefinitely side by side with no cutover ever occurring
• D. Requires a separate manual approval for every single instance replaced

Check the answer

B. Gradual, capacity-preserving replacement is the defining shape — no full outage, no instant all-or-nothing switch.

Q34 (GitOps Principles). Which scenario correctly satisfies all four OpenGitOps principles?

• A. A YAML manifest is versioned in Git; an in-cluster controller polls the repo on an interval, applies any change it finds, and separately reconciles drift found from a live diff on that same interval regardless of whether Git itself changed
• B. A YAML manifest lives on a shared network drive that anyone can overwrite in place, applied on a schedule by a configuration-management tool
• C. A Helm chart is installed once manually via helm install, with no ongoing management afterward
• D. A script SSHes into each server and runs a fixed sequence of setup commands whenever someone triggers it

Check the answer

A. Declarative (a stated end state), versioned and immutable (Git), pulled automatically (the in-cluster controller polls and applies on its own), and continuously reconciled (it keeps checking and correcting on an ongoing basis) — all four, together.

Block 3 — Q35–50

Q35 (GitOps Principles). In the curriculum's own framing, which of these is true about the four principles?

• A. They are specific to Kubernetes, YAML, and Git by definition
• B. They describe a specification independent of any particular tool, language or platform — the dominant implementation happens to use Git and Kubernetes, but the principles themselves name neither
• C. They apply only to application deployments, never to infrastructure
• D. They require a service mesh to be present in the managed system

Check the answer

B. Answering at the level of the specification — not at the level of "which product does this" — is what this exam actually rewards.

Q36 (GitOps Terminology). What is "state reconciliation," most precisely?

• A. The one-time act of applying a manifest for the first time
• B. The process by which an agent compares actual state to desired state and takes action to converge the former toward the latter
• C. A synonym for state drift
• D. The process of writing a Git commit message

Check the answer

B. Reconciliation is the corrective act itself — compare, then converge — not the initial apply and not the problem it's solving.

Q37 (GitOps Patterns). Compared to a rolling update, what does a blue/green deployment pattern provide that makes it attractive for a release a team wants to be able to instantly and fully reverse?

• A. Nothing — the two patterns are identical under different names
• B. A complete, separate, already-running "green" environment that traffic cuts over to (and can cut back from) all at once, rather than a gradual instance-by-instance replacement where old and new versions coexist mid-rollout
• C. Blue/green never requires provisioning any extra compute capacity
• D. Blue/green is a formal requirement of GitOps compliance

Check the answer

B. The whole-environment cutover — and the ability to cut straight back — is exactly what a rolling update's gradual, mixed-version state doesn't give you.

Q38 (Related Practices). A CodeBuild-style CI job needs a database credential at build time to run integration tests. Which approach best reflects the DevSecOps half of Related Practices, rather than DevOps convenience alone?

• A. Hardcode the password directly into the pipeline definition
• B. Resolve the value at build time from a dedicated secret manager, referenced by a pointer rather than stored as plaintext anywhere in the pipeline configuration
• C. Email the password to whoever's running the build that day
• D. Store it as a plaintext environment variable visible in the CI project's console

Check the answer

B. Resolving secrets from a dedicated store at build time — never persisting plaintext in configuration — is the same reference-not-value pattern the domain tests elsewhere.

Q39 (Tooling). A team wants their reconciler to notify a chat channel automatically whenever a sync fails, without writing a custom integration from scratch. Which tooling competency does this fall under?

• A. Manifest format and packaging
• B. State store systems
• C. Interoperability — connecting the reconciliation engine to a notification system
• D. This isn't part of the Tooling domain at all

Check the answer

C. Notification hookups are named explicitly under interoperability, alongside observability and CI tooling.

Q40 (GitOps Principles). A state store's canonical, published history can be force-pushed and rewritten, even though fragments of the old history technically still survive in individual contributors' local reflogs. Does this satisfy Versioned and Immutable?

• A. Yes, as long as it's technically recoverable somewhere, by someone
• B. No — the principle requires the published, canonical history to be a complete and unalterable record; a rewritable public history breaks that guarantee even if fragments survive elsewhere
• C. Yes, because Git is inherently immutable by design and cannot be force-pushed
• D. No, because Git cannot support branching at all

Check the answer

B. What the principle protects is the shared, canonical record everyone actually reads and reconciles against — not whatever might be recoverable from someone's local machine.

Q41 (GitOps Terminology). A team says "our rollback is restoring yesterday's database backup." Why would this likely be flagged as a misuse of the term "rollback" in CGOA terms?

• A. Because "rollback" specifically means reverting the desired state in the state store and letting the reconciler converge — restoring a database backup addresses data, not the declared state of a GitOps-managed system, and never goes through the store or the reconciler at all
• B. Because rollbacks must always be instantaneous to count
• C. Because databases can never be GitOps-managed under any circumstances
• D. Because backups are technically a form of state drift

Check the answer

A. The term is scoped precisely to the store-and-reconciler mechanism; a data restore, however useful operationally, is a different operation entirely.

Q42 (GitOps Patterns). Which best distinguishes a canary release from a plain rolling update?

• A. They are the same pattern under two different names
• B. A canary deliberately routes only a small, controlled fraction of real traffic to the new version first — often gated by automated metric analysis — before progressively increasing it, whereas a rolling update simply replaces instances without necessarily controlling traffic proportion by version
• C. Canaries apply only to database migrations, never to services
• D. Rolling updates always roll back automatically, and canaries never do

Check the answer

B. Deliberate, metrics-gated traffic control is the distinguishing feature — a rolling update doesn't inherently control traffic share at all, only instance replacement.

Q43 (Related Practices). Which of these is an example of Configuration as Code specifically, rather than Infrastructure as Code?

• A. A Terraform module provisioning a new VPC and its subnets
• B. A Helm values file setting an application's replica count, feature flags and environment variables, version-controlled alongside the chart
• C. A Crossplane claim provisioning a managed database instance
• D. A CloudFormation template creating a storage bucket

Check the answer

B. A, C and D all provision infrastructure resources — the IaC layer. The Helm values file configures software already running on top of that infrastructure — the CaC layer.

Q44 (Tooling). Why might an exam question describe "a Helm chart packaged and pushed as an OCI artifact to a registry, then referenced as the source in an Argo CD Application," rather than a plain Git-hosted YAML folder?

• A. Because Helm charts can never be sourced from Git under any configuration
• B. Because it's testing whether the candidate understands that "manifest format and packaging" and "state store systems" are somewhat independent competencies — a chart is a packaging choice, an OCI registry is a valid state-store alternative to Git, and the two can combine
• C. Because OCI is only ever used for container runtimes, never for manifests
• D. Because Argo CD cannot read from an OCI registry under any configuration

Check the answer

B. Packaging format and state-store choice are separate axes — this scenario is designed to test that you don't conflate them.

Q45 (GitOps Principles). A candidate objects: "a Kubernetes Operator that watches a CRD and only reconciles when that CRD's spec actually changes isn't continuous — it just reacts to events." What's the flaw in that objection?

• A. There is no flaw — event-triggered reconciliation is never continuous
• B. Continuous means the loop is always running and capable of correcting drift at any time, not that it must be constantly computing even when nothing has changed — most reconcilers combine watch events with periodic resync exactly to remain continuous without wasting resources
• C. Continuous only applies to Argo CD specifically, never to custom Operators
• D. Continuous requires re-applying every resource every second regardless of whether anything changed

Check the answer

B. "Always able to act" is the requirement, not "always actively computing" — event-driven plus periodic resync satisfies it.

Q46 (GitOps Terminology). Put these four in the order they causally occur in a single "something breaks, then gets fixed" GitOps cycle: (i) state reconciliation, (ii) state drift, (iii) desired state declared in the store, (iv) the feedback loop reports the result.

• A. ii, iii, i, iv
• B. iii, ii, i, iv
• C. iv, iii, ii, i
• D. i, ii, iii, iv

Check the answer

B. The desired state has to be declared first; drift is something diverging from it after the fact; reconciliation is the correction; the feedback loop is what reports how that correction went.

Q47 (GitOps Patterns). Why does the curriculum treat "pull vs. event-driven" as a spectrum rather than a strict either/or, given both still count as GitOps-compliant?

• A. Because event-driven systems don't actually pull at all, under any circumstances
• B. Because an event, like a webhook, is typically used only to trigger an earlier pull cycle rather than replace the pull-and-apply mechanism itself — the agent still fetches and applies the state itself; the event just tells it sooner
• C. Because pull-based systems secretly rely on webhooks internally regardless of configuration
• D. Because the distinction genuinely doesn't matter for this exam

Check the answer

B. Event-driven is a latency optimization layered on top of pulling, not a separate mechanism that replaces it.

Q48 (Related Practices). Per the curriculum, why does a candidate who studies only "pure" GitOps mechanics and skips Related Practices risk losing roughly a sixth of the real paper?

• A. Because Related Practices is worth 0% of the exam and doesn't actually matter
• B. Because the domain specifically examines how GitOps relates to, overlaps with, and differs from CaC, IaC, DevOps/DevSecOps and CI/CD as disciplines in their own right — not GitOps mechanics themselves
• C. Because the real exam doesn't actually include a Related Practices section
• D. Because these topics were removed from the current curriculum

Check the answer

B. At 16%, Related Practices is the exam's own reminder that GitOps doesn't live in a vacuum — it sits next to disciplines with their own vocabulary.

Q49 (GitOps Principles). A "GitOps" pipeline applies manifests to a cluster directly from a CI job on every merge, using kubectl apply, and nothing else ever checks the cluster again until the next merge. Which TWO principles does this fail? (Choose the single best answer describing the primary, most direct failure.)

• A. Declarative and Versioned and Immutable — the manifests themselves are the problem
• B. Pulled Automatically — an external CI job pushes the change in — and Continuously Reconciled — nothing watches for drift between merges
• C. Only Declarative fails; the other three are all satisfied
• D. Nothing fails — this is a textbook-correct GitOps pipeline

Check the answer

B. This is the recurring "push-and-forget" shape across this paper: the manifests can be perfectly declarative and perfectly versioned, and it still isn't GitOps, because nothing pulls and nothing keeps watching.

Q50 (GitOps Principles). A team's desired state is declarative, stored with full version history in Git, pulled automatically by an in-cluster agent, and continuously reconciled with self-heal enabled. A reviewer still objects that the system "isn't really GitOps" because it uses Flux rather than Argo CD. Is the reviewer correct?

• A. Yes — only Argo CD implementations count as genuine GitOps
• B. No — the four principles say nothing about which specific reconciliation engine is used; a system satisfying all four is GitOps-compliant regardless of which tool implements the loop
• C. Yes, because Flux cannot satisfy Continuously Reconciled
• D. No, but only because Flux happens to be older software than Argo CD

Check the answer

B. The last question of this paper is the same idea as the first, from the other direction: the principles are a specification, and any tool that genuinely satisfies all four — Argo CD, Flux, or something else entirely — is GitOps, full stop.

Score yourself

☺ Like you're 10: Count your correct answers out of fifty, turn it into a percentage against the real 75% pass mark, then look at which domain cost you the most points — that second part is the part that actually helps.

The Linux Foundation's Multiple Choice Exam FAQ states that a score of 75% or above is required to pass any LF multiple-choice exam, and the CGOA is one. Treat 75% here as a target to clear comfortably, not a calibrated prediction of the real sitting — this paper's wording is ours, not the CNCF's, and it isn't tuned to match the real exam's difficulty.

Whatever you scored, sort your misses into two piles before you move on, because on a paper like this one they mean different things. A question you got wrong because you genuinely didn't know the term or the principle is a real content gap — reread the linked domain page and redo that exact question cold in a couple of days. A question you got wrong despite roughly knowing the material — you second-guessed yourself, or confused two similarly worded options under time pressure — is a confidence problem, not a knowledge gap, and the fix is more timed reps, not rereading content you already have. Either way, don't retake this exact paper minutes later; go read first, then come back.

Where each domain is taught

☺ Like you're 10: Every question above traces back to one of a handful of pages. Go back to the page, not to the wider internet.

Nothing in this paper examines anything that isn't covered somewhere on this course. Where a domain is genuinely GitOps-specific, the pages live right here on Golden Astronaut; where it's general platform-engineering ground shared with GitOps rather than unique to it, the deeper read lives on the sibling Platform Engineering CGOA overview, which covers the same five domains from the other side of the trio.

Beyond the domain pages, the wider revision kit still applies: flashcards for the vocabulary, the self-check quiz for mixed recall, the glossary for anything a question assumed you already knew, and the CGOA study plan for how to sequence all of this against your remaining prep time.

Check your answers

1. GitOps Principles 30%; GitOps Terminology 20%; GitOps Patterns 20%; Related Practices 16%; Tooling 14%.
2. It satisfies Declarative and Versioned and Immutable — the manifests themselves are fine. It breaks Pulled Automatically (CI, an external actor, pushes the change in) and Continuously Reconciled (nothing watches for drift between merges).
3. The system holding the declarative desired state, versioned and immutable with a complete history. Git is the usual choice, not the definition — an OCI registry or comparable versioned, immutable store can also qualify, hence "and alternatives."
4. Reverting the desired state in the store — typically a commit revert — and letting the reconciler converge the system to match. It deliberately excludes hand-patching the running system directly, and excludes data-layer operations like restoring a database backup.
5. In-cluster: credentials stay inside that one system's trust boundary, limiting blast radius to a single cluster. External: one control point and central visibility across a fleet, at the cost of holding credentials for every managed target.
6. Officially published: the 90-minute duration and the 75% pass mark (from the Linux Foundation's Multiple Choice Exam FAQ). Not published: the real question count — any third-party figure for it is unverified. Confirm both, and everything else, on the official Linux Foundation CGOA page and the CNCF certification page before you register.

That's the full sitting. Reread whichever domain cost you the most, give it a day to settle, then move on to Set 2 — the scenario-heavy paper that assumes this baseline is already solid.