Tooling practice questions

Kyverno

Why it fails: Kyverno is a Kubernetes admission controller that validates and mutates cluster resources at deploy time; it does not sign or encrypt manifest files in Git. It is tempting because Kyverno enforces policy on manifests, but that is runtime admission control, not at-rest cryptographic protection of repository content.

Sealed Secrets

Why it fails: Sealed Secrets encrypts secrets for safe storage in Git, but it does not sign manifests, so it fails the signing requirement. It is tempting because it addresses at-rest protection of sensitive values, and would be correct if only secret encryption were required.

HashiCorp Vault

Why it fails: HashiCorp Vault manages secrets, dynamic credentials and encryption keys, but it does not sign and encrypt Kubernetes manifest files before a Git push. It is tempting because Vault performs encryption as a service, yet that protects secrets at rest in Vault, not manifest artefacts in a repository.

syncPolicy.automated.prune

Why it fails: This controls whether resources are removed when deleted from Git.

resource.exclusions

Why it fails: This is not a standard field for per-application sync tuning.

selfHeal

Why it fails: This forces ArgoCD to sync back to the Git state if modified manually.

Project settings

Why it fails: Project settings define RBAC and source restrictions, not sync connectivity.

ApplicationSet controller logs

Why it fails: ApplicationSet manages groups of apps, not the sync state of an individual app.

Git repository webhooks

Why it fails: Webhooks trigger refreshes but do not track controller-level sync logic errors.

Secret injection controller

Why it fails: Not a native ArgoCD feature.

Resource hooks

Why it fails: Hooks run during sync, they don't modify the manifest parameters.

Git commit override

Why it fails: Committing changes defeats the purpose of dynamic injection.

Enforcing policies

Why it fails: That is a role for Kyverno or OPA.

Applying Kubernetes manifests

Why it fails: That is the Kustomization Controller's job.

Encrypting secrets

Why it fails: That is a security task.

A human user who manages Git

Why it fails: A GitOps Operator is a Kubernetes controller that continuously reconciles cluster state against a Git repository; a human managing Git performs no automated reconciliation. Tempting because people do administer repositories, but that is a Git administrator role, not the controller pattern the term denotes.

A CI/CD pipeline server

Why it fails: A CI/CD pipeline server builds and pushes artefacts on triggers; a GitOps Operator instead runs inside the cluster, continuously pulling Git state and reconciling drift. Tempting because pipelines also touch Git and deploy, but push-based execution differs from the operator's pull-based reconciliation loop.

A Git server provider

Why it fails: A Git server provider hosts repositories; a GitOps Operator is the in-cluster controller that watches Git and applies desired state to Kubernetes. Tempting because GitOps depends on a Git host, yet hosting stores manifests without reconciling anything, so it cannot perform the operator's continuous convergence.

kubectl get application <app-name> -n argocd -o yaml

Why it fails: This command retrieves the Argo CD Application resource, which contains sync status and health information, but it does not show the live state of the individual Kubernetes resources managed by the application. To debug a specific resource stuck in Progressing, you need to inspect that resource directly, not the Application wrapper.

argocd app diff <app-name>

Why it fails: The argocd app diff command compares the desired state in Git with the live state in the cluster, which is useful for detecting drift. However, it does not provide detailed diagnostic information about why a resource is unhealthy, such as events or status conditions. For that, you need to inspect the resource directly.

kubectl logs -n argocd deployment/argocd-application-controller

Why it fails: Checking the Argo CD application controller logs can reveal reconciliation errors, but it is not the most direct way to inspect a specific problematic resource. The logs may show that the controller is waiting for a resource to become healthy, but they will not show the underlying reason, such as a failing readiness probe.

ArgoCD Notifications

Why it fails: ArgoCD Notifications sends alerts about sync and health events; it takes no admission decision and cannot block a pod image. It is tempting because it is a GitOps observability component, but it would be correct for notifying teams of deployment changes, not enforcing registry allowlists at admission.

Sealed Secrets

Why it fails: Sealed Secrets encrypts Kubernetes Secrets for safe Git storage; it performs no admission-time validation of image registries. It is tempting because it is a Flux-friendly security tool, but it would be correct for committing credentials to Git, not for restricting namespaces to an internal registry.

Flux Image Automation Controller

Why it fails: Image Automation Controller updates image tags in Git; it does not evaluate admission requests. Namespace-scoped registry restriction at admission time needs a validating admission policy, such as a Kyverno ClusterPolicy or Gatekeeper constraint. Flux's automation is tempting because it already watches registries, but it writes manifests rather than blocking pods.

GitOps CLI (kubeseal)

Why it fails: kubeseal encrypts plaintext into a SealedSecret using the controller's public key, and only runs client-side. Decryption happens in-cluster via the sealed-secrets controller's private key. kubeseal is the right tool when creating sealed manifests before committing them to Git.

Kubernetes API Server

