CGOA Practice Test 2 — 10 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

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 3

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 4

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 5

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.

Question 6

A developer pushes a change to Git, but the cluster does not update. Which log source is most effective for debugging the pull-based mechanism?

Accepted Answer

The logs of the GitOps controller (e.g., Argo CD repo-server or Flux controller).. The GitOps controller (Argo CD repo-server or Flux controller) is responsible for the pull-based reconciliation loop: it periodically fetches the desired state from Git, compares it to the live cluster state, and applies any differences. When a Git push does not result in a cluster update, the failure lies within this reconciliation process—such as an inability to fetch the repository, a manifest rendering error, or a sync policy misconfiguration. Therefore, the controller's logs are the most direct and effective source for diagnosing why the change was not applied.

Answer

The browser console of the user.

Answer

The application's logs inside the pod.

Answer

The Git provider's audit logs.

Question 7

A developer updates a Helm release values file in Git to change a ConfigMap key. How does the GitOps pull-based agent determine that reconciliation is necessary?

Accepted Answer

The agent continuously compares the target Git repository commit SHA and state against the cluster's actual state.. GitOps agents like Argo CD and Flux continuously compare the desired state defined by the target Git commit (SHA) against the actual state in the cluster. When the values file changes, the commit SHA changes, the rendered manifests differ, and the controller detects the divergence and triggers reconciliation to apply the new ConfigMap.

Answer

The container registry notifies the GitOps agent whenever a ConfigMap is altered in the source code.

Answer

The Kubernetes API server continuously queries the Git repository directly without using any controller.

Answer

The agent receives an SSH trigger sent manually by the developer from their workstation.

Question 8

When deploying across multiple clusters using Argo CD, you need to ensure that specific secrets are only available to clusters located in the 'us-east' region. Which resource should you use to enforce this segregation?

Accepted Answer

AppProject. AppProject is the Argo CD resource that provides logical grouping and multi-tenancy boundaries, including restricting which clusters, namespaces, and repositories a set of Applications may target. By defining a destination cluster allow-list scoped to the us-east region inside an AppProject, you enforce that only Applications bound to that project can deploy secrets to those clusters. This is the intended mechanism for segregating resources by region or environment.

Answer

ConfigMap

Answer

ApplicationSet

Answer

ClusterRoleBinding

Question 9

When configuring Kyverno policies to secure a cluster, which TWO of the following actions can a policy perform?

Accepted Answer

Enforce policies by blocking requests. Kyverno is a Kubernetes-native policy engine that operates as a validating and mutating admission controller, so option A is correct: a policy in Enforce mode causes the admission webhook to reject (block) any request that violates the rule, returning a denial to the API server. Option E is also correct: Kyverno policies can run in Audit mode, where violations are not blocked but are recorded as PolicyReports (and ClusterPolicyReports) that surface non-compliant resources for review. The remaining options are outside Kyverno's scope: provisioning new clusters (B) is done by tools like Cluster API, kubeadm, or Terraform; managing Git repository webhooks (C) belongs to Git hosting platforms or CI/CD systems such as GitHub/GitLab; and automatically upgrading cluster nodes (D) is handled by node lifecycle tooling like kubeadm upgrade, Cluster API, or managed-node upgrade features, not by a policy engine.

Answer

Provision new clusters

Answer

Manage Git repository webhooks

Answer

Automatically upgrade cluster nodes

Question 10

What does the term 'Self-Healing' mean in a GitOps context?

Accepted Answer

The system automatically restores the desired state if someone manually modifies the cluster. Self-healing in GitOps refers to the operator's ability to detect when the live cluster state diverges from the desired state stored in Git and automatically restore the desired state. If someone manually edits or deletes a resource, the operator reverts the change to match Git. This enforces Git as the single source of truth and prevents configuration drift.

Answer

The application automatically updates its own code

Answer

The cluster automatically reboots upon failure

Answer

The database automatically backs itself up