CGOA Gitops Terminology — 25 Questions

Question 1

You are using Flux and need to ensure that specific resources are ignored by the reconciliation process. Which feature should you utilize?

Accepted Answer

Kustomization ignore annotations. Flux provides a mechanism to ignore specific resources during reconciliation using annotations on Kustomization resources. By adding the `kustomize.toolkit.fluxcd.io/reconcile: disabled` annotation, you can instruct Flux to skip reconciliation for those resources, which is essential for resources that are managed externally or should not be altered.

Answer

Namespace-level network policies

Answer

Git commit filtering

Answer

ClusterRoleBinding exclusions

Question 2

Which TWO of the following are true about 'Pull' vs 'Push' deployment models?

Accepted Answer

Pull models eliminate the need for an external CI/CD tool to access the cluster. Option A is correct because in a pull-based deployment model the in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from the Git repository, so no external CI/CD system needs network access or credentials to reach the cluster API. Option D is correct because the pull-model operator/agent runs inside the cluster and therefore must itself hold the RBAC permissions and cluster access required to apply manifests and reconcile resources. Option B is wrong because pull models scale to clusters of any size; the agent's reconciliation loop is not limited to small clusters. Option C is wrong because GitOps is characteristically implemented with pull-based reconciliation, not push. Option E is wrong because push models require external systems to hold cluster credentials, which generally increases rather than reduces the attack surface.

Answer

Pull models only support small clusters

Answer

Push models are the standard for GitOps

Answer

Push models are inherently more secure

Question 3

What is the primary function of a 'Namespace' in an Argo CD Application?

Accepted Answer

To restrict where the operator deploys resources. In an Argo CD Application, the destination namespace field specifies which Kubernetes namespace the application's resources will be deployed into. It restricts the deployment target, ensuring manifests are applied to the intended namespace rather than the default. This is a deployment scoping mechanism, not a runtime isolation feature.

Answer

To store container images

Answer

To store Git history

Answer

To provide network isolation

Question 4

Which TWO of the following are standard GitOps workflows for promoting changes?

Accepted Answer

Updating a manifest file in a 'production' directory. Option A is correct because in GitOps the desired state of each environment is declared in Git, so promoting a change to production is done by updating the manifest file in the 'production' directory and letting the GitOps controller (e.g., Argo CD or Flux) reconcile the cluster to that new declared state. Option E is correct because updating a Git tag to point to a new release is a standard GitOps promotion mechanism: the tag references the immutable artifact/commit, and the controller detects the change and rolls it out. Option B is not a GitOps workflow because running a manual script on the live server mutates the environment outside of Git, breaking the single source of truth and drift detection. Option C is not a promotion workflow because reinstalling the Kubernetes cluster is a destructive infrastructure action, not a controlled change promotion. Option D is not GitOps because using a UI wizard to bypass Git circumvents the declarative, version-controlled pipeline that defines GitOps.

Answer

Running a manual script on the live server

Answer

Reinstalling the Kubernetes cluster

Answer

Using a UI wizard to bypass Git

Question 5

Which TWO of the following are standard ways to structure environment configurations?

Accepted Answer

Using separate repositories for each environment. Option A is correct because maintaining separate repositories per environment (e.g., a dev repo and a prod repo) is a recognized pattern for isolating environment-specific configuration, allowing each environment's settings, branches, and access controls to evolve independently. Option D is correct because organizing configurations into distinct folders such as dev/ and prod/ is a standard directory-based structuring approach that keeps environment-specific files (e.g., application-dev.yml vs application-prod.yml) cleanly separated within one codebase. Option B is not a standard structural pattern for environment configuration because an external database is a storage mechanism, not a way to organize or lay out configuration files. Option C is incorrect because hardcoding environment names into deployment scripts creates brittle, non-reusable automation rather than a structured configuration scheme. Option E is incorrect because embedding all environments in a single flat file mixes concerns, invites key collisions, and makes environment-specific overrides error-prone.

