Certifications · CGOA · Mock Exam · Set 2

CGOA Mock Exam · Set 2

Fifty more multiple-choice questions, weighted question-for-question to the same five domains of the official CGOA curriculum as Set 1 — fifteen on GitOps Principles, ten each on GitOps Terminology and GitOps Patterns, eight on Related Practices, seven on Tooling. This is the second of two papers, and it assumes Set 1's baseline is already solid: instead of testing one fact per question, most items here hand you a short scenario and make you notice two or three things about it at once — a system that satisfies three principles and fails a fourth for a subtler reason, a pairing of terms that only looks synonymous, a pattern applied somewhere unfamiliar. None of these fifty repeat Set 1's questions. Answer first, then read the explanation directly beneath your choice, and use the domain tag on every item to know exactly which page to reread if you miss it.

How this paper is weighted

☺ Like you're 10: Same split as last time — the biggest chapter still gets the most questions, in the same nice round numbers.

Like Set 1, this paper's fifty questions divide the CGOA's five official domain weights — 30, 20, 20, 16, 14 — with no rounding at all: 15, 10, 10, 8, 7. Keeping the same split across both papers is deliberate, not just tidy: it's what makes a Set 1 score and a Set 2 score directly comparable domain for domain, rather than two numbers on unrelated scales. If Principles cost you points on Set 1 and costs you points again here, that is not the same mistake happening twice by chance — it's the same real gap, confirmed.

Sit it like the real thing

☺ Like you're 10: Same rules as Set 1 — no notes, no open tabs, one sitting, straight through, never leave a question blank.

Sit this exactly like Set 1: closed-book, one timer, one sitting, no documentation allowance, because there's no terminal here for a "browse the docs" concession to apply to in the first place. The scenario questions in this paper reward reading the whole stem before committing — several are built so that an answer which looks right after the first sentence turns out wrong once you reach the second clue. Slow down by a few seconds per question rather than pattern-matching to the nearest question you remember from Set 1; these are new, and a couple are deliberately shaped to resemble a Set 1 question while testing something different.

The paper — 50 questions across three blocks

☺ Like you're 10: Fifty questions, three blocks, every domain mixed into every block — but more of these stories have two things going on at once, so read the whole thing before you answer.

Each question names its domain in parentheses so you can total your score by domain afterward — the real exam won't label them. A few questions are marked (Select TWO), and a few others deliberately describe a scenario where "nothing is actually wrong" is itself the correct answer — don't assume every stem is hiding a violation just because the last several were.

Block 1 — Q1–17

Q1 (GitOps Principles). An Argo CD Application has prune: true but selfHeal: false. An engineer deletes a ConfigMap that's still declared in Git; separately, someone else hand-edits a Deployment's environment variable that's also still declared in Git. What happens to each, and what does the difference reveal?

• A. Both are corrected instantly by Kubernetes itself, unrelated to Argo CD
• B. Neither is ever corrected, because selfHeal governs both deletions and edits equally
• C. The ConfigMap deletion is corrected only at the next Git-triggered sync (prune runs as part of a sync, not continuously); with selfHeal off, the field edit is never corrected on its own — showing that true continuous reconciliation requires drift correction independent of new commits, not just prune running alongside a sync
• D. Both are corrected immediately, since prune and selfHeal are the same setting under different names

Check the answer

C. prune and selfHeal answer different questions — "should deletions from desired state be applied?" versus "should live drift be corrected outside of a triggered sync?" — and this system only has the first one on.

Q2 (GitOps Terminology). A training doc defines five terms: "Desired State: what should be running. State Drift: any change to a Git commit message. State Store: only Git, never anything else. Rollback: SSHing in to fix a broken pod. Feedback Loop: the CI pipeline's build cache." How many of these five are correct as CGOA uses the terms?

• A. All five
• B. Three
• C. One — only "Desired State"
• D. Zero

Check the answer

C. Drift is actual-vs-desired divergence, not a commit message change; a state store isn't Git-exclusive; rollback is a store-level commit revert, not SSH; a feedback loop reports reconciliation outcomes, not a build cache. Only "Desired State: what should be running" survives as a reasonable gloss.

Q3 (GitOps Patterns). An in-cluster reconciler watches a Git branch and applies changes it finds. A separate, unrelated external service also ingests webhook events from the same repo, purely to post Slack messages about what changed — it never touches the cluster. Does this notification service change whether the deployment mechanism counts as "in-cluster" or "external," or "pull" or "event-driven"?

• A. Yes to both — introducing any external service makes the whole system external and event-driven
• B. No to either — the reconciler actually applying changes is still in-cluster and still pull-based; the notification service is a downstream consumer of events, not the mechanism performing reconciliation
• C. Yes, it becomes event-driven, but stays in-cluster
• D. No, it becomes external, but stays pull-based

Check the answer

B. A peripheral notification consumer doesn't redefine the reconciler's own architecture — this is exactly the kind of detail meant to distract from what's actually being asked.

Q4 (Related Practices). A platform runs its application Helm values (Configuration as Code) and its Terraform VPC modules (Infrastructure as Code) through the same Git-triggered CI pipeline, which builds artifacts for both and updates two separate desired-state repos reconciled by two different tools. Is mixing CaC and IaC through the same general delivery approach coherent, or does it break something?

