GitOps interviews have a tell. The interviewer stops asking about CI/CD in general and starts asking why the cluster pulls instead of getting pushed to. That shift is the whole point of GitOps, and it is where a lot of otherwise strong candidates go quiet.
If you have run Argo CD or Flux in production, you already know the mechanics. This is about translating that experience into answers that hold up under follow-up questions. Here are ten themes that come up again and again, with the gotchas built in.
1. Explain the pull model. Why does it matter?
In a push model, your CI pipeline has credentials to your cluster and applies changes directly. In GitOps, an in-cluster controller (Argo CD or Flux) continuously polls a Git repository and reconciles cluster state to match it. Nothing outside the cluster needs write access to the cluster.
The gotcha: interviewers want you to name the security benefit specifically. No pipeline holds a kubeconfig with cluster-admin. The blast radius of a compromised CI token shrinks to whatever that token can do in Git, not in Kubernetes.
2. What is a sync wave in Argo CD and when do you use one?
Sync waves control ordering inside a single Argo CD sync operation. You set the argocd.argoproj.io/sync-wave annotation on a resource, and Argo CD applies lower-numbered waves first, waiting for each wave to reach a healthy state before moving to the next.
Common real answer: CRDs and namespaces in wave -1, secrets and configmaps in wave 0, deployments in wave 1, and post-sync jobs or smoke tests in wave 2 or higher. If you cannot give a concrete example from your own manifests, the interviewer will notice.
3. How does Argo CD decide if an application is healthy?
Argo CD has built-in health checks for standard resource types: Deployments look at replica counts, Services check endpoints, Ingresses check load balancer status. For custom resources, there is no default logic, so Argo CD reports them as Progressing or Unknown unless you write a custom health check in Lua under resource.customizations in the argocd-cm ConfigMap.
This is a favorite gotcha question: what happens when you deploy a custom CRD, like a Postgres operator resource, and Argo CD shows it stuck at Progressing forever? The answer is you write a Lua health check that inspects the CRD's status fields and returns Healthy, Degraded, or Progressing explicitly.
4. What is App-of-Apps and why not just list every application manually?
App-of-Apps is a pattern where a single parent Argo CD Application manages a set of child Application manifests, which in turn point to the actual workload manifests. It gives you one Git commit to onboard a new service, a bootstrap point for a new cluster, and a blast-radius boundary if one child app's sync fails.
Flux has an equivalent concept using Kustomization resources that reference other Kustomizations, sometimes called the App-of-Apps pattern applied to the Flux Kustomize controller.
5. Explain Flux's controller architecture
Flux v2 is split into separate controllers, each doing one job:
- Source controller — watches Git repositories, Helm repositories, and OCI registries, producing artifacts other controllers consume
- Kustomize controller — applies Kustomize overlays from those source artifacts
- Helm controller — reconciles HelmRelease resources
- Notification controller — sends alerts to Slack, Teams, or webhooks on reconciliation events
Interviewers ask this to see if you understand Flux is composable, unlike Argo CD's more monolithic application model. If you can explain why you would swap the Helm controller for GitOps-managed raw manifests, you are answering at the right depth.
6. How does drift detection actually work?
Both tools run a reconciliation loop that compares live cluster state against the desired state in Git on an interval (Flux defaults to every 10 minutes per GitRepository, Argo CD polls every 3 minutes by default, both are configurable). When it finds drift, it either reports it or, if self-heal is enabled, automatically re-applies the Git version.
The gotcha: someone kubectl-edits a Deployment directly to hotfix a production issue. Ask the candidate what happens next. With Argo CD's selfHeal: true, that manual edit gets reverted on the next reconciliation. Good GitOps hygiene means that hotfix has to go through Git, not kubectl, or you will fight your own controller.
7. How do you handle secrets in a GitOps repo?
You never commit plaintext secrets to Git, full stop. The three common answers, and interviewers expect you to know the tradeoffs of each:
| Approach | How it works | Tradeoff |
|---|---|---|
| Sealed Secrets | Encrypt with a cluster-specific public key; only the in-cluster controller can decrypt | Simple, but re-encryption needed per cluster |
| SOPS | Encrypt individual fields using KMS, PGP, or age; decrypted at apply time | Works well with Flux's native SOPS support |
| External Secrets Operator | Pulls secrets at runtime from AWS Secrets Manager, Vault, or similar; Git only stores a reference | Adds an external dependency and API calls |
8. Argo CD vs Flux: what would make you pick one over the other?
- Argo CD ships a UI out of the box, which matters for teams with less Kubernetes fluency reviewing sync status visually
- Flux is more Unix-philosophy — smaller, composable controllers that integrate cleanly with existing CI tooling and Kustomize/Helm workflows
- Argo CD has stronger native support for multi-cluster fan-out from one control plane
- Flux tends to have a lighter resource footprint, which matters on smaller clusters
There is no universally correct answer here. What interviewers want is that you have an opinion backed by a real tradeoff, not a memorized feature list.
9. What happens during a sync failure mid-rollout?
Argo CD marks the sync as failed and, depending on your retry policy, either stops or retries with exponential backoff. If a resource in a later sync wave fails, earlier waves are not automatically rolled back — you are left with a partially applied state until you fix the underlying manifest and re-sync. Know this cold; it is the most common "what would you actually do at 2am" follow-up.
10. How do you promote a change from staging to production in GitOps?
The Git-native answer is a promotion via pull request: bump the image tag or Helm chart version in the production overlay, get it reviewed, merge, and let the controller reconcile. Some teams automate this with image update automation (Flux's image automation controller, or Argo CD Image Updater), but be ready to explain why you would or would not want that automation gated behind human review for a production namespace.
Quick prep checklist
- Can you name the exact annotation for Argo CD sync waves
- Can you write a one-line Lua health check example
- Can you name all four core Flux controllers
- Can you explain selfHeal and prune in one sentence each
- Can you compare two secret-management approaches with a real tradeoff
If you want to talk through how GitOps experience translates into your next contract, the team at Josh Pros LLC can help you frame it for the roles hiring right now. Reach out at contact@joshpros.com or visit https://joshpros.com.
#GitOps #ArgoCD #FluxCD #Kubernetes #DevOps #PlatformEngineering #SRE #CloudNative #TechInterviews #ITContracting #ContinuousDelivery #KubernetesJobs
Talk to a real recruiter, not a bot.
We'll tell you the rate, the client, and the terms before you interview. And if we're not the right fit, we'll say so.