CGOA Gitops Principles Practice Test 7 — 15 Questions

Question 1

Which THREE of the following are essential components of an effective GitOps 'Continuous Drift Detection and Correction' strategy?

Accepted Answer

Continuous comparison loop between cluster live state and Git desired state. Option A is correct because drift detection fundamentally requires a continuous reconciliation loop that compares the cluster's live state against the desired state declared in Git, which is the core mechanism tools like Argo CD and Flux use. Option B is correct because detecting drift is only useful if it triggers an action — either an alert to operators or automated synchronization (self-heal) to bring the cluster back in line with Git. Option C is correct because strict RBAC and admission controls that prevent manual, out-of-band changes to the cluster reduce drift at its source and preserve Git as the single source of truth. Option D is not correct because periodic manual audits are reactive and point-in-time, not continuous, so they cannot satisfy a continuous drift detection strategy. Option E is not correct because a CI-based push pipeline applies changes only when the pipeline runs, rather than continuously reconciling live state against Git as a pull-based GitOps agent does.

Answer

Regular manual audits of the cluster state

Answer

Using a CI-based push pipeline to update the cluster

Question 2

A DevOps team is storing its Kubernetes manifests in a Git repository. To adhere strictly to the principle of versioned and immutable desired state in Git, how should the team manage changes to an existing deployment's container image tag?

Accepted Answer

Commit a change updating the image tag in the manifest file within the Git repository and merge it via a pull request.. In GitOps, Git is the single source of truth for desired state, so any change to a deployment—including the container image tag—must be made by committing to the manifest in Git and merging via a pull request. The GitOps controller then reconciles the cluster to match. Direct cluster mutations bypass the audit trail and are reverted by reconciliation.

Answer

Exec into the running pod using 'kubectl exec' and update the container image binary directly.

Answer

Run 'kubectl set image deployment/my-app my-app=image:v2' against the live cluster without updating Git.

Answer

Delete the deployment using 'kubectl delete' and manually re-apply a temporary local manifest file.

Question 3

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 4

A company is choosing between a push-based CI/CD pipeline (e.g., executing 'kubectl apply' from GitHub Actions) and a pull-based GitOps controller (e.g., Argo CD or Flux). Which security advantage is uniquely provided by adopting the pull-based architecture?

Accepted Answer

Cluster API credentials do not need to be exposed or stored inside the external CI/CD platform.. The unique security advantage of pull-based GitOps is that the cluster's API credentials never leave the cluster — the in-cluster controller pulls changes from Git rather than an external system pushing into the cluster. This eliminates the need to store high-privilege kubeconfig or service account tokens in an external CI/CD platform, drastically reducing the attack surface.

Answer

Git repositories are automatically encrypted at rest using cluster-managed hardware security modules.

Answer

It eliminates the need to perform code reviews or pull request approvals before deploying to production.

Answer

Container images are automatically scanned for vulnerabilities before being pushed to the container registry.

Question 5

A platform engineer wants to configure an application state declaratively. They write an imperative script containing commands like 'kubectl scale deployment --replicas=5' and push this script into a Git repository for execution by a cron job. Why does this approach fail to satisfy the core GitOps principle of 'Declarative Desired State'?

Accepted Answer

The state is defined as a series of execution steps rather than a static description of the target system configuration.. The core GitOps principle of 'Declarative Desired State' requires that the system's target configuration be described as a static, declarative specification (e.g., YAML manifests) rather than a series of imperative commands. An imperative script like 'kubectl scale deployment --replicas=5' defines actions to execute, not the desired end state, so it fails to satisfy this principle.

Answer

GitOps tools only support JSON files and reject any YAML or shell-based configurations.

Answer

Cron jobs running in Kubernetes cannot execute kubectl commands against the internal API server.

Answer

Imperative scripts cannot be stored in Git repositories due to file permission limitations.

Question 6

During an audit, an organization discovers that a secret was accidentally committed to a Git repository managed by Flux. An engineer deletes the commit containing the secret using 'git push --force' with a rewritten history. Why is this action problematic in a production GitOps environment?

Accepted Answer

Force-pushing history breaks the cryptographic chain of custody and can desynchronize agents expecting immutable, append-only history.. Force-pushing a rewritten history in a GitOps environment is problematic because it breaks the append-only, immutable history that GitOps agents rely on for cryptographic chain of custody and consistent reconciliation. Flux CD and similar tools expect the Git history to be immutable; rewriting it can cause agents to become desynchronized, as they may have already reconciled a commit that no longer exists, leading to unpredictable behavior.

Answer

Kubernetes secrets created before the force-push are automatically converted into ConfigMaps by the API server.

Answer

Flux automatically restores deleted Git commits by fetching missing objects from the live cluster memory.

Answer

Git repositories permanently reject future commits if a force-push is detected by the GitOps operator.

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

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 9

A senior cloud architect is designing a multi-tenant platform using GitOps. They want to ensure that continuous drift detection and correction operate reliably without causing system instability. Which TWO practices help mitigate risks associated with automated continuous drift correction?