• A. It breaks GitOps — CaC and IaC can never share a delivery approach
• B. It's coherent — CaC and IaC are distinct disciplines by subject matter (runtime config vs. infrastructure provisioning), but GitOps as a delivery pattern is agnostic to which one it's reconciling, so applying the same pull-based model to both is exactly the relationship this domain expects you to recognize
• C. It's coherent only if both use the literal same tool
• D. It's invalid, because Terraform-managed infrastructure can never be reconciled continuously

Check the answer

B. Related Practices tests the relationship between disciplines, not a rule that they must stay siloed.

Q5 (Tooling, Select TWO). A team packages their app as a Helm chart, pushes it as an OCI artifact to their container registry, and configures Flux to reconcile straight from that OCI URL instead of a Git repository. Which TWO tooling competencies does this combination demonstrate?

• A. Manifest format and packaging — Helm as the packaging format
• B. State store systems — an OCI registry serving as a valid alternative to Git
• C. A violation of Pulled Automatically, because OCI isn't Git
• D. Progressive delivery patterns
• E. The Related Practices domain no longer applies once OCI is involved

Check the answer

A and B. Flux still pulls, diffs, and applies from the OCI source exactly as it would from Git — the state-store choice doesn't touch any principle. C, D, and E are all distractors unrelated to what's actually happening.

Q6 (GitOps Principles). A reconciler has automated sync enabled but its polling interval is set to 6 hours with no webhook configured. A change merges to main; for nearly six hours the running system doesn't yet reflect it. Does this long interval, by itself, violate any of the four principles?

• A. Yes — it violates Pulled Automatically, because pulling must happen instantly to count
• B. Yes — it violates Continuously Reconciled, because six hours is too slow to count as "continuous"
• C. No — the principles don't specify a required interval; the agent is still pulling on its own initiative, without a human, and will still eventually converge and keep re-checking indefinitely. Latency is a tuning/patterns concern, not a principles violation
• D. No, but only because Kubernetes itself enforces a maximum polling interval

Check the answer

C. "Continuous" means always operating, not "fast" — a slow but genuinely ongoing, self-initiated loop still satisfies the principle, even if it's a poor operational choice.

Q7 (GitOps Terminology). Which pairing correctly matches each term to its role in a single reconciliation cycle?

• A. Desired State = the report of what happened; Feedback Loop = the target configuration
• B. Desired State = the target configuration declared in the store; State Drift = divergence from it; State Reconciliation = the correction; Feedback Loop = the report of what happened
• C. State Drift = the correction; State Reconciliation = the divergence
• D. Rollback = a synonym for State Reconciliation

Check the answer

B. Declare, diverge, correct, report — in that order, and each word names exactly one step, not two.

Q8 (GitOps Patterns). A rollout launches a full parallel set of new-version instances (matching 100% of current capacity) behind a separate temporary endpoint, runs automated smoke tests against it, then flips the load balancer to send all production traffic to the new set — with the old set kept running, untouched, as a fast-revert option. Which named pattern is this, and what is it explicitly not?

• A. This is blue/green; it is explicitly not a canary, since no fraction of real production traffic is progressively shifted before the full cutover
• B. This is a canary; it is explicitly not blue/green
• C. This is a rolling update; it is explicitly not progressive delivery
• D. This pattern has no name in the curriculum

Check the answer

A. Two full environments and a single-step cutover is the defining shape of blue/green — a canary's defining shape is a controlled, progressively-increasing fraction of real traffic instead.

Q9 (Related Practices). A DevSecOps review flags that the state store contains a NetworkPolicy and a Kyverno ClusterPolicy alongside application Deployments, all reconciled by the same Argo CD instance. Is bundling policy-as-code into the same GitOps loop as application manifests coherent, or a violation?

• A. A violation — policy enforcement can never be expressed as GitOps-managed desired state
• B. Coherent — policy-as-code is itself just more declarative, versioned configuration; reconciling it through the same pull-based loop as application manifests is a natural extension of Related Practices, not a special case
• C. A violation, because NetworkPolicy objects cannot be versioned
• D. Coherent, but only with a completely separate reconciler

Check the answer

B. Nothing about the four principles or Related Practices restricts what kind of resource the loop is allowed to manage.

Q10 (Tooling). An Argo CD Application specifies source.chart pointing at a Helm chart hosted in a chart repository (not Git), with destination targeting a specific cluster and namespace. Is this still a valid GitOps configuration?

• A. It's invalid — Argo CD can only ever source from Git repositories
• B. It's valid: Argo CD's own loop (pull, diff, apply) doesn't care whether the source is a Git repo or a chart repository, as long as it's a versioned, addressable source — this combines packaging (Helm) with an alternative source, not a broken one
• C. It's valid only in Flux, never in Argo CD
• D. It combines Tooling with Related Practices, which the curriculum forbids mixing

Check the answer

B. The reconciliation loop is indifferent to which addressable, versioned source it's pulling from.