Answer

Using an external database to store config

Answer

Hardcoding environment names in the deployment script

Answer

Embedding all environments in a single flat file

Question 6

Which THREE of the following are core responsibilities of a GitOps operator?

Accepted Answer

Detecting drift between the cluster state and the Git source. Option A is correct because a GitOps operator's fundamental job is to compare the live cluster state against the desired state stored in Git, thereby detecting configuration drift. Option D is correct because once drift is detected, the operator must apply the necessary changes (for example, via server-side apply or kubectl-equivalent reconciliation) to bring the live state back into alignment with the declared state. Option E is correct because the operator must continuously watch or poll the Git repository so that any commit to the desired state is promptly noticed and acted upon, which is the essence of the pull-based GitOps model. Options B and C are not core responsibilities: writing CI/CD build scripts belongs to the CI pipeline and application teams, not the GitOps operator, and executing manual kubectl commands for developers is an ad-hoc human action that contradicts the automated, declarative reconciliation the operator performs.

Answer

Writing CI/CD build scripts

Answer

Executing manual kubectl commands for developers

Question 7

When setting up Argo CD, which TWO components are essential to define a GitOps workflow?

Accepted Answer

AppProject. In Argo CD, the Application CRD (option C) is essential because it defines the desired state of a deployed application by linking a source Git repository (with path and target revision) to a destination Kubernetes cluster and namespace, which is the core of the GitOps reconciliation loop. The AppProject (option B) is also essential because it provides the logical grouping and RBAC boundary that restricts which repositories, clusters, and namespaces an Application may use, enforcing multi-tenancy and security in the GitOps workflow. A Kubernetes Node (option A) is just the underlying compute host where Argo CD and workloads run; it is infrastructure, not a GitOps workflow definition. A Docker Registry (option D) stores container images but is not required by Argo CD to define GitOps, since Argo CD syncs Kubernetes manifests from Git rather than images directly. A Jenkins Pipeline (option E) is a CI tool and is not part of Argo CD's GitOps model, which is pull-based and driven by the Application and AppProject resources.

Answer

Kubernetes Node

Answer

Docker Registry

Answer

Jenkins Pipeline

Question 8

You are troubleshooting a Flux installation. The operator is failing to pull updates from a private GitHub repository. What component is most likely misconfigured?

Accepted Answer

The GitRepository secret. Flux uses a GitRepository custom resource to define the source repository, including the URL, branch, and authentication secret. If the operator cannot pull updates from a private GitHub repository, the most likely misconfiguration is the GitRepository secret — the credentials (e.g., SSH key or token) referenced by the GitRepository are incorrect, missing, or lack permissions.

Answer

The Helm chart version

Answer

The cluster service account permissions

Answer

The Kustomization path

Question 9

A company transitions from a push-based CI/CD pipeline (using Jenkins) to a pull-based GitOps model (using Flux). What is the primary security architectural change regarding cluster access?

Accepted Answer

The CI server no longer requires cluster credentials. In a pull-based GitOps model, the in-cluster operator (Flux) pulls desired state from Git and applies it from inside the cluster. The CI server's only job is to build and push artifacts and commit manifest changes to Git — it never needs kubeconfig or cluster API credentials. This removes the long-lived cluster credentials that a push-based Jenkins pipeline required to run kubectl/helm against the cluster.

Answer

Git is no longer the source of truth

Answer

The cluster no longer requires an API server

Answer

The operator is now a push-based agent

Question 10

You are auditing your GitOps deployment strategy. Which TWO of the following statements correctly describe the 'Source of Truth' in a GitOps architecture?

Accepted Answer

