CGOA Practice Questions

Question 1

Which TWO of the following are considered 'Anti-Patterns' in a GitOps workflow? (Choose two)

Accepted Answer

Storing sensitive secrets as plain text in the Git repository.. Option A is correct because committing secrets as plain text in Git exposes credentials to anyone with repository read access and permanently embeds them in Git history, violating GitOps' declarative, auditable, and secure source-of-truth model; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external secrets manager. Option C is correct because making manual changes directly to the production cluster creates configuration drift from the Git-declared desired state, breaking the core GitOps principle that Git is the single source of truth and that all changes flow through version control and automated reconciliation. Option B is not an anti-pattern; using branches (or directories) per environment is a legitimate, widely used GitOps repository strategy for separating prod and dev configurations. Option D is not an anti-pattern; automating deployment with a GitOps operator such as Argo CD or Flux is the intended practice, as it continuously reconciles cluster state with Git. Option E is not an anti-pattern; storing application manifests in a central repository is a standard GitOps pattern that provides a single, versioned source of truth for deployments.

Answer

Using a Git branch to represent a specific environment (e.g., prod vs dev).

Answer

Automating the deployment process using a GitOps operator.

Answer

Storing application manifests in a central repository.

Question 2

You need to ensure that no one can modify cluster resources manually. How can you implement this in a GitOps-mature organization?

Accepted Answer

Remove cluster-admin access from all users except the GitOps controller.. In a GitOps-mature organization, the GitOps controller is the only entity with write access to the cluster, and all changes flow through Git. Removing cluster-admin access from all users except the GitOps controller enforces this by preventing manual modifications, ensuring that the Git repository remains the single source of truth. This is a foundational security practice in GitOps.

Answer

Install a plugin that logs all kubectl commands.

Answer

Add a firewall rule to block kubectl.

Answer

Disable the Kubernetes API server.

Question 3

Which TWO of the following are NOT recommended in a GitOps workflow?

Accepted Answer

Manual changes via kubectl. Option B (Manual changes via kubectl) is NOT recommended in a GitOps workflow because GitOps requires the Git repository to be the single source of truth, and any out-of-band change made directly with kubectl creates configuration drift that the reconciliation controller will detect and revert, defeating the declarative model. Option C (Storing plain-text secrets in the repository) is NOT recommended because committing unencrypted credentials to Git exposes sensitive data to anyone with repository access and to the permanent Git history, violating security best practices; secrets should instead be managed with tools like Sealed Secrets, SOPS, or an external vault. By contrast, option A (Automated reconciliation of state) is a core GitOps principle, typically implemented by controllers such as Argo CD or Flux continuously comparing live cluster state to the desired state in Git. Option D (Using Git as a source of truth) is the foundational GitOps tenet, providing versioning, auditability, and rollback. Option E (Using pull requests for code changes) is recommended because it enables peer review, CI validation, and an auditable approval trail before changes are merged and deployed.

Answer

Automated reconciliation of state

Answer

Using Git as a source of truth

Answer

Using pull requests for code changes

Question 4

What is the primary role of a 'GitOps controller'?

Accepted Answer

To watch the repository and reconcile the cluster state. A GitOps controller (e.g., Argo CD's application controller or Flux's kustomize-controller) continuously watches the Git repository for the desired state and reconciles the live cluster to match it, detecting and correcting drift. It is the engine that closes the loop between declarative intent in Git and actual cluster state. Without it, GitOps is just version-controlled YAML with no enforcement.

Answer

To host the container registry

Answer

To generate user tokens

Answer

To manage Git branches

Question 5

You are managing a global cluster setup with GitOps. How do you handle configuration that must be identical across all clusters while allowing for regional variations?

Accepted Answer

Using a base-overlay structure where the base contains common settings and overlays contain regional variations.. A base-overlay structure (as implemented by Kustomize) lets you define shared configuration once in a base directory and layer cluster- or region-specific patches in overlays, so identical settings stay DRY while regional variations are expressed as targeted overrides. This is the canonical GitOps pattern for multi-cluster fleets because it keeps a single source of truth for common config and isolates divergence to small, reviewable overlay files.

Answer

Only having one cluster.

Answer

Duplicating the configuration for every cluster.

Answer

Using global variables in a shell script to modify manifests.

Question 6

