Gitops Terminology practice questions

Namespace-level network policies

Why it fails: Network policies govern pod traffic at layer 3/4 and have no bearing on which manifests Flux reconciles. They are tempting because they are a Kubernetes-native mechanism for scoping behaviour, but Flux ignores resources through annotations and field exclusions, not network rules.

Git commit filtering

Why it fails: Flux reconciles the whole Git revision; there is no commit-filtering feature that excludes individual resources from reconciliation. It is tempting because Git is the source of truth, so filtering commits appears to control what is applied, but exclusion is done via ignore annotations or spec.ignore.

ClusterRoleBinding exclusions

Why it fails: RoleBindings are not managed via exclusion lists in this way.

Pull models only support small clusters

Why it fails: Pull models scale effectively across large environments.

Push models are the standard for GitOps

Why it fails: GitOps is defined by its pull-based nature.

Push models are inherently more secure

Why it fails: Push models often require exposing the API server.

To store container images

Why it fails: Container registries store images.

To store Git history

Why it fails: Namespaces are not related to Git history.

To provide network isolation

Why it fails: Network policies handle isolation, not the namespace itself.

Running a manual script on the live server

Why it fails: GitOps avoids manual live-server scripts.

Reinstalling the Kubernetes cluster

Why it fails: This is not a promotion strategy.

Using a UI wizard to bypass Git

Why it fails: GitOps requires changes to go through Git.

Using an external database to store config

Why it fails: GitOps requires Git to be the source of truth.

Hardcoding environment names in the deployment script

Why it fails: This is not a GitOps practice.

Embedding all environments in a single flat file

Why it fails: This is unmanageable and prone to errors.

Writing CI/CD build scripts

Why it fails: A GitOps operator reconciles desired state from Git into the cluster; writing CI/CD build scripts belongs to the pipeline tooling that produces artefacts, not the operator. Build scripts would be the right responsibility for a CI engineer, not the operator.

Executing manual kubectl commands for developers

Why it fails: Executing manual kubectl commands contradicts GitOps, where a controller continuously reconciles cluster state against the declarative manifests held in Git; imperative commands bypass that reconciliation loop and leave no auditable desired-state record. It is tempting because operators do run kubectl for break-glass debugging, but that is incident response, not a core operator responsibility.

Kubernetes Node

Why it fails: A Kubernetes node is the worker host running pods; Argo CD tracks desired state in Git and reconciles it against a cluster, so the node is infrastructure rather than a GitOps workflow component. It is tempting because Argo CD deploys onto Kubernetes, but the essential pair is the Git repository and the cluster.

Docker Registry

Why it fails: A Docker registry stores container images, not the declarative manifests Argo CD watches, so it plays no part in defining the GitOps reconciliation loop. It is tempting because Argo CD deployments often pull images, but the essential components are the Git repository and the target Kubernetes cluster.

Jenkins Pipeline

Why it fails: Jenkins is a general CI server, not an Argo CD component; it neither stores desired state nor reconciles it into the cluster. It tempts because Jenkins pipelines commonly build the images Argo CD later deploys, yet the essential GitOps pair is the Argo CD application controller and the Git repository holding manifests.

The Helm chart version

Why it fails: The Helm chart version affects which chart revision is rendered, not whether Flux can authenticate to a private GitHub repository, so the pull fails regardless of version. It is tempting because version mismatches cause many deployment faults, and would be correct if the source were reachable but the chart revision were wrong.

The cluster service account permissions

Why it fails: Cluster service account permissions govern what workloads inside the cluster may do; they play no part in Flux authenticating outbound to GitHub. It is tempting because RBAC misconfiguration is a frequent Kubernetes fault, and would be correct if the failure involved in-cluster API access rather than an external private repository.

The Kustomization path

Why it fails: The Kustomization path only locates manifests within an already-fetched source; it cannot authenticate to GitHub, so a wrong path yields missing files, not a pull failure. It is tempting because path errors are common Flux faults, and would be correct if the repository were reachable but the manifests sat elsewhere.

Git is no longer the source of truth

Why it fails: Git becomes the single source of truth in GitOps, with Flux continuously reconciling cluster state against it. Abandoning Git describes no GitOps model at all; the tempting confusion is that CI still builds artefacts, yet desired state is declared and versioned in Git.

The cluster no longer requires an API server

Why it fails: The API server remains essential; Flux reconciles by watching Git and applying changes through it. Removing it is tempting when contrasting pull with inbound push access, but the architectural shift is that nothing external initiates connections, not that the control plane endpoint disappears.

The operator is now a push-based agent