The declared state in the Git repo must match the observed cluster state. Option B is correct because GitOps relies on continuous reconciliation: the declared state stored in Git must be kept in sync with the observed state of the live cluster, and any drift is detected and corrected by a controller such as Argo CD or Flux. Option C is correct because in GitOps the Git repository is the single source of truth for both infrastructure and application manifests, serving as the authoritative declarative specification from which all deployments are derived. Option A is incorrect because the live cluster state is the observed state, not the source of truth; it is compared against Git and reconciled to match it. Option D is incorrect because database backups are for data recovery and are unrelated to the declarative configuration source of truth in GitOps. Option E is incorrect because CI artifacts (build outputs, images) are produced by pipelines and are not the authoritative declarative source; Git holds the desired state that references such artifacts.

Answer

The live cluster state is the ultimate source of truth for all configurations

Answer

Database backups constitute the primary source of truth

Answer

Continuous Integration artifacts are the source of truth

Question 11

What is the primary benefit of a 'pull' deployment model compared to a 'push' model in GitOps?

Accepted Answer

Reduced need for inbound firewall access to the cluster. In a pull-based GitOps model, an in-cluster agent (e.g., Argo CD or Flux) continuously reconciles the desired state from Git with the live cluster. Because the agent initiates outbound connections to Git and the cluster does not need to accept inbound connections from an external CI/CD system, the need for inbound firewall access to the cluster is significantly reduced — a major security and operational benefit.

Answer

Support for non-Kubernetes platforms

Answer

Elimination of Kubernetes manifests

Answer

Faster application builds

Question 12

You are configuring an Argo CD application. After a developer manually modifies a Kubernetes Service via kubectl, the application status changes to 'OutOfSync'. Which GitOps principle is this monitoring process specifically identifying?

Accepted Answer

Drift detection. When a developer edits a Service directly with kubectl, the live state diverges from the desired state in Git, and Argo CD flags the Application as OutOfSync. This is precisely drift detection: the continuous comparison between the cluster's actual state and the Git-declared state. Argo CD's application-controller polls or watches resources and computes a diff, surfacing any divergence as OutOfSync until reconciled.

Answer

Rollback recovery

Answer

Image promotion

Answer

Webhook integration

Question 13

An administrator notices that the 'sync' status of an Argo CD application is 'Synced' but the health status is 'Degraded'. What does this indicate?

Accepted Answer

The application is correctly defined in Git but is failing at runtime. A 'Synced' sync status means the live cluster resources match the desired manifests in Git — there is no configuration drift. A 'Degraded' health status, however, is reported by Argo CD's health assessment (based on resource readiness, e.g., a Deployment with unavailable replicas or a Pod in CrashLoopBackOff) and indicates the workloads are not functioning correctly at runtime. Together they signal that the desired state was applied successfully but the application itself is failing.

Answer

The Argo CD controller has crashed

Answer

The Git repository is unreachable

Answer

Git and the cluster state are mismatched

Question 14

Which THREE of the following represent common symptoms of 'drift' in a GitOps-managed cluster?

Accepted Answer

Unexpected changes to resource labels or annotations. Drift in a GitOps-managed cluster means the live state diverges from the desired state declared in Git, so option A is correct because unexpected changes to resource labels or annotations indicate someone or something modified objects outside the Git workflow, breaking the declared manifest. Option B is correct because manually editing a ConfigMap via kubectl changes the live cluster state directly, bypassing Git as the single source of truth and creating drift that a reconciler like Argo CD or Flux would detect and revert. Option D is correct because unauthorized scaling of a deployment alters the replica count away from the value in Git, a classic drift symptom that reconciliation would flag or correct. Option C does not belong because a successful CI pipeline execution is a normal build/test outcome and says nothing about live cluster state diverging from Git. Option E does not belong because a long Git commit history is simply normal repository activity and is unrelated to whether the cluster's actual state matches the desired state.

Answer

Successful CI pipeline execution

Answer

Git commit history being too long

Question 15

In a GitOps environment, what is the 'Reconciliation Loop' primarily responsible for?

Accepted Answer