Why it fails: The Kubernetes API server stores and serves objects but holds no Sealed Secrets private key, so it cannot decrypt SealedSecret data. The sealed-secrets controller performs decryption. The API server is correct for persisting the resulting Secret once decrypted.

ArgoCD Application controller

Why it fails: ArgoCD's Application controller only syncs and reconciles manifests; it holds no Sealed Secrets private key, so it cannot decrypt SealedSecret resources. The sealed-secrets controller performs decryption. ArgoCD is correct for syncing the encrypted manifest into the cluster.

Git pre-receive hook

Why it fails: A Git pre-receive hook runs on the Git server before objects are accepted, so it inspects commits, not rendered Kubernetes manifests, and cannot evaluate Gatekeeper's label constraint. It is tempting because pre-receive hooks do block pushes, which is correct when the requirement is rejecting malformed commits rather than admission-time policy.

Flux Source Controller

Why it fails: The Flux Source Controller fetches and reconciles source artefacts such as Git repositories and Helm charts; it does not admit workloads or inspect labels on rendered manifests. It is tempting because source controllers do gate what enters the cluster, which is correct when the requirement is controlling which sources are trusted rather than validating workload fields.

ArgoCD AppProject

Why it fails: An ArgoCD AppProject scopes which repositories, clusters and namespaces an application may target; it does not evaluate manifest contents against a label constraint. It is tempting because AppProjects do restrict deployments, which is correct when the requirement is limiting an application's permitted destinations rather than enforcing field-level policy.

Post-sync hooks

Why it fails: Post-sync hooks run only after all resources report healthy, so they cannot sequence resources within a single reconciliation pass the way Sync Waves do. They are tempting because ArgoCD itself uses hooks for ordering, but Flux's equivalent ordering mechanism is dependsOn, not hooks.

Sync waves

Why it fails: Flux has no 'sync waves' feature; that term belongs to ArgoCD's annotation-driven ordering. It is tempting because the question asks for an equivalent, but the correct Flux mechanism is dependsOn, which expresses explicit dependencies between Kustomization or HelmRelease resources rather than numeric wave annotations.

Reconciliation intervals

Why it fails: Reconciliation intervals control how often Flux re-checks a resource against its desired state, not the order in which resources are applied. They are tempting because they govern timing, but ordering across resources requires dependsOn references, which gate reconciliation on another resource's readiness.

ArgoCD

Why it fails: ArgoCD uses Application and AppProject custom resources with its own application controller; it does not use Source Controller or Kustomization CRDs. Those resources belong to Flux, which is the correct pull-based GitOps tool for this description.

Terraform

Why it fails: Terraform is an imperative CLI provisioning tool that applies plans from state files; it has no Source Controller or Kustomization CRDs. It is tempting because Terraform can be driven from Git pipelines, but Flux is the tool whose Source Controller and Kustomization resources implement the pull-based reconciliation described.

Helm

Why it fails: Helm renders and deploys Kubernetes manifests from packaged charts; it has no Source Controller or Kustomization custom resources and does not reconcile cluster state against a Git repository. It is tempting because Helm also manages Kubernetes deployments declaratively, but it is a package manager, not a pull-based GitOps reconciler.

Faster build times

Why it fails: Build time is determined by the CI system compiling and testing code, which is unchanged whether deployment is pull- or push-based. It is tempting because pull models remove cluster credentials from CI, and would be correct if the question asked about reduced credential exposure or drift correction.

Automatic unit testing

Why it fails: Unit testing is executed by the CI system before code is committed, so it is orthogonal to whether deployment uses a pull or push mechanism; Flux and ArgoCD do not run tests. It tempts because CI pipelines commonly include test stages, but the question concerns deployment reconciliation, not test execution.

No need for Git

Why it fails: GitOps requires Git.

Post-build variables

Why it fails: Post-build variables substitute values into already-rendered output during Flux reconciliation; they cannot restructure or patch resources per environment. They are tempting because they vary configuration by environment, and would be correct for injecting cluster-specific values into a rendered manifest, not for overlaying a shared base.

Flux Kustomization resource

Why it fails: Flux Kustomization is the delivery mechanism that points at a Kustomize overlay directory; it does not itself provide the overlay/base layering. It is tempting because it is the Flux object that applies Kustomize output, and it would be correct when wiring an overlay into a cluster, not when naming the Kustomize feature.

Helm charts

Why it fails: Helm charts are a separate templating system using values files, not Kustomize's base-and-overlay mechanism, so they cannot layer patches onto the shared base manifests. They are tempting because they also separate environment configuration, and would be correct if the manifests were packaged as charts rather than Kustomize bases.

SOPS version mismatch

Why it fails: Flux decrypts using the sops-age key held in its decryption secret, so a SOPS binary version difference does not prevent decryption; the encrypted data key and Age recipient remain unchanged. Version alignment matters when the local sops CLI must re-encrypt files with a newer format, not when Flux reads them.