A team is reviewing their deployment practices against OpenGitOps standards. Which THREE conditions are required to satisfy the 'Declarative Desired State' and 'Versioned and Immutable State' principles?

Accepted Answer

The target system's desired state is expressed in a software-interpretable, declarative format like YAML or JSON.. Option A is correct because the OpenGitOps 'Declarative Desired State' principle requires that the intended state of the system be expressed in a declarative, software-interpretable format such as YAML or JSON, so tooling can read and reconcile it automatically. Option B is correct because 'Versioned and Immutable State' requires the desired state to live in a version-controlled repository whose history is append-only, meaning changes are added as new revisions rather than overwriting or deleting prior ones. Option C is correct because each revision must be uniquely identifiable—typically by a Git commit SHA—and fully reproducible, so any past state can be reconstructed and audited. Option D does not belong because allowing live cluster state to override the repository breaks the single source of truth and the immutability of the declared desired state. Option E does not belong because manual shell scripts executed directly on production control plane nodes are imperative, unversioned, and non-reproducible, contradicting both principles.

Answer

Live cluster state is permitted to override repository configurations during peak traffic periods.

Answer

System changes are made by executing manual shell scripts directly on production control plane nodes.

Question 7

Which GitOps tool provides a dedicated CLI called 'argocd'?

Accepted Answer

ArgoCD. ArgoCD ships with a dedicated command-line interface called `argocd`, used to log in, manage applications, sync, and inspect cluster state. The CLI is a first-class part of the ArgoCD project and is documented alongside the web UI. This is a defining characteristic of ArgoCD among GitOps tools.

Answer

Kyverno

Answer

Flux

Answer

Helm

Question 8

What does the status 'OutOfSync' indicate in Argo CD?

Accepted Answer

The live resources are not identical to the Git manifests. In Argo CD, the 'OutOfSync' status indicates that the live state of the resources in the Kubernetes cluster does not match the desired state defined in the Git manifests. Argo CD continuously compares the two and flags any drift, allowing operators to detect and reconcile differences. This is a core part of GitOps: Git is the source of truth, and any deviation is considered out of sync.

Answer

The Git repository is empty

Answer

The application is running out of memory

Answer

The Argo CD server is offline

Question 9

When evaluating ArgoCD vs Flux, which TWO of the following are distinct advantages of using Flux?

Accepted Answer

Modular, controller-based architecture. Option D is correct because Flux is built as a set of independent Kubernetes controllers (source-controller, kustomize-controller, helm-controller, notification-controller), each with a single responsibility, which allows operators to install only the components they need and to scale or upgrade them independently — a modular design that contrasts with ArgoCD's more monolithic application-server model. Option E is correct because Flux natively reconciles multiple Git repositories through multiple GitRepository sources, each watched by its own Kustomization or HelmRelease, so a single Flux installation can continuously reconcile many repos without extra tooling. The unmarked options do not belong: A and B describe ArgoCD's strengths, since ArgoCD ships a built-in web UI with graphical RBAC management, whereas Flux is CLI/GitOps-centric and configures RBAC through Kubernetes manifests; C is also an ArgoCD feature, as ArgoCD provides visual sync waves and health status in its dashboard, while Flux expresses ordering via dependsOn and health checks rather than a graphical sync-wave view.

Answer

Built-in web-based graphical dashboard

Answer

RBAC managed via UI

Answer

Visual sync waves

Question 10

What is the recommended way to handle secrets in GitOps?

Accepted Answer

Use an encrypted secret operator like SealedSecrets.. SealedSecrets (and similar operators like SOPS, External Secrets) allow secrets to be safely stored in Git by encrypting them with a public key; only the controller in the cluster can decrypt them with its private key. This preserves GitOps principles—everything is declarative and version-controlled—while keeping plaintext secrets out of the repository. The sealed secret is safe to commit even to a public repo because it can only be decrypted by the target cluster's controller.

Answer

Commit them directly to the repo in a private branch.

Answer

Create them manually using kubectl.

Answer

Store them in base64 in Git.

Question 11

An organization is implementing GitOps across its infrastructure using Kubernetes and Flux. Which TWO statements accurately describe core characteristics of the 'Automated Pull-Based Reconciliation' principle?

Accepted Answer

