Helm vs Kustomize for Per-Environment Config
Helm or Kustomize for handling environment differences in an Argo CD repo? Walk me through how you would pick and what the repo layout looks like for each.
Helm or Kustomize for handling environment differences in an Argo CD repo? Walk me through how you would pick and what the repo layout looks like for each.
Default to Kustomize for your own apps. Use Helm for third-party software you do not own. Use both together when you have a Helm chart from a vendor but need environment-specific tweaks the chart does not expose as values. Reasoning. Kustomize patches a flat YAML base. What you see is what gets applied. No templating engine, no Go template debugging, no quoting traps. The downside is no logic, no loops, no conditionals. That is fine for your own apps because you control the base. Helm shines when you do not own the base. cert-manager, ingress-nginx, kube-prometheus-stack: each ships a chart with hundreds of toggles. Reimplementing that in Kustomize is a waste of time. Pin the chart version, write a values file per environment, done. Repo layout with Kustomize (your own apps): apps/ web/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ dev/ kustomization.yaml prod/ kustomization.yaml Repo layout with Helm (third-party): platform/ ingress-nginx/ values-base.yaml values-dev.yaml values-prod.yaml cert-manager/ values-base.yaml values-prod.yaml Argo CD Application points at the chart in its repo (or an OCI registry) and references the right values files from your manifests repo using the multi-source feature. The combined pattern, Helm chart rendered by Kustomize, looks like this: platform/ingress-nginx/ base/ kustomization.yaml # uses helmCharts to pull and render the chart values.yaml # base values overlays/ prod/ kustomization.yaml # patches the rendered output values.yaml # prod-specific values Kustomize renders the chart with its values, then your overlay patches the rendered output. This is what you reach for when the chart does not let you change something through values and forking the chart is worse than patching the output. One thing not to do. Do not build your own apps as a Helm chart just so you can use values files per environment. That is the most common 'we picked Helm and regretted it' story. You will spend weeks debugging Go template indentation. Use Kustomize.
This is a question where opinions matter, and a strong candidate will have one. The instinct to say 'it depends' is fine if it is followed by specific criteria. Listen for the ownership criterion: who controls the base manifests determines whether templating logic earns its keep. Bonus points for awareness of the multi-source Application feature in Argo CD, and for mentioning the combined helmCharts inside Kustomize pattern, which is widely used in production but rarely taught.
Argo CD Application with multi-source: chart from one repo, values from manifests repo
Kustomize rendering a Helm chart so you can patch the output
Prod overlay patching the rendered chart output
- Building your own application as a Helm chart so you can have values files, then drowning in Go template debugging for what was supposed to be a simple replica count change
- Pinning a chart to a major version like 4.x and letting Argo CD pull whatever 4.y.z is latest at sync time, so what gets deployed depends on when the sync runs
- Copying entire third-party Kubernetes manifests into your repo because Helm 'feels too complex', then never updating them and falling years behind
- Argo CD needs --enable-helm to render Helm inside Kustomize. Where do you set that, and what is the security trade-off?
- A vendor chart does not expose the setting you need as a value. Helm post-renderer or Kustomize patch on top? Why?
- How do you pin a chart version so a new release does not change behavior under you?
- Same setup but the chart lives in an OCI registry instead of a Helm repo. What changes in the Application spec?
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
Bootstrapping Argo CD and Letting It Manage Itself
Argo CD manages your apps. Who manages Argo CD? Walk me through how you would bootstrap it from a fresh cluster and where its own config lives in your repo.
junior