Continuously ensuring the cluster state matches the Git repository. The Reconciliation Loop is the core control mechanism in GitOps that continuously compares the desired state declared in Git with the actual live state of the Kubernetes cluster. When a difference (drift) is detected, the loop applies the necessary changes to bring the cluster back into alignment with Git, which is the single source of truth. This continuous, automated convergence is what makes GitOps declarative and self-healing rather than a one-time push deployment.

Answer

Running unit tests on application code

Answer

Generating new Kubernetes manifests

Answer

Managing user authentication for the Git provider

Question 16

When a GitOps tool reports a 'Sync Error', what is the most likely cause?

Accepted Answer

The manifest contains invalid Kubernetes syntax. A 'Sync Error' in a GitOps tool such as Argo CD or Flux means the operator successfully retrieved the desired state from Git but failed to apply it to the cluster. The most common root cause is that the manifest itself is invalid — malformed YAML, an unknown API version, a missing required field, or a schema violation that the Kubernetes API server rejects. Because the error surfaces during the apply/reconcile step rather than the fetch step, it points squarely at the manifest content rather than connectivity or infrastructure capacity.

Answer

The Git repository is deleted

Answer

The cluster has too many nodes

Answer

The network latency is high

Question 17

Which TWO of the following are benefits of using Git as the 'Source of Truth'?

Accepted Answer

Clear audit trail of who changed what and when. Option A is correct because Git records every commit with author identity, timestamp, and a cryptographic hash of the exact changes, giving an immutable, reviewable history of who changed what and when — the essence of an audit trail for a source of truth. Option B is correct because Git's versioned history lets you undo a bad change deterministically with commands like git revert (which creates a new commit that inverts a prior one) or git reset, enabling reliable rollback to a known-good state. Option C is wrong because Git is a version-control system for code and configuration, not a cloud IAM or account-lifecycle tool; it cannot detect or delete unused cloud accounts. Option D is wrong because Git reduces reliance on manual terminal access by providing a structured, reviewable workflow (commits, branches, pull requests) rather than encouraging ad-hoc manual changes. Option E is wrong because Git has no bearing on application CPU performance; it manages source history, not runtime compute resources.

Answer

Automatic removal of unused cloud accounts

Answer

Increased reliance on manual terminal access

Answer

Faster CPU performance for applications

Question 18

What is the primary function of an 'Operator' in the context of GitOps?

Accepted Answer

Automating the reconciliation process within the cluster. In GitOps, an Operator is a Kubernetes controller that extends the API with custom resources and continuously reconciles the cluster to match the declared desired state. It encodes operational knowledge — such as how to deploy, upgrade, back up, or failover an application — into software that runs inside the cluster. This automation of the reconciliation process is precisely what makes Operators central to GitOps workflows.

Answer

Hosting the Git repository

Answer

Writing application code

Answer

Executing SQL queries

Question 19

Which term best describes the process of ensuring the live cluster matches the desired state stored in Git?

Accepted Answer

Syncing. Syncing is the GitOps term for the process of applying the desired state from Git to the live cluster so that the actual state matches the declared state. In Argo CD, a sync operation applies manifests; in Flux, reconciliation achieves the same. The question describes exactly this convergence process, making 'Syncing' the correct term.

Answer

Validation

Answer

Provisioning

Answer

Compilation

Question 20

In a GitOps workflow, how does an operator handle a situation where a user manually deletes a resource that is defined in Git?

Accepted Answer

It automatically recreates the resource. A GitOps operator continuously reconciles live cluster state against the desired state declared in Git. If a resource defined in Git is manually deleted, the operator detects the drift during its next reconciliation cycle and recreates the resource to match Git. Git remains the authoritative source, so the deletion is treated as unauthorized drift to be corrected.

Answer

It creates an alert and waits for manual intervention

Answer

It updates the Git repository to reflect the deletion

Answer

It blocks all future deployments until a reset occurs