Reconciliation automatically corrects drift when actual live cluster state deviates from desired Git state.. Option A is correct because automated pull-based reconciliation continuously compares the desired state declared in Git with the actual live state in the cluster and automatically remediates any drift, restoring resources to the declared configuration. Option C is correct because in the pull model an in-cluster agent such as Flux's source-controller/kustomize-controller periodically fetches (polls) the Git repository and applies changes, so no inbound connection to the cluster is needed. Option B is wrong because pull-based GitOps never has Git initiate inbound SSH connections to worker nodes; the cluster agent pulls from Git instead. Option D is wrong because the whole point of pull-based GitOps is that external CI systems do not need cluster administrative credentials, which stay inside the cluster. Option E is wrong because reconciliation is automated and continuous, not gated by manual human approval for each resource sync.

Answer

The Git repository initiates an inbound SSH connection to cluster worker nodes to push manifest updates.

Answer

Cluster administrative credentials must be stored inside external CI system secret stores.

Answer

Reconciliation requires direct human approval at the terminal for every individual resource sync.

Question 12

You are managing a GitOps repository that contains both application manifests and cluster-wide configurations. You want to ensure that changes to cluster-wide configurations are applied before application workloads during a sync. Which Argo CD feature should you use?

Accepted Answer

Sync waves with negative wave numbers for cluster-wide resources.. Sync waves are the correct feature for ordering resources during a sync. By assigning negative wave numbers to cluster-wide configurations, they are applied before application workloads that have higher wave numbers. This ensures that dependencies are satisfied and avoids race conditions, which is a common GitOps pattern for managing complex deployments.

Answer

Argo CD Projects to group cluster-wide configurations and applications separately.

Answer

ApplicationSets with a progressive sync strategy.

Answer

Resource hooks with a PreSync phase for cluster-wide configurations.

Question 13

What is the purpose of the 'SealedSecrets' custom resource?

Accepted Answer

Encrypting sensitive data for Git storage. SealedSecrets is a Kubernetes controller that encrypts Secret manifests with a cluster-specific public key so the ciphertext can be safely committed to Git. Only the controller in the target cluster, holding the private key, can decrypt the SealedSecret back into a regular Secret. This enables GitOps workflows where secrets live in version control without exposing plaintext.

Answer

Backing up Kubernetes secrets

Answer

Managing cluster-wide RBAC

Answer

Encrypting traffic between pods

Question 14

Which TWO tools are commonly associated with the 'GitOps' ecosystem?

Accepted Answer

Argo CD.. Argo CD (D) is a declarative, GitOps continuous-delivery controller for Kubernetes that continuously reconciles the live cluster state against manifests stored in a Git repository, making it a flagship GitOps tool. Flux (E) is likewise a CNCF GitOps toolkit that watches Git repositories and applies/reconciles Kubernetes manifests, so it is equally central to the GitOps ecosystem. Docker Desktop (A) is a local container build/run environment, Nginx (B) is a web server/reverse proxy, and Prometheus (C) is a metrics monitoring and alerting system; none of these implement Git-based declarative reconciliation, so they are not GitOps tools.

Answer

Docker Desktop.

Answer

Nginx.

Answer

Prometheus.

Question 15

In a GitOps environment, what is the best strategy for managing external dependencies (like Helm charts)?

Accepted Answer

Pinning the version of the Helm chart in your Git repository.. Pinning the Helm chart version in Git ensures the exact chart revision is declared as code, so the GitOps operator reconciles a deterministic, reproducible state. This makes deployments idempotent, enables rollback by reverting the Git commit, and prevents an upstream chart maintainer from silently changing behaviour. Version pinning is the GitOps equivalent of locking dependencies in a package manager.

Answer

Always pulling the latest version from the remote Helm repository.

Answer

Ignoring the chart version and hoping it stays compatible.

Answer

Manually downloading the chart to every node.

Certified GitOps Associate (CGOA, CNCF/Linux Foundation) CGOA practice test

Three ways to study

Study CGOA by domain

Study CGOA by topic

Tooling practice questions

Gitops Terminology practice questions

Related Practices practice questions

Gitops Patterns practice questions

Gitops Principles practice questions

CGOA fundamentals practice questions

CGOA scenario practice questions

CGOA troubleshooting practice questions

Certified GitOps Associate (CGOA, CNCF/Linux Foundation) (CGOA) practice questions