Gitops Principles practice questions

The Git repository is automatically updated.

Why it fails: Argo CD does not modify the source Git repository.

The cluster is wiped completely.

Why it fails: Only the resources managed by that app might be affected.

Nothing happens.

Why it fails: Argo CD will act on its configuration.

Automated reconciliation

Why it fails: This refers to the controller's action, not the review process.

Continuous drift detection

Why it fails: Drift detection identifies discrepancies, it does not enforce the review process.

Declarative desired state

Why it fails: Declarative state defines the 'what', but not the workflow for approval.

Edit the Deployment directly with kubectl scale and later reconcile by reverting the change in Git.

Why it fails: Directly scaling with kubectl bypasses the GitOps pull-based reconciliation model. Flux will detect the drift and may revert the manual change, causing instability. This approach violates the principle that Git is the single source of truth for desired state and makes the canary change non-auditable and non-revertible through version control.

Add an imperative script to the CI pipeline that runs kubectl scale only during the canary window.

Why it fails: An imperative script in CI reintroduces push-based deployment, which conflicts with GitOps pull-based reconciliation. The script would not be part of the declarative desired state, making the canary change invisible to Flux and prone to being overwritten. It also complicates auditability and rollback compared to a Git-based change.

Commit the replica change to a short-lived branch, open a pull request, and merge it only after the canary test completes.

Why it fails: A short-lived branch with a pull request keeps the change reviewed, but merging after the canary test means the desired state in Git is not updated during the test. Flux reconciles only the configured branch, so the cluster would never apply the canary replica count while the test runs, defeating the purpose.

Pull-based deployment

Why it fails: Pull-based deployment means the agent in the cluster pulls changes from Git. Argo CD uses a pull-based model, but the workflow described focuses on the review and automated sync, not on the direction of the deployment. The pull-based aspect is inherent in Argo CD's operation, but the primary principle demonstrated by the review and automatic sync is automated reconciliation.

Git as the single source of truth

Why it fails: Git as the single source of truth means all desired state is stored in Git. While the pull request workflow involves Git, the primary demonstration is about the review process and automated sync, not solely about Git being the source of truth. The principle is broader and includes the idea that changes are made via Git, but the specific workflow emphasizes the review and automation aspect.

Declarative configuration

Why it fails: Declarative configuration means the desired state is expressed as code. The workflow uses declarative manifests, but the focus is on the review and automated application, not on the declarative nature itself. The principle is about how the state is described, not about the process of reviewing and syncing changes. Thus, it is not the primary principle demonstrated.

Faster deployment of hotfixes directly to production

Why it fails: Immutable Git state records versioned configuration; it does not itself deploy hotfixes to production, which requires a pipeline and release process. It is tempting because Git enables rapid, traceable changes, and it would be correct if the question asked about source control supporting fast, auditable releases.

Automated conversion of Docker images to YAML

Why it fails: Git stores versioned files and does not convert Docker images into YAML; that transformation belongs to tooling such as image inspection or templating. It is tempting because GitOps stores Kubernetes manifests as YAML in Git, but the conversion is performed by external tools, not by immutability itself.

Increased server-side storage capacity

Why it fails: Git stores commits, trees and blobs as content-addressed objects; repository size is driven by history, not server capacity, so immutability does not increase storage. It is tempting because large histories consume disk, but capacity is an infrastructure concern, not a benefit of immutable state.

Grant the cluster node broad read access to all public repositories.

Why it fails: This is overly permissive and insecure.

Use an environment variable in the Argo CD container deployment manifest.

Why it fails: Environment variables are less secure than secrets and harder to manage for multiple repositories.

Hardcode the credentials in the Application manifest.

Why it fails: Hardcoding credentials violates security best practices.

Git commit hook triggers

Why it fails: A Git commit hook triggers pipeline or sync activity when repository content changes, but it does not watch the cluster, so out-of-band kubectl edits never fire it. Commit hooks suit automating builds or syncs on push, not reverting live drift.

Kubernetes admission controllers