Accepted Answer

Configuring the GitOps controller to ignore specific dynamic fields updated by in-cluster controllers, such as 'spec.replicas' managed by a HorizontalPodAutoscaler (HPA).. Option C is correct because GitOps controllers such as Argo CD or Flux continuously reconcile live state to Git, and fields like 'spec.replicas' that are legitimately mutated by an in-cluster controller (an HPA) will otherwise be perpetually reverted, causing a fight between controllers and instability; configuring ignoreDifferences (Argo CD) or equivalent field exclusions prevents this. Option E is correct because running drift detection in a non-mutating mode first — Argo CD's diff view or sync with --dry-run, or alerting on OutOfSync status — surfaces unexpected drift to teams before self-healing applies destructive changes (e.g., deleting or recreating critical resources), which is the standard risk-mitigation pattern for automated correction. Option A is wrong because granting cluster-admin to all developers and allowing manual disabling of drift correction destroys the security model and auditability of GitOps rather than mitigating risk. Option B is wrong because removing Git versioning and comparing against an unversioned NFS share eliminates the single source of truth, rollback capability, and drift provenance that GitOps depends on. Option D is wrong because a 30-second reconciliation interval with a full node reboot per iteration is operationally catastrophic and would itself cause the instability the architect is trying to avoid.

Answer

Granting full cluster-admin permissions to all application developers so they can manually disable drift correction during deployments.

Answer

Disabling Git versioning so that drift detection compares live state against an unversioned NFS network share.

Answer

Setting the reconciliation loop interval to run once every 30 seconds while forcing a full cluster node reboot on every iteration.

Question 10

A platform team manages 50 Kubernetes clusters using GitOps. They need to ensure that an emergency rollback of an application across all clusters can be executed cleanly and audited effectively. What is the standard GitOps mechanism to achieve this rollback?

Accepted Answer

Revert the bad commit in the Git repository using 'git revert' and merge the change.. In GitOps, the desired state is stored in Git, so rolling back an application is done by reverting the bad commit in Git and merging it. The GitOps controller then reconciles the clusters to the reverted state, providing a clean, auditable rollback across all clusters.

Answer

Execute 'helm rollback' on each individual cluster CLI in parallel.

Answer

Delete the target namespace in each cluster and let the API server re-download the manifest from cache.

Answer

Power down the GitOps controller pods so the clusters automatically default to their initial factory settings.

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

A company uses Flux to manage a Kubernetes cluster. During a recent security audit, they found that an engineer manually edited a ConfigMap directly in the live cluster using 'kubectl edit', causing the cluster state to drift from the Git repository. The engineer wants to ensure that such manual changes are automatically reverted to match Git. Which GitOps principle should they enforce?

Accepted Answer

Continuous reconciliation. Continuous reconciliation ensures the cluster state is continuously compared to the desired state in Git and any drift is corrected. Manual edits like the ConfigMap change are automatically reverted, enforcing the Git repository as the single source of truth. This principle is fundamental to GitOps and is implemented by tools like Flux and Argo CD.

Answer

Declarative configuration

Answer

Pull-based reconciliation

Answer

Immutable infrastructure

Question 13

A DevOps team is adopting GitOps for their Kubernetes environment. They want to ensure that all changes to the cluster are made through Git, and that the cluster state is always in sync with the Git repository. They also want to avoid manual kubectl commands. Which GitOps principle is most directly violated if a team member uses 'kubectl apply' to update a Deployment?

Accepted Answer

Git as the single source of truth. Git as the single source of truth requires that all desired state be stored in Git and changes be made via Git. Using 'kubectl apply' directly modifies the cluster without updating Git, causing drift and violating this principle. The reconciliation loop would eventually revert the change, but the manual action itself breaks the GitOps workflow.

Answer

Automated delivery

Answer

Immutable infrastructure

Answer

Declarative configuration

Question 14

A team is implementing GitOps for their infrastructure. They want to ensure that the entire system state is described in a way that can be versioned, reviewed, and automatically applied. Which characteristic of GitOps best describes the practice of storing all configuration as code in Git?

Accepted Answer

Declarative. The declarative characteristic of GitOps means the entire system state is described as code in Git, specifying what the system should be. This enables version control, peer review, and automated reconciliation. Storing configuration as code is a direct application of the declarative principle, making it the best description.

Answer

Procedural

Answer

Imperative

Answer

Mutable

Question 15

A company is adopting GitOps and wants to ensure their implementation follows the core principles. They are reviewing their current practices and need to identify which of the following are considered core GitOps principles. (Choose two.)

Accepted Answer

Automated reconciliation. The core GitOps principles include declarative configuration, Git as the single source of truth, automated reconciliation, and pull-based deployment. Among the options, declarative configuration and automated reconciliation are explicitly core principles. Manual approval for every change and push-based deployment contradict GitOps automation and pull-based models, while immutable infrastructure is a related but not core principle.

Answer

Push-based deployment

Answer

Manual approval for every change

Answer

Immutable infrastructure