Why it fails: Flux runs inside the cluster as a controller that pulls manifests from Git, so it is not a push-based agent reaching outward. A push agent describes the Jenkins model being replaced, where the pipeline holds credentials and initiates connections to the cluster API server.

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

Why it fails: GitOps treats the live cluster as a reconciled target that is continuously corrected, never as the authoritative source; Git holds that role. It is tempting because the cluster reflects what is actually running, which would be correct under imperative or manually administered models where no declarative repository exists.

Database backups constitute the primary source of truth

Why it fails: Database backups capture data state for recovery, not the declarative configuration GitOps reconciles against, so they cannot serve as the source of truth. It is tempting because backups are authoritative for restoring data, which would be correct when the concern is data durability rather than configuration drift.

Continuous Integration artifacts are the source of truth

Why it fails: CI artifacts are build outputs consumed by pipelines, not the declarative desired state that GitOps reconciles the cluster against. It is tempting because artifacts are versioned and immutable, which would be correct when tracing which binary was deployed rather than determining the authoritative configuration source.

Support for non-Kubernetes platforms

Why it fails: Pull reconciliation targets Kubernetes clusters via in-cluster agents; non-Kubernetes support is unrelated to the pull mechanism and requires separate tooling. It is tempting because pull agents can run anywhere, but the actual benefit is that the cluster fetches desired state, so drift is detected and corrected without exposing credentials to CI.

Elimination of Kubernetes manifests

Why it fails: Pull deployment still applies Kubernetes manifests; the agent reconciles them from Git rather than removing them. It is tempting because the agent handles reconciliation automatically, but manifests remain the declarative source of truth. The genuine benefit is continuous drift detection and correction inside the cluster, without inbound CI access.

Faster application builds

Why it fails: Build speed is determined by the CI pipeline compiling and testing artefacts, not by how deployment state is fetched. It is tempting because pull removes CI's cluster credentials, which feels faster, but the real benefit is that the in-cluster agent continuously reconciles Git-declared state, correcting drift without inbound access.

Rollback recovery

Why it fails: Rollback recovery restores a previous known-good state after a failed deployment; it does not detect drift. Argo CD flags OutOfSync because live cluster state diverges from Git, which is drift detection. Rollback would be correct when a released revision must be reverted to an earlier commit.

Image promotion

Why it fails: Image promotion updates a Git manifest to reference a new image tag, typically via CI automation; it does not detect cluster drift. OutOfSync appears because Argo CD's reconciliation compares live state with Git and finds the manual Service edit. Image promotion would be correct when advancing a tested build to the next environment.

Webhook integration

Why it fails: Webhooks notify Argo CD of Git repository events to trigger faster syncs; they do not compare live cluster state against desired state. The OutOfSync status arises from Argo CD's reconciliation loop detecting the manual kubectl change diverging from Git. Webhooks would be correct to reduce polling delay after a commit.

The Argo CD controller has crashed

Why it fails: A crashed controller stops reconciliation entirely, so the application would not report Synced; the status would go stale or unknown. It is tempting because a degraded application suggests something is broken, and it would be correct when the controller pod is down and no sync status updates appear at all.

The Git repository is unreachable

Why it fails: An unreachable repository produces a comparison error or Unknown sync status, not Synced, since Argo CD cannot render manifests to compare. It is tempting because connectivity failures do disrupt reconciliation, but here the application already reports Synced, so Git access is demonstrably working.

Git and the cluster state are mismatched

Why it fails: Synced means Git and cluster manifests match, so this contradicts the stated status. It is tempting because drift between desired and live state is a common cause of trouble, but drift produces OutOfSync, not Degraded, which instead reflects unhealthy pods or failed resources.

Successful CI pipeline execution

Why it fails: A successful CI run is the expected healthy state, not drift; drift is divergence between the Git-declared desired state and the live cluster. It is tempting because CI success confirms the pipeline pushed manifests, but that says nothing about whether the cluster still matches them after manual edits or deletions.

Git commit history being too long

Why it fails: Commit history length is unrelated to drift, which is divergence between Git-declared state and live cluster state. It is tempting because long histories feel like repository clutter, but commit count is a normal artefact of development; drift symptoms include out-of-sync resources and manual kubectl changes.

Running unit tests on application code

Why it fails: Unit tests execute in CI pipelines against source code, not inside the GitOps controller, which only compares desired and live cluster state. It is tempting because reconciliation is often conflated with continuous delivery pipelines that do run tests before manifests are committed.

Generating new Kubernetes manifests