Why it fails: Admission controllers validate or mutate API requests at creation time; they do not continuously reconcile live cluster state against Git, so a kubectl edit that passes admission persists. Argo CD's self-heal sync loop performs that reconciliation. Admission controllers suit policy enforcement, such as blocking privileged pods, not reverting drift.

Manual refresh button

Why it fails: Manual refresh only re-queries Git and the cluster on demand; it does not continuously reconcile live state, so kubectl edits would persist until someone clicks it. It is used to force an immediate sync check after a Git change, not to enforce ongoing desired-state convergence.

The developer's local kubectl client.

Why it fails: In pull-based GitOps, an in-cluster agent such as Flux or Argo CD polls the repository; a developer's kubectl client never initiates reconciliation. kubectl suits imperative, push-style deployments, which is the pattern pull-based GitOps deliberately replaces.

The CI/CD pipeline pushes updates to the cluster.

Why it fails: A push-based CI/CD pipeline inverts the pull model: the pipeline sends manifests to the cluster rather than the cluster's GitOps agent polling Git. It is tempting because pipelines do deploy applications, but here the agent must initiate outbound polling of the repository.

The Git server pushes changes to the cluster webhook.

Why it fails: Pull-based GitOps has the cluster agent fetch from Git; the Git server never pushes to a cluster webhook, which describes a push-based model. Server-initiated webhooks suit push-based GitOps, where CI or Git triggers cluster deployment directly.

The cluster ingress controller

Why it fails: An ingress controller routes external HTTP/S traffic into cluster services; it never compares live objects with Git manifests. Argo CD's application controller detects and reverts drift. Ingress controllers are tempting because they are cluster-resident controllers, but their reconcile loop concerns load-balancer and routing configuration, not Git-declared desired state.

The Argo CD API server

Why it fails: The API server serves the UI, CLI and gRPC requests; it does not reconcile cluster state against Git. Argo CD's application controller performs that sync loop, reverting drift. The API server is tempting because it is the visible entry point for Argo CD operations, but it only exposes and manages resources.

The Git webhook listener

Why it fails: A Git webhook listener merely notifies Argo CD that a repository changed, triggering a refresh; it does not continuously reconcile live cluster state. The application controller reverts kubectl drift. Webhooks are tempting because they link Git events to Argo CD, but they act only on repository pushes, not on out-of-band cluster edits.

The controller ignores the change until the next git commit.

Why it fails: Reconciliation runs continuously against the declared state, so the controller recreates the Deployment immediately rather than waiting for a commit. Deferring to the next commit suits pipelines that only apply on push, but GitOps controllers detect and correct drift independently of repository activity.

The system issues an alert but does not modify the cluster.

Why it fails: Alerting alone leaves the cluster diverged from the Git-declared state; reconciliation must actively recreate the Deployment. It is tempting because monitoring tools do raise drift alerts, but that suits observability-only setups, not GitOps controllers whose defining behaviour is automatic self-healing.

The manual deletion is permanently synced to the Git repository.

Why it fails: GitOps reconciliation treats Git as the source of truth, so the controller recreates the deleted Deployment instead of writing the deletion back. It is tempting because syncing cluster state to Git describes some bidirectional tools, and would apply where Git is not authoritative.

Manual approval is required for all production deployments

Why it fails: GitOps declares desired state in Git and reconciles automatically; manual approval gates contradict continuous reconciliation and are not a CNCF principle. It is tempting because approval gates are common in regulated CI/CD, and it would be correct for change-control pipelines, not GitOps.

Software must be delivered using push-based CI/CD pipelines

Why it fails: GitOps uses pull-based agents that reconcile cluster state from Git, not push-based pipelines delivering software. It is tempting because push-based CI/CD is the conventional delivery model, and it would be correct for traditional deployment pipelines rather than GitOps reconciliation.

Running a pipeline to execute terraform apply on demand

Why it fails: Running terraform apply on demand executes an imperative pipeline action; the desired state is not continuously reconciled from a Git-declared source of truth. It is tempting because Terraform does describe infrastructure declaratively, but it would be correct when a GitOps controller watches the repository and applies changes automatically.

