CGOA Gitops Principles Practice Test 5 — 15 Questions

Question 1

You are troubleshooting a Flux controller that is not reconciling changes. The Git repository is updated, but the cluster remains unchanged. Which component should you inspect first to verify the 'automated pull-based reconciliation'?

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

Accepted Answer

The 'GitRepository' or 'Kustomization' custom resources.. Flux's reconciliation is driven by custom resources: 'GitRepository' defines the source (repo URL, branch, credentials) and 'Kustomization' defines what to apply and how. If Git is updated but the cluster is unchanged, inspecting these CRs with 'kubectl get gitrepository,kustomization -n flux-system' and their status conditions reveals whether the source was fetched and whether the apply succeeded. This is the first diagnostic step because it directly reflects the reconciliation pipeline.

Answer

The Kubernetes API server logs.

Answer

The 'flux-system' namespace's 'kustomization.yaml' file.

Answer

The Git provider's webhook logs.

Question 2

Which of the following is a primary benefit of using a GitOps pull-based model over a push-based CI/CD model?

Accepted Answer

Removal of the need for external access to cluster credentials.. In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD, Flux) pulls desired state from Git, so external CI systems never need cluster credentials. This removes the need to store or expose kubeconfig/API credentials outside the cluster, significantly reducing the attack surface.

Answer

Automatic code compilation within the cluster.

Answer

Support for imperative commands.

Answer

Faster deployment velocity.

Question 3

What is the primary function of the 'reconciliation loop' in GitOps?

Accepted Answer

To continuously compare actual state with Git and correct discrepancies.. The reconciliation loop is the core control mechanism of GitOps: an agent continuously observes the actual state of the cluster and compares it to the desired state stored in Git, then takes corrective action to eliminate any difference. This closed-loop feedback ensures the cluster converges on the declared configuration and stays there despite manual changes, failures, or drift. It is what makes Git the authoritative source of truth in practice.

Answer

To manage user access control for the cluster.

Answer

To compile source code into container images.

Answer

To update the documentation in the Git repository.

Question 4

In a multi-cluster environment, how does the GitOps principle of 'Declarative Desired State' simplify cluster management?

Accepted Answer

By enabling template-based configuration across identical environments.. Declarative desired state means the entire cluster configuration is expressed as versioned manifests in Git, which can be templated (Helm, Kustomize) and applied consistently across many clusters. This enables identical environments — dev, staging, production, or multiple regions — to be provisioned from the same parameterized source, eliminating configuration drift and manual per-cluster setup. The result is repeatable, auditable, and scalable multi-cluster management.

Answer

By allowing each cluster to define its own unique state manually.

Answer

By requiring a human operator to verify each cluster's state daily.

Answer

By eliminating the need for Git altogether.

Question 5

Which of these is NOT a principle of GitOps?

Accepted Answer

Imperative manual updates.. GitOps principles are declarative desired state, versioned and immutable state in Git, automated reconciliation, and continuous drift correction. Imperative manual updates contradict the declarative model because they bypass Git as the source of truth and are not reproducible or auditable. Therefore, imperative manual updates is NOT a GitOps principle.

Answer

Versioned and immutable state.

Answer

Declarative desired state.

Answer

Automated reconciliation.

Question 6

When using Argo CD, what does the 'Sync Status' 'OutOfSync' indicate?

Accepted Answer

The live state differs from the desired state in Git.. In Argo CD, 'OutOfSync' means the live Kubernetes cluster state does not match the desired state declared in the Git repository. Argo CD continuously compares the manifests in Git against the resources running in the cluster, and any difference (missing resource, changed field, extra resource) sets the Sync Status to OutOfSync. This is distinct from Health Status, which reflects whether resources are functioning correctly.

Answer

The cluster is disconnected from the network.

Answer

A new version of the application is available in the registry.

Answer

The Git repository has been deleted.

Question 7

You are configuring an automated GitOps pipeline. How do you prevent 'drift' from occurring due to out-of-band changes?

Accepted Answer

By enabling automated self-healing in the GitOps controller.. Automated self-healing in the GitOps controller continuously reconciles the live cluster state against the desired state stored in Git. When an out-of-band change (drift) is detected, the controller automatically reverts the cluster to match Git, preventing drift from persisting. This is a core GitOps principle: the controller enforces the declared state.

Answer

By manually disabling 'kubectl' access for all users.

Answer

By storing the state in a central database instead of Git.

Answer

By setting up a cron job to restart the cluster daily.

Question 8

Which statement best defines 'immutable state' in the context of GitOps?

Accepted Answer