Q11 (GitOps Principles). System X: changes are proposed via pull request, merged, and an in-cluster agent polls and applies them, with drift correction disabled after the initial apply. System Y: changes are applied directly via a CI job's kubectl apply on every merge, but a separate always-running sidecar in the cluster continuously diffs live state against the last-applied manifest and reverts drift every 30 seconds, forever. Which system satisfies more of the four principles?

• A. X satisfies all four; Y satisfies none
• B. Neither fully satisfies all four: X fails Continuously Reconciled (drift correction disabled after the initial apply); Y fails Pulled Automatically (CI pushes the initial apply, even though the sidecar's ongoing correction is genuinely continuous)
• C. Both fully satisfy all four
• D. Y satisfies all four; X satisfies none

Check the answer

B. Two systems can each look "mostly compliant" while failing entirely different principles — this is the shape of question this paper leans on hardest.

Q12 (GitOps Terminology). A junior engineer says: "State drift is bad, so a GitOps system should be designed to make drift impossible." Why is this framing subtly wrong?

• A. Because drift is actually desirable and should be encouraged
• B. Because the four principles don't promise drift can never occur — they promise a continuously reconciled loop will detect and correct it whenever it does; the term exists precisely because the possibility of divergence is assumed, not designed away
• C. Because "state drift" isn't a real GitOps term
• D. Because drift can only be prevented by disabling RBAC entirely

Check the answer

B. The system is designed to tolerate and correct drift continuously, not to make drift structurally impossible.

Q13 (GitOps Patterns). A reconciler runs in "server-side apply" mode purely for merge-conflict-safe field ownership when multiple controllers touch the same resource. Does apply mode change whether the system is pull-based, event-driven, in-cluster, or external?

• A. Yes — server-side apply always implies event-driven triggering
• B. No — apply mode is an implementation detail of how a resource gets written, entirely orthogonal to the trigger mechanism (pull vs. event) and reconciler placement (in-cluster vs. external) axes the Patterns domain actually tests
• C. Yes — server-side apply always implies an external reconciler
• D. No, but only because Flux forbids server-side apply

Check the answer

B. Don't let an unrelated implementation detail get mistaken for one of the two axes actually being tested.

Q14 (Related Practices, Select TWO). A team wants their CI pipeline to never hold long-lived cluster credentials, and their secrets to never appear as plaintext anywhere in Git history. Which TWO practices, both part of Related Practices, directly support these two goals respectively?

• A. The "CI pushes, CD pulls" boundary — keeps cluster credentials out of CI
• B. Storing secrets as encrypted references or external pointers (Sealed Secrets, SOPS, External Secrets) — keeps plaintext out of Git history
• C. Switching the state store from Git to an OCI registry
• D. Disabling Continuously Reconciled
• E. Using a monorepo instead of a multi-repo layout

Check the answer

A and B. Each goal maps to a distinct, named practice — don't let C or E, which solve different problems entirely, distract you.

Q15 (Tooling). A described state store is a versioned object-storage bucket (not Git, not OCI) that a custom-built reconciler polls directly via a cloud provider API, applying any new object version found. Assuming the bucket genuinely enforces immutable versioning, does this qualify as a valid GitOps tooling choice?

• A. No — only Git and OCI registries are ever acceptable state stores
• B. Yes — the curriculum defines "state store" by property (versioned, immutable, holds a declarative description), not by product; a properly versioned object-storage bucket satisfies that property just as Git or OCI would, even with a custom reconciler instead of Argo CD or Flux
• C. No — only Argo CD or Flux may serve as the reconciler
• D. Yes, but only if the bucket is hosted on the same cloud provider as the cluster

Check the answer

B. Property, not product — and that includes the reconciler, not only the store.

Q16 (GitOps Principles). Rank these four systems from "satisfies the fewest principles" to "satisfies all four," assuming everything not mentioned is otherwise compliant: (i) desired state applied once via SSH script, never revisited; (ii) desired state pushed by CI on every merge, no ongoing drift correction; (iii) desired state pulled automatically once at startup only, no ongoing polling or watching afterward; (iv) desired state pulled automatically and continuously reconciled with self-heal on.

• A. (iv) < (iii) < (ii) < (i)
• B. (i) < (ii) = (iii) < (iv) — (i) satisfies essentially none of the four; (ii) and (iii) each satisfy three of the four but fail Continuously Reconciled in different ways (push vs. one-shot pull); (iv) satisfies all four
• C. All four are equally compliant
• D. (ii) satisfies all four; the others satisfy none

Check the answer

B. (ii) and (iii) fail the same principle for different reasons — reaching the same score by two different broken paths.

Q17 (GitOps Terminology). A system's Feedback Loop reports "Synced" even though the underlying State Reconciliation attempt silently failed due to an admission controller rejecting the change. What does this best illustrate about the relationship between these two terms?

• A. That Feedback Loop and State Reconciliation are the same thing
• B. That a Feedback Loop is only as trustworthy as what it actually observes and reports — if it doesn't correctly capture a failed reconciliation attempt, the loop technically exists but has failed at its actual purpose of letting a human or process act on the true outcome
• C. That State Reconciliation cannot fail once "Synced" is reported
• D. That admission controllers are unrelated to either term

Check the answer

B. A feedback loop that reports the wrong thing is worse than no feedback loop, because it manufactures false confidence.

Block 2 — Q18–34

Q18 (GitOps Patterns). A team runs Argo CD's ApplicationSet controller to automatically generate one Application per directory found under clusters/*/apps/* in their monorepo, so onboarding a new cluster is "add a directory, and an Application appears." Which architecture-pattern consideration does this most directly address?

• A. Pull vs. event-driven triggering
• B. State store management at scale — how a single monorepo's structure can represent many target environments/clusters without hand-writing an Application object for each one
• C. In-cluster vs. external reconciler placement
• D. Blue/green vs. canary release strategy

Check the answer

B. Generating targets from a structure is a state-store-management technique, not a trigger or placement choice.

Q19 (Related Practices). Which statement most precisely describes where DevSecOps fits into Related Practices, as distinct from DevOps generally?

• A. DevSecOps replaces DevOps entirely once GitOps is adopted
• B. DevSecOps integrates security concerns — secrets handling, policy enforcement, supply-chain integrity — directly into the same automated delivery flow DevOps already established, rather than as a separate, later gate
• C. DevSecOps applies only to database migrations
• D. DevSecOps and GitOps are mutually exclusive practices

Check the answer

B. Woven in, not bolted on afterward, is the distinction the curriculum draws.

Q20 (Tooling). A reconciliation engine emits a metric an alerting rule watches, paging on-call the moment a sync transitions to Degraded. Which tooling competency, and which GitOps term, does this combination most directly connect?

• A. Manifest format and packaging; State Drift
• B. Interoperability (observability integration); the Feedback Loop
• C. State store systems; Rollback
• D. Progressive delivery patterns; Desired State

Check the answer

B. A metric plus an alert is a machine-readable feedback loop, wired through the interoperability competency.

Q21 (GitOps Principles). A reconciler has selfHeal: true but is RBAC-scoped to modify resources in only one namespace; a manual edit occurs in a different namespace the reconciler was never granted access to. Is the resulting, uncorrected change in that second namespace a violation of Continuously Reconciled?

• A. Yes, always, regardless of scope
• B. No — Continuously Reconciled is a property of resources actually under a given reconciler's declared management scope; a namespace never declared as part of this loop's managed system isn't "drift" from this loop's perspective at all — it's simply out of scope
• C. Yes, because every namespace in a cluster is automatically GitOps-managed by any reconciler present
• D. No, but only because RBAC failures are silently ignored by convention

Check the answer

B. A principle only governs what was actually declared as part of the managed system in the first place.

Q22 (GitOps Terminology). Match each described behavior to the term it best represents: (i) an alert fires when a sync fails; (ii) a commit is reverted to restore a prior configuration; (iii) a running Service's selector no longer matches its Git-declared value; (iv) an agent notices (iii) and corrects it.

• A. (i) Rollback, (ii) Feedback Loop, (iii) State Reconciliation, (iv) State Drift
• B. (i) Feedback Loop, (ii) Rollback, (iii) State Drift, (iv) State Reconciliation
• C. All four describe the single term "Continuous"
• D. (i) State Drift, (ii) State Reconciliation, (iii) Feedback Loop, (iv) Rollback

Check the answer

B. Alert → Feedback Loop; commit revert → Rollback; divergence → State Drift; correction → State Reconciliation.

Q23 (GitOps Patterns, Select TWO). A team wants a strategy that (1) never reduces total serving capacity below 100% at any point during rollout, and (2) allows an instant, single-step full revert with no gradual re-ramp required. Which TWO satisfy BOTH conditions at once?

• A. A plain rolling update with no extra batch capacity
• B. Blue/green
• C. "Rolling with additional batch" (new capacity launched before any old capacity is removed), combined with keeping the fully-scaled old environment alive for the revert window
• D. A canary that shrinks old capacity as it ramps
• E. All-at-once replacement

Check the answer

B and C. Plain rolling (A) briefly reduces capacity; canary (D) and all-at-once (E) fail one or both conditions outright. Only blue/green and additional-batch rolling satisfy both requirements simultaneously.

Q24 (Related Practices). An auditor asks: "show me that every infrastructure change last quarter went through code review before being applied." Which Related Practices combination answers this almost for free, and why?

• A. IaC alone, because infrastructure is inherently reviewable
• B. IaC (infrastructure described as versioned code) plus GitOps's requirement that changes flow through the versioned, immutable state store — the store's own commit/PR history is the audit trail, with no separate system needed
• C. CI/CD alone, unrelated to either IaC or GitOps
• D. This is unanswerable without a dedicated compliance product

Check the answer

B. The review gate the state store already enforces doubles as the audit trail.

Q25 (Tooling). Comparing Argo CD's ApplicationSet and a Flux Kustomization with a multi-source generator, what do both mechanisms fundamentally exist to solve?

• A. Generating many managed targets (apps, clusters, environments) from a template plus a set of inputs, rather than hand-authoring one static object per target
• B. Encrypting secrets at rest
• C. Replacing the need for a state store
• D. Enforcing policy-as-code

Check the answer

A. Both are, at bottom, generators — turning a small set of inputs into many managed objects.

Q26 (GitOps Principles). A system individually satisfies all four principles, but the desired state describes infrastructure for a database that the manifest never actually references — the "system" being managed doesn't correspond to anything real in production. Is this GitOps-compliant?

• A. No — this fails Declarative, because an unreferenced manifest isn't a real end-state description
• B. Technically yes, in the narrow sense that the four mechanical principles can hold even for a manifest describing nothing real — they govern how a system is managed, not whether what's being managed is meaningful or correctly scoped; that's a design/requirements problem the principles don't claim to catch
• C. No — this fails Continuously Reconciled, because there's nothing real to reconcile against
• D. No — this fails Pulled Automatically, because there's no real destination

Check the answer

B. The four principles are a specification for how management happens — they say nothing about whether what's being managed is sensible, which is exactly the kind of scope-of-the-spec question this paper pushes on harder than Set 1 did.

Q27 (GitOps Terminology). Why does the curriculum define "Continuous" as a standalone term rather than folding its meaning entirely into "Continuously Reconciled"?

• A. It doesn't — "Continuous" isn't actually a separate curriculum term
• B. Because "Continuous" names the general property (always operating, not merely frequently triggered) that applies beyond just the reconciliation act itself — the same quality could describe a continuously-running feedback loop or a continuously-available pull mechanism, not only reconciliation in isolation
• C. Because "Continuous" is a synonym for "instant"
• D. Because "Continuous" only applies to CI pipelines, never to GitOps

Check the answer

B. The word is doing general work across the whole loop, not just one step of it.

Q28 (GitOps Patterns). A canary analysis template checks p99 latency and error rate every 60 seconds, automatically aborting and rolling back the canary if either threshold is breached — with no human paged unless the automated abort itself fails. What does the automated abort most directly exhibit, beyond simply "progressive delivery"?

• A. Nothing to do with GitOps principles at all
• B. A Feedback Loop that closes without human involvement — the system observes an outcome and acts on it directly, the same underlying idea (observe, then converge) Continuously Reconciled applies to drift generally
• C. State Drift
• D. Versioned and Immutable specifically

Check the answer

B. The same observe-then-act shape shows up here as it does in ordinary drift correction — just applied to a rollout metric instead of a resource diff.

Q29 (Related Practices). A team stores Kyverno ClusterPolicy resources in the same repo and loop as their application manifests, so a policy violation blocks a sync via admission control — and separately, Kyverno continuously scans already-running resources for policy drift. Which Related Practices idea does the admission-time check represent, and which does the continuous scan represent?

• A. Both represent Configuration as Code only
• B. The admission-time check is closer to a traditional CI/CD gate (block before it lands); the continuous scan is the GitOps-style reconciliation model applied to policy rather than to application state — same underlying pattern, different subject
• C. Neither relates to Related Practices at all
• D. Both are pure Tooling-domain concerns, unrelated to Related Practices

Check the answer

B. One checks before the change lands; the other keeps checking forever after — the same distinction that separates a one-shot apply from continuous reconciliation, applied to policy.

Q30 (Tooling). A reconciliation engine's own controller pods are deployed and updated via the exact same GitOps loop they operate — the reconciler manages its own manifests. What's the most direct risk this "self-managing" pattern introduces, and how do production setups typically mitigate it?

• A. There is no risk; self-management is always strictly safer
• B. A misconfigured update to the reconciler's own manifests could break the very mechanism meant to detect and fix that; production setups typically mitigate this with a separate bootstrap/break-glass path so the reconciler can always be manually recovered if it reconciles itself into a broken state
• C. This pattern is explicitly forbidden by the OpenGitOps principles
• D. This risk only applies to Flux, never to Argo CD

Check the answer

B. "App-of-apps" and similar self-managing setups are common, but they need an escape hatch precisely because of this risk.

Q31 (GitOps Principles). A system satisfies Declarative, Versioned and Immutable, and Pulled Automatically, but its reconciliation loop crashes on any transient network blip and doesn't restart without manual intervention — which happens, on average, once a week. On the days the loop is down, does the system still count as Continuously Reconciled?

• A. Yes — as long as it eventually resumes and catches up
• B. No — Continuously Reconciled describes an ongoing, indefinitely-operating property; a loop that silently stops and stays stopped for days until a human notices and restarts it isn't continuously doing anything during those days, regardless of how it behaves once it resumes
• C. Yes, because the desired state never changed while it was down
• D. This scenario is unrelated to any of the four principles

Check the answer

B. Continuity is judged by what's actually happening, not by what would happen if the loop were healthy.

Q32 (GitOps Terminology, Select TWO). An internal wiki defines "Desired State" as "whatever is currently running in production" and "GitOps Managed Software System" as "the Git repository itself." Which TWO corrections bring these in line with the curriculum?

• A. Desired State should be defined as the target configuration declared in the store — not what's currently running, which is actual state, the thing compared against desired state
• B. GitOps Managed Software System should be defined as the running system under management — not the Git repository, which is the state store, a different term entirely
• C. Both definitions are already correct as written
• D. Desired State should instead be defined as a synonym for Rollback
• E. GitOps Managed Software System should instead be defined as a synonym for Feedback Loop

Check the answer

A and B. Both original definitions swap a term for its neighbor in the loop — the target for the actual, and the managed thing for the store that describes it.

Q33 (GitOps Patterns). A GitOps Managed Software System spans two clusters in two cloud regions, reconciled from one shared state store by two separate in-cluster reconciler instances, each scoped to its own cluster's directory. Compared to one external reconciler managing both centrally, name one advantage and one disadvantage of this design.

• A. Advantage: smaller per-cluster blast radius, since each reconciler only ever holds credentials for its own cluster. Disadvantage: no single place to see both clusters' sync status at once, unless something aggregates the two reconcilers' status separately
• B. Advantage: it removes the need for a shared state store. Disadvantage: it becomes impossible to promote a change between regions
• C. Advantage: it automatically becomes event-driven. Disadvantage: it violates Continuously Reconciled
• D. There is no meaningful difference between the two designs

Check the answer

A. The same blast-radius-versus-visibility trade shows up again here, just phrased with two concrete instances instead of the abstract in-cluster/external framing.

Q34 (Related Practices). Why might "GitOps replaces the need for CI entirely" be a wrong answer on this exam, even though GitOps genuinely does replace a traditional CD deployment step?

• A. Because GitOps replaces both CI and CD equally
• B. Because CI's responsibilities — build, test, produce an artifact, update the desired-state reference — still have to happen somewhere; GitOps specifically replaces the deployment/apply mechanism (the CD half), not build-and-test (the CI half), which is why the curriculum frames it as "CI pushes, CD pulls" rather than "GitOps replaces CI/CD"
• C. Because CI is entirely unrelated to GitOps in any framing
• D. Because GitOps only applies to infrastructure, never to application code that needs building

Check the answer

B. GitOps replaces a step, not a whole discipline — a distinction worth being precise about.

Block 3 — Q35–50

Q35 (Tooling). A team concludes: "Argo CD is 'more GitOps' because it has an official UI showing sync status, while Flux, being just controllers, is 'less GitOps.'" What's wrong with this conclusion?

• A. Nothing — a UI is required for GitOps compliance
• B. GitOps compliance is defined by whether a system satisfies the four principles, not by whether it ships a UI; a UI is a usability feature of one implementation, and Flux's notification-controller plus its CLI can surface the same sync status through a different interface
• C. Flux cannot report sync status by any means
• D. Argo CD cannot be run without its UI

Check the answer

B. Presentation and compliance are different questions entirely.

Q36 (GitOps Principles). A team wants to prove, to an auditor, that production has been "Pulled Automatically" for six months with zero manual applies. Which artifact would most directly support that claim?

• A. The Git commit history alone, since it shows what changed
• B. The reconciler's own operation logs/events showing it initiating every apply on its own schedule or on watch events, with no corresponding record of a human running kubectl apply or clicking a manual sync during that window
• C. A screenshot of the current running state
• D. The state store's .gitignore file

Check the answer

B. Pulled Automatically is a claim about who initiates the apply — provable only from the reconciler's own record of initiating it.

Q37 (GitOps Terminology). A postmortem reads: "The incident was caused by state drift that our feedback loop reported, but by the time state reconciliation kicked in, the desired state itself had already been rolled back to fix an unrelated issue — so reconciliation converged the system to the wrong target." Is anything in this account actually out of order?

• A. No — the account is internally consistent and uses all four terms correctly, in a plausible real sequence: drift detected → reported via feedback loop → desired state changed via rollback → reconciliation converges to the now-updated desired state
• B. State Drift and Rollback are swapped
• C. Feedback Loop and State Reconciliation are swapped
• D. The account misuses "Rollback" entirely

Check the answer

A. The trap here is assuming a question must be hunting for an error — sometimes the correct answer is that a convoluted-sounding account is actually using every term correctly.

Q38 (GitOps Patterns). A team debates whether "GitOps applied to database schema migrations" is coherent, given that a migration feels inherently imperative — you can't simply "reconcile" a schema back to an old version without running a down-migration. What's the most accurate resolution?

• A. It's incoherent; GitOps can never apply to anything database-related
• B. It can be made coherent by declaring the desired schema version (not the migration steps) as the GitOps-managed desired state, with a migration operator as the reconciler that determines whatever forward or backward steps are needed to converge actual schema state to that declared version — the declarative/imperative line is drawn at what's stored (a target version), not at how the reconciler gets there internally
• C. It's coherent only if migrations are always run manually by a DBA
• D. It's incoherent because databases cannot be versioned

Check the answer

B. The same reasoning that makes a canary's Rollout object "just more desired state" applies here — the store holds a target, not a procedure, even when the underlying mechanics are imperative.

Q39 (GitOps Principles). System A uses a webhook-only trigger with no fallback polling at all — a lost webhook is never retried or caught by anything else. System B uses a webhook for fast triggering plus a periodic poll as a fallback. Which single principle do these two otherwise-identical systems differ on?

• A. Declarative
• B. Continuously Reconciled — System A's reconciliation is only as continuous as its webhook delivery is reliable, and a permanently lost webhook with no fallback means that change, and any future drift, is never corrected at all; System B's periodic poll preserves the "always eventually correcting" guarantee even if events are lost
• C. Versioned and Immutable
• D. Pulled Automatically — both systems are equally non-compliant here

Check the answer

B. Event-driven-only, with no pull fallback, is the one configuration that actually does break a principle — not because events are used, but because nothing pulls when events fail.

Q40 (GitOps Terminology). Which single word, if removed from the curriculum's description of the GitOps loop, would make "a script that runs once, applies desired state perfectly and correctly, and then exits forever" indistinguishable from full compliance?

• A. "Declarative"
• B. "Continuously" (or "Continuous") — without the requirement for ongoing, indefinite operation, a single correct one-shot apply would satisfy everything else: it can be declarative, versioned, and even "pulled" once by an agent
• C. "Versioned"
• D. "Reconciled"

Check the answer

B. That one word is carrying the entire weight of the fourth principle.

Q41 (GitOps Patterns). A "shadow" deployment sends the new version a mirrored copy of production traffic for testing, but its responses are discarded and never returned to real users, while the old version continues serving all real responses. How does this relate to the deploy/release distinction?

• A. It's not a real pattern and doesn't relate to deploy/release at all
• B. It's an extreme case of deploy without release — the new version is fully deployed and even receiving traffic, but explicitly never released, since no real user ever sees its output; it exists to validate behavior under real load with zero release risk
• C. It's identical to blue/green
• D. It's identical to a canary

Check the answer

B. Deploy and release can separate further than a canary shows — shadow traffic is deploy pushed almost as far from release as it can go.

Q42 (GitOps Principles). A reconciler's selfHeal only corrects drift on resources it directly manages via its own applied manifests. A separate admission webhook, unrelated to the reconciler, independently mutates a label on every Pod at creation — a label the state store never declares an opinion about. Six months later, an auditor calls this label mutation "uncorrected drift the reconciler is failing to catch." Is that characterization accurate?

• A. Yes — any deviation from the original deployment counts as drift, always
• B. No — "drift" specifically means divergence from the declared desired state in the store; a label the store never specified an opinion on cannot "drift" from a value that was never declared, so there's nothing here for Continuously Reconciled to be failing at
• C. Yes, because all Pod fields are automatically part of desired state by default
• D. No, but only because admission webhooks are exempt from GitOps by a special rule

Check the answer

B. You can't drift away from something that was never declared in the first place.

Q43 (Related Practices). A security review requires every change to a policy guardrail go through the same review process as an application deployment, with no separate, less-scrutinized path for "infrastructure-adjacent" changes. Which existing mechanism in a mature GitOps setup satisfies this essentially for free?

• A. None — a brand-new, separate review system must be built
• B. The same PR-based review gate the state store already requires for any change reaching desired state — if the guardrail is itself expressed as declarative, store-managed configuration, it inherits the exact same review boundary as everything else in that repo, with no additional tooling needed
• C. IaC alone, unrelated to GitOps
• D. This requirement is impossible to satisfy under GitOps

Check the answer

B. Treating policy as just another kind of desired state means it inherits every guarantee the store already provides.

Q44 (GitOps Principles). Two engineers argue about whether a reconciler that acts only on every resource-watch event, with no periodic resync at all, is "more continuous" than one combining watch events with a periodic resync every 5 minutes. Who has the stronger case?

• A. The watch-only engineer — reacting instantly to every event is inherently more continuous than waiting on a timer
• B. The resync engineer: a watch-only system can miss events (a dropped connection, a missed notification) with nothing to catch the resulting drift until some other event happens to fire; a periodic resync guarantees the loop revisits and re-verifies state on its own initiative regardless of whether any event ever arrives again — closer to the "always operating" spirit of the principle
• C. Neither — the terms are undefined
• D. The watch-only engineer, because periodic resync wastes compute

Check the answer

B. "Reacts fast" and "keeps checking regardless" are different properties, and only the second one is what the principle actually requires.

Q45 (GitOps Terminology). A GitOps Managed Software System spans application workloads, a cluster's node pool configuration (via a Cluster API resource), and a cloud load balancer (via a Crossplane claim), all reconciled from the same repository. Does the term only apply to application-layer resources?

• A. Yes, only application-layer resources qualify
• B. No — the term applies to whatever is under active reconciliation from the state store, regardless of layer; infrastructure, platform, and application resources can all be part of the same GitOps Managed Software System simultaneously, as this scenario shows
• C. Only infrastructure-layer resources qualify
• D. The term doesn't apply to anything provisioned via Crossplane

Check the answer

B. The term is defined by what's being reconciled, not by which layer it happens to sit at.

Q46 (GitOps Patterns). A "dark launch" deploys a new feature fully into production, gated entirely behind a feature flag that's off for all users, with no traffic-shifting or environment-switching involved at all — just code sitting inert. Where does this sit relative to deploy/release, and is the gate closer to Configuration as Code or a rollout controller's job?

• A. It's pure release with no deploy; closely related to a rollout controller
• B. It's an extreme form of deploy-without-release, similar in spirit to a canary or shadow deployment — but the "release" gate here is a runtime feature-flag value, which is Configuration as Code (a versioned config value) rather than a rollout controller's traffic-shifting logic
• C. It has nothing to do with the deploy/release distinction
• D. It's identical to a blue/green cutover

Check the answer

B. Deploy-without-release can be implemented by an entirely different mechanism than a rollout controller — a flag value is enough.

Q47 (GitOps Principles). Which of the following would represent a genuine architectural inability to ever be Continuously Reconciled, as opposed to merely a bad default configuration that could be changed?

• A. Its default polling interval is set to 3 hours out of the box
• B. Its default sync policy is manual rather than automated
• C. The engine has no mechanism whatsoever — no polling, no watch, no scheduled resync of any kind — for re-evaluating a resource's state once applied a single time; the only way to reconcile it again is to delete and recreate the object from scratch
• D. It requires a restart to pick up a new version of itself

Check the answer

C. A and B are configuration choices, changeable without touching the engine's architecture; only C describes a genuine structural incapacity to ever continuously reconcile.

Q48 (GitOps Principles). A reconciler correctly implements Declarative, Versioned and Immutable, and Pulled Automatically. Its drift correction, however, only ever restores resources deleted out-of-band — it silently ignores drift caused by a modification to an existing resource's fields (someone hand-changing a Deployment's image tag persists forever, uncorrected). Does this partial drift correction still satisfy Continuously Reconciled?