Why it fails: Manifests are authored and committed by developers or templating tools; the reconciliation loop reads them and applies the desired state, it does not create them. It is tempting because the controller does render and apply manifests, which looks like generation to anyone unfamiliar with the source-of-truth model.

Managing user authentication for the Git provider

Why it fails: Authentication to the Git provider is handled by credentials, deploy keys or tokens configured on the controller, not by the reconciliation loop itself. It is tempting because the controller must authenticate to poll the repository, so its polling activity is easily mistaken for identity management.

The Git repository is deleted

Why it fails: A deleted repository makes the source unreachable, producing a fetch or authentication failure, not a Sync Error. Sync Errors arise when the tool cannot reconcile live cluster state with the desired manifests it has already retrieved. Repository deletion would be the answer if the stem described a missing or inaccessible Git remote.

The cluster has too many nodes

Why it fails: Node count is irrelevant to reconciliation; a Sync Error means the tool cannot apply the desired Git state, typically due to invalid manifests, missing resources or permission failures. It tempts because large clusters do surface operational issues, but scale affects performance, not whether Git and live state diverge.

The network latency is high

Why it fails: Sync Errors arise when the tool cannot reconcile desired Git state with the cluster — a deleted manifest, invalid YAML or RBAC denial — not from transport latency, which merely slows reconciliation. High latency is tempting because network problems do disrupt operations, but latency causes timeouts, not the state-divergence error GitOps reports.

Automatic removal of unused cloud accounts

Why it fails: Git tracks configuration files, not cloud account lifecycles; it cannot detect or delete unused accounts, which requires IAM governance tooling. It is tempting because version control does record infrastructure changes, so teams assume it manages the resulting resources, but deletion is outside its scope.

Increased reliance on manual terminal access

Why it fails: Git replaces manual terminal changes with reviewed commits, so it reduces rather than increases hands-on access. It is tempting because engineers still run git commands locally, but the benefit sought is auditable, peer-reviewed change history, not greater dependence on interactive shells.

Faster CPU performance for applications

Why it fails: Git tracks commits, branches and merges of source files; it never executes application code, so it cannot influence CPU performance. Git would be the correct source of truth where teams need versioned, auditable configuration and code history.

Hosting the Git repository

Why it fails: Hosting the Git repository is the function of a Git server such as GitHub or GitLab, which stores the desired-state manifests GitOps reconciles from. A Kubernetes Operator runs inside the cluster as a controller. It is tempting because Git is central to GitOps, but the Operator consumes that repository rather than hosting it.

Writing application code

Why it fails: Writing application code is the developer's task committed to Git; a Kubernetes Operator is a controller extending the API to reconcile cluster state with declared custom resources. It is tempting because Operators are built by developers, but the code they run automates operational reconciliation, not application logic.

Executing SQL queries

Why it fails: Executing SQL queries belongs to the database engine or a client, not to a Kubernetes Operator, which watches custom resources and drives cluster state toward the declared spec. It is tempting because Operators often manage database instances, but they provision and reconcile those workloads rather than run queries themselves.

Validation

Why it fails: Validation checks that manifests are syntactically and schematically correct before they are applied; it does not continuously compare live cluster state with Git. It is tempting because GitOps pipelines validate YAML and policies, but that is a pre-deployment gate, not the ongoing reconciliation loop.

Provisioning

Why it fails: Provisioning creates infrastructure or cluster resources initially; it does not continuously reconcile live state against Git afterwards. It is tempting because GitOps tooling can provision clusters, but the question asks about maintaining alignment, which is reconciliation, not one-off creation of resources.

Compilation

Why it fails: Compilation converts source code into executable artefacts; it never compares live cluster state against Git. It is tempting because CI pipelines compile manifests or Helm charts before deployment, so the word appears in GitOps tooling, but reconciliation is the term for continuously aligning cluster state with the declared desired state.

It creates an alert and waits for manual intervention

Why it fails: GitOps operators continuously reconcile cluster state to match Git, so a manually deleted resource is recreated automatically rather than flagged for a human. Alerting and waiting suits drift-detection tooling that reports divergence without enforcing the declared state.

It updates the Git repository to reflect the deletion

Why it fails: GitOps treats Git as the single source of truth, so an operator's reconciliation loop recreates the deleted resource from the manifest rather than amending Git. Committing the deletion would make Git match reality, which is the reverse direction; that approach fits deliberately decommissioning a resource by removing its manifest.

It blocks all future deployments until a reset occurs

Why it fails: Halting deployments is not part of reconciliation; the operator simply reapplies the manifest and restores the resource, so no reset is needed. Blocking until manual intervention resembles a policy gate or freeze, which suits change-control windows rather than drift correction.