Select Two (Multi-Select) Questions

Using a Git branch to represent a specific environment (e.g., prod vs dev).

Why it fails: Branch-per-environment promotes drift: each branch diverges, so promotion becomes merges rather than a single source of truth. It is tempting because branches feel like isolation, but it would be correct only for short-lived feature work, not environment representation, which belongs in directories or overlays.

Automating the deployment process using a GitOps operator.

Why it fails: Automating deployments via a GitOps operator is the core purpose of GitOps, not an anti-pattern. It fails this scenario because the question asks for practices to avoid, and reconciliation-driven automation is precisely what GitOps prescribes; it would be correct when describing a healthy GitOps delivery pipeline.

Storing application manifests in a central repository.

Why it fails: A central manifest repository is standard GitOps practice, providing the single source of truth for declarative state. It fails here because the question seeks anti-patterns, and centralised manifests are the intended design; this would be correct when describing a well-structured GitOps repository topology.

Automated reconciliation of state

Why it fails: Automated reconciliation is the core mechanism of GitOps: an agent continuously compares cluster state with the declared state in Git and corrects drift. It is recommended, so it cannot be one of the two NOT recommended items. Manual reconciliation, by contrast, would be the discouraged practise.

Using Git as a source of truth

Why it fails: Git as the single source of truth is the foundational GitOps principle, so it cannot be one of the two NOT recommended practices. It is tempting because teams do debate repository structure and branching, yet the declarative desired state must live in Git for any GitOps controller to reconcile against.

Using pull requests for code changes

Why it fails: Pull requests are central to GitOps: they provide the review and approval gate before merged changes reconcile into the cluster. The stem asks for practices NOT recommended, so this fails. It is tempting because pull requests genuinely suit change control, but here they are the prescribed mechanism rather than an anti-pattern.

Live cluster state is permitted to override repository configurations during peak traffic periods.

Why it fails: Permitting live cluster state to override the repository breaks the single source of truth: reconciliation must always drive the cluster towards the declared state. It is tempting because hotfixing drift during incidents feels pragmatic, but that is precisely what GitOps forbids.

System changes are made by executing manual shell scripts directly on production control plane nodes.

Why it fails: Manual shell scripts on control plane nodes bypass the declared, versioned source of truth entirely, so changes are neither reviewable nor reproducible. It appeals when a fast fix is needed, yet the correct approach commits the change to Git and lets the reconciler apply it.

Built-in web-based graphical dashboard

Why it fails: Flux has no built-in web UI; its CLI and Git-driven reconciliation provide the interface, whereas ArgoCD ships a graphical dashboard. It is tempting because a dashboard is a real ArgoCD feature, but the question asks for Flux advantages, and Flux deliberately omits this component.

RBAC managed via UI

Why it fails: Flux does not provide UI-managed RBAC; authorisation relies on Kubernetes RBAC and Git repository permissions, while ArgoCD offers UI-driven role configuration. It is tempting because centralised RBAC is desirable, but that capability belongs to ArgoCD, not Flux.

Visual sync waves

Why it fails: Flux has no visual sync-wave representation; ordering is expressed through Kubernetes dependencies and health checks, whereas ArgoCD renders sync waves graphically. It is tempting because sync waves exist as a deployment concept, but Flux exposes them declaratively rather than visually.

The Git repository initiates an inbound SSH connection to cluster worker nodes to push manifest updates.

Why it fails: Pull-based reconciliation has the in-cluster Flux agent fetch and apply manifests from Git; Git never opens inbound SSH to worker nodes to push updates. Push-based CI pipelines, where an external system connects into the cluster to deploy, are the scenario this describes.

Cluster administrative credentials must be stored inside external CI system secret stores.

Why it fails: Pull-based reconciliation has the cluster's own agent fetch desired state from Git, so no external CI credentials are needed; storing cluster admin credentials in CI secret stores describes push-based deployment, where a pipeline holds cluster access and applies manifests directly.

Reconciliation requires direct human approval at the terminal for every individual resource sync.

Why it fails: Automated pull-based reconciliation continuously compares desired state in Git with live cluster state and applies changes without human intervention, so requiring terminal approval per resource contradicts the principle outright. It is tempting because manual approval gates do exist in GitOps workflows, but those belong to change authorisation before merge, not to per-resource sync execution.

Docker Desktop.

Why it fails: Docker Desktop is a local container runtime and GUI, not part of the GitOps toolchain. It is tempting because GitOps deploys containerised workloads, so container tooling appears adjacent, but the ecosystem centres on Git repositories, declarative manifests and reconciliation controllers such as Argo CD or Flux.

Nginx.