The configuration committed to Git represents a fixed, unchangeable historical point.. In GitOps, immutable state means that a commit in Git represents a fixed, unchangeable point in history — it cannot be altered after the fact. This immutability provides an auditable, versioned record of desired state, enabling rollbacks and reproducibility. Changes are made by adding new commits, not by modifying existing ones.

Answer

The cluster hardware cannot be modified.

Answer

The container images cannot be changed.

Answer

The application state cannot be deleted.

Question 9

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 10

Why is 'pull-based' reconciliation considered more secure than 'push-based' CI/CD?

Accepted Answer

Because the cluster initiates the connection.. In a pull-based model, an in-cluster agent (Argo CD, Flux) initiates outbound connections to Git and the registry, so no external system needs inbound access or cluster-admin credentials. This inverts the trust boundary: the cluster reaches out rather than an external CI server reaching in. That architectural inversion is what makes pull-based reconciliation more secure.

Answer

Because it eliminates the need for Git.

Answer

Because Git requires passwords for every pull.

Answer

Because it removes the need for container images.

Question 11

In a GitOps workflow, where does the 'source of truth' reside?

Accepted Answer

In the Git repository.. In GitOps, the Git repository is the single source of truth because it declaratively stores the desired state of the entire system — manifests, Helm charts, Kustomize overlays, and configuration. Controllers continuously reconcile the live cluster state against this repository, so any drift or change must be committed to Git first. This makes Git the authoritative record of what should be running.

Answer

In the application's environment variables.

Answer

In the Kubernetes etcd database.

Answer

In the developer's local workstation.

Question 12

What is the relationship between the 'desired state' and the 'actual state' in GitOps?

Accepted Answer

The controller continuously reconciles the actual state to the desired state.. In GitOps, Git holds the declarative desired state, and a controller (e.g., Argo CD or Flux) continuously compares it against the live actual state, reconciling any differences so the cluster converges on Git. This continuous reconciliation loop is the defining mechanism of GitOps.

Answer

The desired state is defined by the actual state.

Answer

The desired state is enforced by the controller to match the actual state.

Answer

The actual state is manually pushed to the desired state.

Question 13

If a GitOps controller detects that an image tag has been changed in the cluster but not in Git, what does the controller do?

Accepted Answer

Reverts the cluster state to match the Git repository.. In GitOps, the Git repository is the single source of truth. If the GitOps controller detects that the live cluster state differs from the desired state in Git (e.g., an image tag changed in the cluster but not in Git), it will revert the cluster to match Git. This enforces the declarative model and prevents configuration drift.

Answer

Leaves the cluster in the new state.

Answer

Updates the Git repository with the new image tag.

Answer

Prompts the user for approval.

Question 14

Which TWO of the following are considered advantages of the GitOps approach?

Accepted Answer

Improved auditability through version-controlled commits.. Option C is correct because GitOps stores the desired state of infrastructure and applications as declarative manifests in a Git repository, so every change is captured as a version-controlled commit with author, timestamp, and diff history, giving a complete and auditable trail. Option D is correct because since the Git history is the single source of truth, reverting to a previous commit (for example with git revert or git reset) lets the GitOps operator automatically reconcile the cluster back to the prior known-good configuration, making rollbacks simple and reliable. The unmarked options do not belong: A is wrong because GitOps reduces manual CLI interventions by automating reconciliation from Git, B is wrong because GitOps manages infrastructure and deployment state rather than generating business requirements, and E is wrong because GitOps enforces security and policy controls through review and CI checks rather than bypassing them.

Answer

Increased reliance on manual CLI interventions.

Answer

Automatic creation of new business requirements.

Answer

Ability to bypass security protocols.

Question 15

Which THREE components are typically involved in a GitOps reconciliation loop?

Accepted Answer

A controller running inside the cluster.. In a GitOps reconciliation loop, the Git repository containing manifests (E) is the single source of truth, holding the desired state that the system continuously compares against. A controller running inside the cluster (A) — such as Argo CD's application controller or Flux's kustomize-controller — watches that repo and performs the actual reconciliation by detecting drift and re-syncing. The Kubernetes API server (B) is the target of that reconciliation: the controller reads live object state from it and issues create/update/patch calls to converge the cluster on the desired state. Option C is wrong because GitOps is designed for automated, continuous reconciliation, not per-change human approval gates (approval may exist as a policy, but it is not a core loop component). Option D is wrong because GitOps explicitly rejects an external CI server manually applying changes (push-based deploys); the in-cluster controller pulls and applies, rather than CI pushing kubectl/helm commands.

Answer

A manual human approval gate for every change.

Answer

An external CI server that manually applies changes.