CGOA Practice Test 3 — 10 Questions

Question 1

What is the primary role of the GitOps operator during the reconciliation phase?

Accepted Answer

Continuously checking if the cluster matches the desired state in Git.. The GitOps operator's core responsibility during reconciliation is to continuously compare the actual state of the cluster with the desired state declared in Git. If any drift is detected, the operator automatically applies changes to bring the cluster back into alignment. This closed-loop process ensures that Git remains the single source of truth for declarative infrastructure and applications.

Answer

Reporting the number of users connected to the cluster.

Answer

Deleting the Git repository to save space.

Answer

Compiling the application source code.

Question 2

Which THREE of the following are common GitOps tools used in the CNCF ecosystem?

Accepted Answer

Crossplane.. Crossplane (A) is a CNCF project that extends Kubernetes with custom resources to provision and manage cloud infrastructure declaratively, making it a common GitOps tool for infrastructure-as-code workflows. Flux (B) is a CNCF graduated project that continuously reconciles Kubernetes cluster state with Git repositories, embodying the core GitOps pull-based model. Argo CD (D) is also a CNCF graduated project that performs declarative, Git-based continuous delivery for Kubernetes by syncing cluster resources to a desired state stored in Git. Apache HTTP Server (C) is a general-purpose web server and MySQL (E) is a relational database; neither is a GitOps reconciliation or continuous delivery tool, so they do not belong in this list.

Answer

Apache HTTP Server.

Answer

MySQL.

Question 3

Which TWO of the following are true about ArgoCD ApplicationSets?

Accepted Answer

They support multi-cluster generators. Option A is correct because ApplicationSets provide generators such as the Cluster generator, which enumerates clusters registered in ArgoCD (via cluster Secrets) and produces one Application per cluster, enabling true multi-cluster deployments. Option D is correct because an ApplicationSet controller renders a template against generator output to automatically create, update, and delete ArgoCD Application resources, removing the need to hand-write each Application manifest. Option B is wrong since ApplicationSets are explicitly designed to target many clusters, not just the local one. Option C is wrong because ApplicationSets only generate Application CRs; image building is handled by CI tools like Jenkins, GitLab CI, or Tekton, not ArgoCD. Option E is wrong because ApplicationSets still rely on Git (or another generator source) as the desired-state source of truth and do not replace it.

Answer

They are only for local clusters

Answer

They handle container image builds

Answer

They replace the need for Git

Question 4

What is the role of a 'Webhook' in a GitOps setup?

Accepted Answer

To inform the operator of a change in the Git repository. A webhook in a GitOps setup is a notification mechanism: the Git provider (GitHub, GitLab, Bitbucket) sends an HTTP POST to the operator's endpoint whenever a push, merge, or tag occurs, prompting the operator to reconcile immediately. This reduces the latency between a Git commit and cluster convergence compared to relying solely on periodic polling.

Answer

To store encrypted credentials

Answer

To scan container images for vulnerabilities

Answer

To automatically approve pull requests

Question 5

Which of the following is considered an 'Anti-pattern' in a GitOps workflow?

Accepted Answer

Applying 'hotfixes' directly to the cluster via kubectl. Applying 'hotfixes' directly to the cluster via kubectl is an anti-pattern in GitOps because it bypasses the declarative, version-controlled workflow. GitOps requires all changes to be made through Git, ensuring auditability, reproducibility, and consistency. Direct kubectl changes cause drift and are not tracked in Git.

Answer

Storing infrastructure definitions as code

Answer

Automated testing of configuration before merging to main

Answer

Using pull requests to review configuration changes

Question 6

An administrator notices that an engineer manually modified a Service loadBalancerIP in the Kubernetes live cluster using 'kubectl edit'. The cluster is managed by an automated GitOps engine configured in a pull-based model. What will happen during the next reconciliation cycle?

Accepted Answer

The GitOps engine will detect the drift and overwrite the live cluster state to match the declared state in Git.. In a pull-based GitOps model, the engine (e.g., Argo CD or Flux) continuously compares the live cluster state to the desired state declared in Git. When it detects drift—such as a manually edited loadBalancerIP—it overwrites the live resource to match Git, provided auto-sync/self-heal is enabled. Git is never updated from the cluster; the flow is one-directional from Git to cluster.

Answer

The GitOps engine will automatically commit the updated loadBalancerIP back to the Git repository to keep Git in sync.

Answer

The live cluster modification will block future Git commits from being fetched by the GitOps agent.

Answer

The GitOps engine will halt reconciliation permanently until an administrator manually clears the cluster error log.

Question 7

What does 'Declarative Configuration' imply in GitOps?

Accepted Answer

The system is defined by files that describe the desired final state. Declarative configuration means you write files (YAML manifests, Helm charts, Kustomize overlays) that describe the desired end state of the system, and a controller continuously reconciles actual state to match. You declare 'what' the system should look like, not 'how' to get there step by step. This is the foundation of GitOps because the declarative files can be version-controlled and diffed.

Answer

Only developers can access the system

Answer

The database is the source of truth

Answer

You must manually type every command

Question 8

Which THREE strategies are effective for managing configuration at scale in a GitOps environment?

Accepted Answer

Organizing manifests into a hierarchical directory structure.. Option B is correct because organizing manifests into a hierarchical directory structure (e.g., base/ and overlays/ per environment) lets GitOps tools like Argo CD or Flux scope and reconcile each environment independently, avoiding duplication and enabling clear ownership. Option C is correct because Kustomize uses a base plus overlay model with kustomization.yaml files to apply environment-specific patches (replicas, image tags, resource limits) without copying whole manifests, which is a standard GitOps pattern. Option D is correct because Helm charts parameterize deployments through values.yaml and templating, so one chart can render many environment-specific releases, reducing drift and duplication at scale. Option A is not appropriate because copying the entire configuration per environment creates massive duplication and drift, making updates error-prone. Option E is not appropriate because a single root-level file does not scale, creates merge conflicts, and prevents per-environment separation of concerns.

Answer

Copying the entire deployment configuration for every single environment.

Answer

Storing all configurations in a single root-level file.

Question 9

What is the best way to handle temporary, non-production overrides in a GitOps environment?

Accepted Answer

Using Kustomize overlays to apply overrides on top of the base configuration.. Kustomize overlays are the canonical GitOps pattern for environment-specific overrides: a shared base holds common manifests, and overlays patch only the fields that differ per environment (replicas, image tags, resource limits). This keeps the base DRY and the overrides declarative and version-controlled. Overlays are applied by the CD controller during reconciliation, so no manual drift is introduced.

Answer

Hardcoding all variants into the base file using if/else statements.

Answer

Leaving the cluster in a drifted state.

Answer

Editing the base manifest and pushing it.

Question 10

Which TWO of the following are common GitOps terminology used to describe the state of an application?

Accepted Answer

Desired State. In GitOps, the Desired State (B) is the declarative configuration stored in Git that defines how the application and its infrastructure should look, serving as the single source of truth that the GitOps operator continuously reconciles toward. The Live State (C), also called the observed or actual state, is the real-time condition of the running application and cluster as reported by the GitOps agent (e.g., Argo CD or Flux), which is compared against the desired state to detect drift. These two terms form the core reconciliation loop of GitOps: the controller drives the live state to match the desired state. The other options are not GitOps terminology: Temporary State (A), Future State (D), and Legacy State (E) are not standard terms used to describe application state in GitOps workflows.

Answer

Temporary State

Answer

Future State

Answer

Legacy State