Why it fails: Nginx is a web server and reverse proxy that serves or routes traffic; it does not watch a Git repository and reconcile cluster state towards it, which is the GitOps mechanism. It is tempting because Nginx ingress controllers are commonly deployed in Kubernetes environments where GitOps tools also run, so it would be correct for a question about ingress or load balancing.

Prometheus.

Why it fails: Prometheus provides metrics collection and alerting for Kubernetes workloads, not the declarative desired-state reconciliation and Git-sourced deployment that define GitOps. It is tempting because it is a standard cloud-native tool often deployed alongside GitOps stacks, and would be correct if the question asked about monitoring rather than the GitOps toolchain itself.

Provision new clusters

Why it fails: Kyverno policies validate, mutate, generate and verify Kubernetes resources; provisioning clusters is the job of cluster lifecycle tooling such as eksctl or Terraform. Kyverno is tempting because it is cluster-scoped and declarative, but it operates on API resources, not infrastructure provisioning.

Manage Git repository webhooks

Why it fails: Git webhooks are configured in the Git provider or CI system, not by Kyverno, which validates, mutates, generates and verifies Kubernetes resources at admission time. Kyverno is tempting because it is policy-as-code stored in Git, but it never manages repository-side integrations.

Automatically upgrade cluster nodes

Why it fails: Node upgrades are handled by managed node group versioning or Karpenter, not admission policies; Kyverno mutates, validates, generates and verifies Kubernetes resources. Kyverno is tempting because it enforces cluster-wide desired state, but it cannot orchestrate node lifecycle operations.

Apache HTTP Server.

Why it fails: Apache HTTP Server is a web server that serves static and dynamic content; it cannot watch Git repositories or reconcile Kubernetes manifests. It is tempting because GitOps tools frequently expose their dashboards through a web server, but the CNCF GitOps category covers Argo CD, Flux and Jenkins X instead.

MySQL.

Why it fails: MySQL is a relational database, not a GitOps continuous-delivery tool; it neither watches Git repositories nor reconciles cluster state. It is tempting because GitOps pipelines often persist application data in MySQL, but the question asks for the CNCF tooling layer itself, such as Argo CD or Flux.

They are only for local clusters

Why it fails: ApplicationSets target any cluster registered with ArgoCD, including remote and multi-cluster fleets, which is their primary purpose. The misconception stems from single-cluster demos where a local target is used, yet the cluster generator exists precisely to fan out across many registered clusters.

They handle container image builds

Why it fails: ApplicationSets generate ArgoCD Application resources from generators such as Git directories, clusters or pull requests; they never build images. The confusion arises because CI pipelines feeding Git often sit alongside ArgoCD, but image building belongs to tools like Jenkins, GitLab CI or Tekton.

They replace the need for Git

Why it fails: ApplicationSets read desired state from Git repositories and generate Application manifests; removing Git eliminates the source of truth they reconcile against. The temptation comes from their templating power, which feels like it replaces configuration, but Git remains the declarative store ArgoCD syncs from.

Copying the entire deployment configuration for every single environment.

Why it fails: Duplicating whole deployment configurations per environment creates divergent copies that drift, defeating the single-source-of-truth model GitOps depends on. It is tempting because isolated per-environment manifests feel safe, and that approach is correct when environments genuinely differ in topology and must be versioned as separate, deliberate overlays.

Storing all configurations in a single root-level file.

Why it fails: One root-level file serialises every change through a single artefact, so unrelated environments become coupled and merge conflicts block promotion. It is tempting because a single file appears tidy and atomic, and that pattern is correct for a small, single-environment repository where no per-team ownership boundaries exist.

Temporary State

Why it fails: GitOps contrasts desired state with observed (actual) state; "temporary state" is not part of that vocabulary. It is tempting because it suggests a transient condition, but it would be correct only if the term denoted desired state, the version-controlled configuration an operator declares and the agent continuously reconciles.

Future State

Why it fails: GitOps describes desired state and observed (actual) state; "future state" is not a recognised term. It is tempting because it sounds like the target configuration, but it would be correct only if the terminology mapped to desired state, which is the actual term used for the intended application configuration.

Legacy State

Why it fails: GitOps terminology centres on desired state and observed state; "legacy state" appears nowhere in the model. It is tempting because it evokes a previous configuration version, but it would be correct only if the term referred to desired state, the declared configuration stored in Git that the cluster reconciles toward.

Running 'helm upgrade' manually.

Why it fails: Manual helm upgrade runs are imperative and leave no reconciled desired state, so drift is never corrected automatically. It tempts because Helm itself is central to GitOps tooling, and manual upgrades would be acceptable for one-off releases outside a GitOps pipeline.

Only storing the chart source code.

Why it fails: Storing only chart source omits the rendered manifests that Argo CD or Flux actually reconciles against the cluster, so drift between values and deployed state goes undetected. It is tempting because versioning chart templates is genuine GitOps practise; that approach suits developing a reusable chart, not deploying environment-specific releases.