• A. Yes, fully — any drift correction at all is sufficient
• B. No — Continuously Reconciled describes converging actual state toward all of desired state, not a subset of change types; a loop that only catches deletions and permanently ignores field-level modification drift is only partially reconciling, which fails the principle's full requirement even though it is doing something
• C. Yes, because deletions are the only kind of drift that matters
• D. This scenario cannot occur in any real reconciler

Check the answer

B. "Does something" and "fully reconciles" are not the same claim.

Q49 (GitOps Principles, Select TWO). A new engineer proposes: "Store manifests in Git, full history kept. Whenever anyone wants to deploy, they open the Argo CD UI and manually hit Sync — deliberately, so a human always makes the final call. Once synced, leave self-heal off, so if someone needs to hand-fix something in an emergency, their fix survives and isn't reverted." Which TWO principles does this deliberately designed workflow fail, and are those failures accidental or intentional?

• A. Declarative and Versioned and Immutable — both accidental
• B. Pulled Automatically (the human-triggered Sync is a deliberate design choice, not an accident) and Continuously Reconciled (self-heal is deliberately left off so hand-fixes persist) — both failures here are intentional, made explicitly for operational reasons the engineer considered a feature
• C. Only Pulled Automatically fails; Continuously Reconciled is fine because self-heal isn't required for it
• D. Only Continuously Reconciled fails; manual sync doesn't affect Pulled Automatically
• E. None of the four principles are actually violated by this design