Writing a bash script to update image tags on all clusters

Why it fails: A bash script applies imperative commands sequentially, so the cluster state is not declared in Git and cannot be reconciled automatically. It is tempting because scripting automates changes, but it would be correct for one-off migrations or bootstrapping tasks rather than ongoing desired-state management.

Using kubectl edit to modify running pod replicas

Why it fails: kubectl edit mutates live cluster state imperatively, leaving no committed desired-state record, so Git cannot reconcile drift. It is tempting because it changes replicas quickly, but it would be correct only for ad-hoc debugging, not for declaring the intended state of the system.

The repository pulls changes from the cluster.

Why it fails: In pull-based GitOps the cluster pulls desired state from the Git repository, not the reverse; Git remains the single source of truth and is never written to by the cluster. The wording tempts candidates by inverting the direction, but the agent's reconciliation only reads from Git.

The cluster is pulled into the development network.

Why it fails: Pull-based GitOps means the in-cluster agent pulls manifests from Git; the cluster is never pulled into a development network. The phrasing tempts candidates by reusing "pull" loosely, but the architecture concerns state reconciliation direction, not network topology or environment relocation.

Developers push code to the cluster API.

Why it fails: Pull-based GitOps has an in-cluster agent (Argo CD or Flux) reconcile desired state from Git; developers never push to the cluster API, which is the push-based model GitOps replaces. Pushing manifests directly is tempting because CI pipelines commonly do it, but that bypasses the reconciliation loop.

External systems pull logs from the cluster.

Why it fails: Pull-based GitOps concerns how the cluster retrieves desired state from Git, not log collection. External log scraping is tempting because observability tooling does pull telemetry, but that is unrelated to the deployment reconciliation model the term describes.

To increase the storage capacity of the cluster.

Why it fails: Immutability concerns preventing in-place mutation of declared objects, not provisioning storage; capacity is handled by PersistentVolumes, StorageClasses and CSI drivers. It is tempting because immutable artefacts are often versioned alongside infrastructure, but the concept never governs cluster disk sizing.

To allow the cluster to delete resources at will.

Why it fails: GitOps immutability means declared state is never mutated in place; the cluster reconciles toward Git rather than deleting resources at will. Deletion-at-will describes garbage collection or manual kubectl pruning, which would let live state drift from the repository and defeat the audit trail immutability exists to provide.

To force developers to use a specific IDE.

Why it fails: Immutability constrains how declared state may change, not which editor a developer uses; IDE choice is unrelated to repository reconciliation. It is tempting because immutable infrastructure is often paired with tooling standards, yet no GitOps mechanism enforces or requires a particular IDE.

The controller alerts the administrator but takes no action.

Why it fails: GitOps controllers such as Flux and Argo CD continuously reconcile, automatically reverting drift to match Git rather than merely alerting. Alert-only behaviour fits monitoring tools, whereas a Git source of truth is chosen precisely to enforce the declared state.

The Git repository is updated to reflect the new cluster state.

Why it fails: GitOps treats Git as declarative desired state, so a reconciler such as Flux or Argo CD reverts the cluster to match the repository, not the reverse. Writing cluster state back into Git is tempting because Git can store manifests, but that flow suits capturing drift for review, not automated reconciliation.

The cluster ignores the Git repository until a new commit is pushed.

Why it fails: Reconciliation is continuous; the controller keeps applying the Git-declared state and does not wait for a new commit. Ignoring Git until the next push describes a manual, commit-triggered deployment pipeline, not a GitOps controller watching the repository.

Role-Based Access Control (RBAC).

Why it fails: RBAC controls who may perform actions on cluster resources; it can block a developer's edit but does not detect or revert drift already applied. It tempts because restricting permissions is a common safeguard, yet the scenario needs automatic correction. Continuous reconciliation against Git restores the ConfigMap without human intervention.

External DNS.

