Application Code vs Kubernetes Manifests in Separate Repos
Should your application source code and Kubernetes manifests live in the same repo or in separate repos? What is your take?
Should your application source code and Kubernetes manifests live in the same repo or in separate repos? What is your take?
Default to separate repos. The application code repo holds Go, Python, Node, whatever. A second manifests repo holds the Argo CD Applications, Kustomize overlays, and any cluster config. This is the pattern most production GitOps setups end up using, and there are four good reasons for it. First, blast radius and permissions. Devs commit code freely. Manifests changes for prod usually want code owners, branch protection, and a smaller set of reviewers. Splitting the repos lets you set those rules cleanly. Second, noise. Argo CD watches the manifests repo. If manifests share a repo with app code, every README edit shows up as a change Argo CD has to decide what to do with. Third, image promotion loops. CI builds an image from the code repo and writes the new tag into the manifests repo. If both live in one repo, the bump commit triggers another CI run, which can build, push, and bump again. You end up adding skip-ci tags everywhere to stop the loop. Fourth, manifests are usually shared. A monitoring stack, ingress controller, and three apps all live in one manifests repo. They do not belong with any single app's code. When the monorepo is fine: one team, one app, no compliance separation. Do not over-engineer that case.
This question reveals whether a candidate has shipped GitOps in production or only read the docs. Strong answers cite specific operational problems (CI loops, noisy reconciliation, permission boundaries) rather than vague principles like separation of concerns. Watch out for candidates who insist on one model as universal truth. The right answer is conditional, and the conditions matter.
CI step that bumps the image tag in the manifests repo
Two-repo layout
- Giving a single deploy key write access to the whole manifests repo, so any compromised CI job can push to prod
- Mixing platform infrastructure manifests and per-app manifests in one folder with no clear ownership
- Insisting on monorepo or polyrepo as a religion instead of matching the choice to team size and compliance needs
- How does the CI pipeline write to the manifests repo without ending up in an infinite loop?
- What does Argo CD Image Updater do, and would you use it for prod?
- How do you keep manifest changes in sync with app changes that need both to deploy together?
- What is the right scope for one manifests repo? One per team? One per cluster? One global?
More GitOps interview questions
Also worth your time on this topic
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
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.