Check the answer

B. Deliberate design choices can still be principle violations — good intent doesn't change compliance, which is precisely what makes this trap effective in practice, not just on paper.

Q50 (GitOps Principles). Q1 of this paper described a system where prune ran on sync but selfHeal was off, leaving field-level drift uncorrected between syncs. Which single configuration change would most directly convert that system into one satisfying all four principles, assuming everything else was already compliant?

• A. Switching the state store from Git to an OCI registry
• B. Enabling selfHeal: true, so drift correction happens continuously between syncs rather than only during a sync triggered by a new commit — closing the exact gap Q1 was built around
• C. Switching from Argo CD to Flux
• D. Increasing the polling interval

Check the answer

B. The paper closes the way it opened — same gap, now named and fixed.

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 — and compare it to your Set 1 domain scores if you kept them.

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.

If you sat Set 1 first, put both domain breakdowns side by side. A domain that improved is a gap you actually closed. A domain that's still weak in the exact same place is the one thing worth another full read before you book anything — a single paper's weak domain could be noise, but the same weak domain twice, on two independently written papers, essentially never is. A domain that was fine on Set 1 but wobbled here is worth a second look too — this paper's layered questions test the same material from a less forgiving angle, so a wobble here can surface a shallow understanding Set 1's more direct questions didn't catch.

