CGOA sample questions with answers

CGOA sample questions

Certified GitOps Associate (CGOA), CNCF / The Linux Foundation.

1. Question 1

   Domain: GitOps Terminology

   In the OpenGitOps glossary, what does the word "continuous" describe?

   1. That reconciliation keeps happening on an ongoing basis, not that it is instantaneous
   2. That the build pipeline runs on every push to the default branch
   3. That the agent holds an open streaming connection to the state store at all times
   4. That every commit must be applied to the cluster within one second
   Show the answer

   Answer: A. That reconciliation keeps happening on an ongoing basis, not that it is instantaneous

   The glossary states that "continuous" is meant in the industry-standard sense: reconciliation continues to happen, not that it must be instantaneous. The one-second option confuses continuity with latency, which the glossary explicitly rules out, and the build-pipeline option describes continuous integration rather than reconciliation.

   Checked against: https://github.com/open-gitops/documents/blob/main/GLOSSARY.md

2. Question 2

   Domain: GitOps Terminology

   What is state drift?

   1. A difference between two environments that were built from the same manifests but promoted at different times
   2. The gradual increase in reconciliation latency as the number of objects managed by the agent grows over time
   3. A backlog of commits in the state store that have not yet been reviewed or merged by the owning team
   4. The actual state of a system moving, or being in the process of moving, away from the desired state
   Show the answer

   Answer: D. The actual state of a system moving, or being in the process of moving, away from the desired state

   The glossary defines drift as the actual state having moved, or moving, away from the declared desired state. Unreviewed commits are the opposite situation: the desired state has changed and the cluster has not caught up yet, which is divergence awaiting reconciliation rather than drift of the running system.

   Checked against: https://github.com/open-gitops/documents/blob/main/GLOSSARY.md

3. Question 3

   Domain: GitOps Principles

   A team proposes keeping desired state in a ConfigMap that operators edit through an internal web form, arguing that the cluster is the single source of truth and that the form enforces review.

   What is the strongest principle-based objection?

   1. ConfigMaps have a 1 MiB size limit, so the full set of manifests for a large platform will not fit in one object
   2. ConfigMaps cannot hold YAML, only key-value pairs
   3. Editing in place keeps no immutable versions or history, so there is nothing to roll back to and no audit trail
   4. The reconciler cannot read ConfigMaps from another namespace, so each team's desired state would need its own controller
   Show the answer

   Answer: C. Editing in place keeps no immutable versions or history, so there is nothing to roll back to and no audit trail

   The proposal fails principle 2 head on: each edit overwrites the previous desired state, so no earlier version survives for rollback or audit, and the runtime becomes its own source of truth. The size limit is the closest distractor and is a real constraint, but it is a practical ceiling rather than the reason the design is not GitOps.

   Checked against: https://github.com/open-gitops/documents/blob/main/PRINCIPLES.md

4. Question 4

   Domain: GitOps Principles

   What makes a Git commit identifier suitable for referring to an immutable version of desired state?

   1. The identifier is a sequential number assigned by the server
   2. The identifier is a hash of the commit's content, so changed content yields a new identifier
   3. The identifier is reserved by the repository host when pushed and can never be reused by another commit
   4. The identifier is generated from the committer's signing key and the time the commit was pushed
   Show the answer

   Answer: B. The identifier is a hash of the commit's content, so changed content yields a new identifier

   Git stores objects addressed by a checksum of their contents, so a commit identifier cannot refer to two different trees; altering anything yields a new identifier. The signing-key option is the closest distractor: signatures attest who made a commit, but they are not what makes the identifier content-addressed.

   Checked against: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

5. Question 5

   Domain: GitOps Principles

   What distinguishes a declarative approach from an imperative one?

   1. Declarative configuration is stored in Git, imperative configuration is not
   2. Declarative configuration is applied by an automated agent, imperative configuration is applied by a human operator
   3. Declarative configuration is idempotent only when written in YAML
   4. Declarative configuration states the intended end state, imperative configuration states the steps to take
   Show the answer

   Answer: D. Declarative configuration states the intended end state, imperative configuration states the steps to take

   The difference is what the artefact expresses: an end state to converge on, versus an ordered sequence of actions to perform. Who applies the change is the closest distractor and is incidental, because an agent can just as easily run a procedural script and a human can apply a declarative manifest.

   Checked against: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/

