CGOA Practice Test 1 — 10 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.