Where each domain is taught

☺ Like you're 10: Same pages as Set 1 — 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. With prune: true, deletions from desired state are corrected — but only when a sync runs. With selfHeal: false, drift from a manual field edit is never corrected on its own, since nothing is watching for it between syncs.
3. One pushes instead of pulling (an external actor applies the change) while otherwise reconciling continuously; another pulls automatically but only ever applies once, with no ongoing drift correction. Both look "mostly compliant" while failing different principles for different reasons.
4. In-cluster: runs inside the system it manages, typically scoped to one cluster — smaller blast radius, no fleet-wide view. External: runs outside, often managing many targets from one control point — central visibility and control, at the cost of holding credentials for every managed target.
5. Because reconciliation is then only as continuous as webhook delivery is reliable — a permanently lost webhook with no fallback means that change, and any future drift, is never corrected at all. A periodic poll preserves the "always eventually correcting" guarantee independent of whether any event arrives.
6. A canary keeps deploy and release separate via a rollout controller's traffic-shifting logic. A dark launch or shadow deployment separates them even further — using a feature flag (Configuration as Code) or discarded mirrored traffic, with no traffic-shifting mechanism involved at all.
7. 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 both papers. If you're clearing 75% or better on Set 1 and Set 2 alike, with no domain sagging on both, you have real, cross-checked evidence you're ready — not just one good day. If a domain still sags on both, reread it properly, give it a day to settle, and only then book the real thing.