6. Question 6

   Domain: Related Practices

   What separates continuous delivery from continuous deployment?

   1. Continuous delivery keeps every change releasable but needs a decision to release; continuous deployment releases every passing change automatically
   2. Continuous delivery applies to libraries and packages, while continuous deployment applies to running services
   3. Continuous delivery runs its acceptance tests only after each release has reached users, while continuous deployment runs them before anything is released
   4. Continuous delivery requires a GitOps agent, while continuous deployment does not
   Show the answer

   Answer: A. Continuous delivery keeps every change releasable but needs a decision to release; continuous deployment releases every passing change automatically

   Both keep changes ready to ship; the difference is whether a human decision stands between a passing pipeline and production. The claim about test ordering is the closest distractor and misdescribes both practices, since automated verification precedes release in each.

   Checked against: https://glossary.cncf.io/continuous-deployment/

7. Question 7

   Domain: Related Practices

   What does DevOps describe?

   1. A team structure in which operations engineers report to development managers and share a single on-call rota for all services
   2. A specific toolchain of pipeline, registry and orchestrator that a team adopts to automate all of its builds and releases
   3. A job title for engineers who maintain build servers
   4. A cultural and organisational approach merging development and operations responsibilities, with supporting practices
   Show the answer

   Answer: D. A cultural and organisational approach merging development and operations responsibilities, with supporting practices

   The CNCF glossary presents DevOps as a methodology and cultural shift in which a team owns the whole lifecycle of what it builds, supported by practices and tooling rather than defined by them. The toolchain option is the closest distractor and is a common misreading, because buying the tools without changing ownership does not deliver the outcome.

   Checked against: https://glossary.cncf.io/devops/

8. Question 8

   Domain: GitOps Patterns

   A team uses Argo Rollouts with the blue-green strategy. They want the new version reachable for internal testing before any customer traffic reaches it, and they do not want promotion to happen on its own.

   Which configuration meets both requirements?

   1. Set previewService to a second Service and leave autoPromotionEnabled unset
   2. Set previewService to a second Service and set autoPromotionEnabled to false
   3. Set previewService and set scaleDownDelayRevisionLimit to 1
   4. Set activeService only and rely on scaleDownDelaySeconds to delay the switch
   Show the answer

   Answer: B. Set previewService to a second Service and set autoPromotionEnabled to false

   The preview Service exposes the new ReplicaSet before promotion, and autoPromotionEnabled set to false pauses the rollout immediately before the active Service is switched, so a human must promote it. Leaving autoPromotionEnabled unset is the closest distractor and defaults to true, which promotes as soon as the new pods are available.

   Checked against: https://argo-rollouts.readthedocs.io/en/stable/features/bluegreen/

9. Question 9

   Domain: GitOps Patterns

   An Argo Rollouts canary has steps setWeight 20, then pause with no duration field, then setWeight 50. The rollout has been sitting at 20 per cent for two hours and the team expected it to continue on its own.

   What is happening and what should they do?

   1. The controller is waiting out the default pause duration of three hours before continuing
   2. The rollout has failed its analysis and is waiting to be aborted
   3. The pause step with no duration pauses indefinitely, so someone must promote the rollout to continue
   4. The weight cannot exceed 20 per cent without traffic routing configured
   Show the answer

   Answer: C. The pause step with no duration pauses indefinitely, so someone must promote the rollout to continue

   A pause step without a duration holds the rollout until the pause condition is removed, which is done with the promote command or through the user interface. The default duration option is the closest distractor and is wrong because there is no implicit duration; when a duration is given without a unit it is interpreted as seconds.

   Checked against: https://argo-rollouts.readthedocs.io/en/stable/features/canary/

10. Question 10

    Domain: Tooling

    A vendor chart exposes most settings through values, but one required change is to an annotation on a Deployment that the chart does not parameterise. The team must keep upgrading the chart as the vendor releases new versions.

    What is the better approach and why?

    1. Copy the rendered output into the repository and edit it directly, so the desired state is explicit and fully reviewable
    2. Keep the chart unmodified, set what it supports through values and add the one unexposed annotation with a post-render patch
    3. Ask the vendor to expose the annotation and postpone the change until they do
    4. Fork the chart and maintain the annotation in the fork, because the change then lives alongside the templates it modifies
    Show the answer

    Answer: B. Keep the chart unmodified, set what it supports through values and add the one unexposed annotation with a post-render patch

    Post-rendering keeps the upstream chart as an upgradable dependency and confines the local change to a small, reviewable patch, which is the cheapest thing to carry forward. Forking is the closest defensible alternative and is sometimes justified for extensive changes, but for a single annotation it imports every future merge conflict for no benefit.

    Checked against: https://argo-cd.readthedocs.io/en/stable/user-guide/helm/