Network latency

Why it fails: SOPS decryption happens locally inside the Flux controller using the Age private key; it makes no network call to a key service, so latency cannot cause failure. Network conditions matter for KMS or Vault-backed keys, where the controller must reach a remote endpoint to unwrap the data key.

Incorrect git branch

Why it fails: Flux reconciles whatever branch the GitRepository source references; pointing at a different branch simply changes which manifests are read, and any encrypted file on that branch still decrypts. Branch selection is the correct concern when promoting environment-specific overlays, not when decryption itself fails.

ClusterRoleBinding

Why it fails: A ClusterRoleBinding grants a subject permissions cluster-wide; it does not scope ArgoCD deployments to namespaces. It is tempting because it is a Kubernetes access-control object, but ArgoCD enforces destination limits through AppProject destinationNamespace fields, not through RBAC bindings.

Sync policies

Why it fails: Sync policies govern automated sync, pruning and self-heal behaviour, not which namespaces an Application may target. They are tempting because they shape deployment behaviour, but restricting destinations is an AppProject concern; sync policy settings never evaluate or block the destination namespace.

ApplicationSet

Why it fails: ApplicationSet generates Applications from generators and templates; it cannot constrain destination namespaces. It is tempting because it manages many Applications at scale, which sounds like blast-radius control, but namespace restriction comes from AppProject destinationNamespace settings, not from how Applications are generated.

The change is permanently accepted

Why it fails: SelfHeal actively reverts the replica count to the Git-declared value, so the manual edit is overwritten rather than retained. Permanence would only hold with SelfHeal disabled, where ArgoCD merely reports OutOfSync and leaves the live change untouched until the next sync or manual intervention.

ArgoCD flags the app as 'OutOfSync' but waits for manual intervention

Why it fails: SelfHeal exists precisely to remove manual intervention: ArgoCD detects drift and automatically syncs the Deployment back to the Git-declared replica count. Flagging OutOfSync and waiting describes the default behaviour when SelfHeal is disabled, which is why that setting is enabled in this scenario.

The manual change is merged into Git

Why it fails: Git is ArgoCD's source of truth; SelfHeal reverts live drift to match Git, never writes cluster state back into the repository. The tempting idea is bidirectional sync, but ArgoCD is one-way only — Git commits require a human or CI pipeline, which is why GitOps workflows mandate pull requests rather than automatic reconciliation.

kubectl get policies

Why it fails: kubectl get policies lists policy resources in the cluster; it never evaluates a named resource against those policies. It is tempting because listing is the natural first step when you want to see which policies exist, and it would be correct for inventorying installed policies rather than checking compliance.

kyverno test

Why it fails: kyverno test runs policies against local manifest files and test cases on your workstation, not against live cluster resources. It is tempting because it validates policy logic before deployment, and it would be correct when checking whether a policy behaves as intended during development.

kubectl describe policy

Why it fails: kubectl describe policy targets a policy object, not a workload, and reports no compliance evaluation for a specific resource. It is tempting because describe is the usual first step when inspecting any Kubernetes object, and it would be correct for reading a policy's own spec or status.

Backing up Kubernetes secrets

Why it fails: SealedSecrets encrypts a secret so it can be committed safely to Git, then decrypts it inside the cluster via a controller. It does not back secrets up; backup requires exporting etcd or using a tool such as Velero. It would be the right choice when storing manifests in a public repository.

Managing cluster-wide RBAC

Why it fails: SealedSecrets encrypts Kubernetes Secret manifests so they can be safely committed to Git, then decrypts them in-cluster via a controller. It performs no authorisation or access control, so it cannot manage RBAC roles or bindings. RBAC management belongs to Kubernetes Role, ClusterRole, RoleBinding and ClusterRoleBinding objects, not to a secrets-encryption operator.

Encrypting traffic between pods

Why it fails: SealedSecrets encrypts secret manifests so they can be stored safely in Git, decrypting only inside the cluster via a controller. Pod-to-pod traffic encryption is handled by service mesh mTLS or network policy tooling, not by this custom resource.

ApplicationSet status

Why it fails: ApplicationSet status reports generator and template reconciliation for producing Applications, not the sync operation of an existing Application. It is tempting because ApplicationSet conditions do surface errors, and it would be correct when an Application is never created due to a faulty generator or template.

Git log

Why it fails: Git log records commits in the application's source repository, not ArgoCD's reconciliation outcome, so it holds no sync error detail. It is tempting because Git history is the natural place to trace manifest changes, and it would be the right choice when diagnosing which commit altered a resource's desired state.

ArgoCD repo server logs

Why it fails: The repo server only generates manifests from the repository; it does not execute the apply against the cluster, so it never records the sync failure itself. It is tempting because repo server logs are genuinely the correct place when manifest generation or Helm rendering fails before any sync attempt.