Using Kustomize Overlays for Per-Environment Config
Walk me through how you would use Kustomize overlays to handle config that differs between dev and prod in an Argo CD setup.
Walk me through how you would use Kustomize overlays to handle config that differs between dev and prod in an Argo CD setup.
Put what is shared in a base. Put what differs in overlays, one per environment. Argo CD detects the kustomization.yaml in the overlay path and runs kustomize build to render the manifests. Base holds: Deployment, Service, baseline ConfigMap, common labels. Overlays patch: replicas, resource requests and limits, image tags, ingress hosts, environment-specific ConfigMap values, env vars, and HPA settings. Key rules I follow: 1. Anything that differs between environments lives in overlays, never the base. 2. Image tags belong in overlays so CI can bump dev without touching prod. 3. Patch with strategic merge or JSON patches. Do not copy the whole Deployment YAML into each overlay; that is exactly the duplication Kustomize is supposed to remove. 4. Use configMapGenerator with behavior: merge to add or override values, not replace the whole map. 5. Secrets do not go in Kustomize. Use external-secrets, sealed-secrets, or a secrets manager. On the Argo CD side, the Application points at the overlay path (apps/web/overlays/prod) and Argo CD figures out it is Kustomize from the kustomization.yaml file. No extra config needed. Edge case: if the same overlay applies to two clusters with one tiny difference (a region label, a DNS suffix), do not create a fourth overlay. Use ApplicationSet parameters to pass that one value in. Otherwise overlays multiply fast.
This question tests whether the candidate has actually shipped Kustomize, not just read about it. Watch for people who treat overlays like full copies of the base. The point of Kustomize is the patch, not the duplication. Strong candidates know the difference between configMapGenerator behaviors (create vs merge vs replace), know where image tags should live, and have a clear take on secrets being out of scope.
Base kustomization.yaml
Prod overlay patching replicas, resources, image, and config
Replicas patch (strategic merge)
- Copying the whole Deployment YAML into each overlay instead of writing a small patch
- Putting secrets into a ConfigMap because Kustomize does not support encrypted resources out of the box
- Hardcoding prod image tags inside the base, so a dev image bump cannot happen without touching prod
- How does Argo CD know to render this with Kustomize? Do you have to tell it?
- Same overlay needs to apply to two clusters but with a different region label in each. How do you handle that without forking the overlay?
- When would you reach for Helm instead of Kustomize? Or both together?
- How do you preview the rendered output of the prod overlay before merging a change?
More GitOps interview questions
Also worth your time on this topic
GitOps with Argo CD: Structuring Your Repository for Multi-Environment Deployments
A practical guide to laying out your Git repository for Argo CD across dev, staging, and production. See real folder structures, Kustomize and Helm patterns, and the pitfalls that bite teams in production.
Argo CD Multi-Environment Repository Structure Checklist
How to organize your Git repositories when running Argo CD across dev, staging, and production. Covers folder layout, app-of-apps, ApplicationSets, secrets, RBAC, and promotion flow.
60-90 minutes
Structuring a Git Repo for Argo CD Multi-Environment Deployments
How would you structure a Git repo for Argo CD when you have dev, staging, and prod environments?
junior