Logging into the node via SSH

Why it fails: SSH access to a node changes nothing the GitOps controller observes, since reconciliation compares Git commits with live cluster state, not node sessions. It is tempting because SSH is a familiar operational entry point, and it would be correct for manually inspecting or repairing a node's runtime.

Restarting the Kubernetes API server

Why it fails: Restarting the Kubernetes API server disrupts the control plane but does not reconcile cluster state against Git; the GitOps controller watches Git and cluster events, not API server restarts. It is tempting because restarts do reinitialise components, and restarting a controller pod would legitimately trigger reconciliation.

Higher speed because testing is bypassed.

Why it fails: GitOps does not bypass testing; pipelines still run tests before merging, and skipping them raises risk rather than speed. It is tempting because automated sync accelerates delivery, but that speed comes from continuous reconciliation, not from removing quality gates.

Increased dependence on manual operator intervention.

Why it fails: GitOps reduces manual operator intervention through automated reconciliation, so increased dependence contradicts its purpose. It is tempting because operators still review pull requests, but that governance is deliberate change control, not the runtime toil GitOps eliminates.

The ability to run without any container registry.

Why it fails: GitOps still deploys container images pulled from a registry, so removing the registry is not a benefit. It is tempting because GitOps stores desired state declaratively in Git, which can feel registry-independent, yet the registry remains the artefact source for Kubernetes workloads.

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.

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.

It is a purely external monitoring tool

Why it fails: A GitOps Operator runs inside the cluster as a controller, watching Git and applying changes; it is not an external monitoring product. It tempts because operators report sync status and drift, which resembles monitoring, but their mechanism is active reconciliation, not passive observation.

It generates application source code

Why it fails: A GitOps Operator reconciles cluster state to match declarations held in Git; it does not author application source code, which developers commit. It tempts because operators act on repositories, but their function is continuous reconciliation of deployed resources, not code generation.

It requires manual triggers for every update

Why it fails: GitOps Operators reconcile continuously and automatically, detecting drift and applying declared state without human initiation. Manual triggering contradicts that control loop. It tempts because approval gates exist in some pipelines, but the operator's defining behaviour is autonomous reconciliation from Git.

A temporary spike in CPU usage.

Why it fails: A CPU spike is transient runtime behaviour, not a divergence between the Git-declared desired state and the actual cluster state. It is tempting because monitoring alerts flag it, but drift concerns configuration mismatch; a manually deleted deployment that Git still declares is drift.

A container crashing due to a code bug.

Why it fails: A container crash is a runtime failure caused by application code, not a divergence between the Git-declared state and the live cluster state. It is tempting because crashes are operational incidents needing attention, but drift specifically means the cluster no longer matches Git; reconciliation corrects drift, not code bugs.

A new Git commit.

Why it fails: A new Git commit is the desired-state change itself, not a divergence from it; GitOps agents reconcile the cluster towards that commit. It is tempting because commits drive GitOps, but drift is the cluster deviating from Git, not Git being updated; a manual kubectl edit is drift.

Manually logging into pods to check health.

Why it fails: Progressive delivery automates health evaluation through metrics, probes and analysis gates; manual pod logins cannot scale or gate a rollout and are not a GitOps feature. Manual inspection belongs to ad-hoc troubleshooting, not controlled canary or blue-green progression.

Immediate deployment of all changes to the entire cluster.

Why it fails: Progressive delivery exposes changes to a subset of users or traffic first, then widens gradually based on observed health. Pushing every change to the whole cluster at once is the opposite mechanism, leaving no staged verification or rollback window.

Removing all health checks from the application.

Why it fails: Progressive delivery depends on health checks and automated analysis to decide whether to advance or roll back a release. Stripping them removes the feedback signal entirely, so this contradicts the practice rather than describing it.

Deleting the application and recreating it.

Why it fails: Deleting and recreating the application causes downtime and discards cluster state, and the recreated manifests still come from Git rather than a promotion step. It is tempting as a clean-slate reset, but GitOps promotion updates the production environment's declared state through a pull request.

Running a 'kubectl rollout undo' command manually.

Why it fails: A manual kubectl rollout undo mutates the cluster directly, bypassing Git as the source of truth, so the change is reverted by reconciliation. It is tempting as an emergency rollback, but GitOps promotion commits the desired state to the production branch and lets the controller apply it.

Bypassing the CI/CD pipeline by pushing directly to the cluster.

Why it fails: Pushing directly to the cluster bypasses CI/CD and Git, so the cluster diverges from the declared state and the controller reverts it. It is tempting for speed during incidents, but GitOps promotion requires the change to be committed to the production branch and reconciled from there.