Why it fails: External DNS publishes service and ingress records to external DNS providers; it does not watch or restore ConfigMap contents. It tempts because it is a GitOps-adjacent controller that reconciles desired state, but only for DNS records. A reconciliation loop comparing cluster objects to Git would revert the manual edit.

CI/CD pipeline triggers.

Why it fails: Pipeline triggers start builds and deployments on events; they do not continuously reconcile cluster state against Git, so a manual ConfigMap edit persists. It tempts because CI/CD delivers manifests, but delivery is one-way. Reconciliation loops detect and revert drift, which is the GitOps feature that prevents recurrence.

Install a plugin that logs all kubectl commands.

Why it fails: Logging kubectl commands provides an audit trail after the fact but leaves manual writes fully permitted, so it cannot ensure resources are unmodifiable. Command logging suits forensic or compliance visibility requirements, not enforcement of a Git-only change path.

Add a firewall rule to block kubectl.

Why it fails: Blocking kubectl at the network layer does not prevent modification: any client, CI job or direct API call from an allowed source still writes to the API server. Firewall rules suit restricting access to specific CIDR ranges, not enforcing that all changes flow through Git.

Disable the Kubernetes API server.

Why it fails: Disabling the API server halts all cluster operations, including the GitOps controller's own reconciliation, so nothing can be deployed at all. Taking the API server offline is appropriate only for decommissioning or isolating a cluster, never for governing change.

Using an interactive terminal to manage resources.

Why it fails: An interactive terminal changes resources imperatively through ad-hoc commands, so the desired state is never stored or reconciled. It is tempting because operators can inspect and fix clusters directly, but declarative GitOps requires the desired state to be expressed in Git and continuously reconciled by an agent.

Providing a script to update resources.

Why it fails: A script executes imperative steps that mutate resources, so rerunning it may produce different results and drift is not automatically corrected. It is tempting because scripts can be version-controlled, but declarative GitOps requires the desired state itself to be declared in Git and continuously reconciled.

Requiring manual approval for every reconciliation.

Why it fails: Declarative GitOps means the desired state is stored in Git and controllers reconcile automatically, so gating each reconciliation on manual approval contradicts the principle's continuous convergence. It tempts because approval gates suit regulated change control, where human sign-off before production rollout is genuinely required.

Kubectl allows editing the live state without record.

Why it fails: Kubectl can leave an audit record via API server audit logging, so the claim is false. GitOps is preferred because a Git repository stores every desired-state change as an immutable commit with author and timestamp, giving declarative history that imperative commands do not inherently provide.

Git is faster than kubectl for large clusters.

Why it fails: Git records every desired-state change as an immutable commit with author and timestamp, whereas imperative kubectl commands leave no declarative history unless audit logging is separately enabled. Speed is irrelevant to audit trails. Git's version control suits change tracking; raw execution speed would matter when applying high volumes of manifests across large clusters.

The cluster automatically emails admins when kubectl is used.

Why it fails: Kubernetes provides no built-in mechanism to email admins when kubectl runs, so this describes a capability that does not exist. It is tempting because audit logging can be enabled on the API server, but that records requests to a log backend, not notifications. GitOps instead captures every change as a reviewable commit in version control.

It sets the password for the Git repository.

Why it fails: Repository credentials are supplied through Argo CD repository secrets, not the Sync Policy field, which governs automated sync, pruning and self-healing behaviour. It is tempting because Git authentication must be configured somewhere, but that sits under repository configuration rather than application sync settings.

It configures the frequency of the container health checks.

Why it fails: Container health check frequency is defined in the workload's Kubernetes probe specification, not in Argo CD's Sync Policy, which controls automated sync, pruning and self-healing. It is tempting because Argo CD does reconcile cluster state, but probe timing is a pod-level manifest concern.

It determines which Git branch is used for the deployment.

Why it fails: Branch selection belongs to the Application spec's source.targetRevision, not the Sync Policy, which governs automated sync, pruning and self-healing. It is tempting because Git revisions do drive deployments, but the policy object only decides how and when detected differences are applied.