Organizing a Shared Manifests Repo for Multiple Teams
Three teams share one Argo CD instance and one manifests repo. How do you lay it out so each team can ship without waiting on each other and can't accidentally deploy each other's stuff?
Three teams share one Argo CD instance and one manifests repo. How do you lay it out so each team can ship without waiting on each other and can't accidentally deploy each other's stuff?
Two things have to work: ownership at the directory level so reviews go to the right people, and AppProjects in Argo CD so the cluster enforces the boundary even if a PR slips through. Repo layout, top level split by team: teams/ payments/ apps/ checkout/ ledger/ projects/ payments.yaml # AppProject for payments team search/ apps/ indexer/ query-api/ projects/ search.yaml platform/ apps/ ingress-nginx/ cert-manager/ projects/ platform.yaml argocd/ applicationsets/ payments.yaml # one ApplicationSet per team search.yaml platform.yaml Then four things wired together: 1. CODEOWNERS at the repo root maps directory paths to team groups. teams/payments/** routes reviews to @org/payments-platform. Branch protection on main requires a review from the right code owners, so a search team PR cannot land changes under teams/payments without a payments reviewer. 2. One AppProject per team. The AppProject restricts which source repo paths the team's Applications can read from, which destinations (cluster plus namespace) they can deploy to, and which Kubernetes resource kinds they are allowed to create. The payments team's AppProject cannot deploy into the search-prod namespace even if someone tries. 3. One ApplicationSet per team with a Git directory generator pointed at that team's apps folder. New app appears under teams/payments/apps, a new Application appears automatically, owned by the payments project. 4. RBAC on the Argo CD UI mirrors the projects. Payments engineers can sync payments Applications, see them, restart pods. They cannot touch search Applications. The platform team can see everything. The AppProject is the load-bearing piece. CODEOWNERS protects the Git side. The AppProject protects the cluster side. You need both. CODEOWNERS alone is fine until a platform engineer with write-everywhere access merges a typo. The AppProject stops the deploy at the controller before it ever reaches the API server. One thing I avoid. Do not put every team's apps in a single flat apps/ directory with team prefixes in the names like apps/payments-checkout. It works for five apps and falls apart at fifty. Directory boundaries cost nothing and CODEOWNERS matches them naturally.
This is a strong mid-level question because multi-tenant Argo CD is where most teams hit their first real organizational pain. Strong candidates know that GitOps repo structure has to combine with both Git review controls (CODEOWNERS, branch protection) and Argo CD's own RBAC (AppProjects). Weak candidates lean entirely on one side, usually CODEOWNERS, and miss that the cluster has no idea what GitHub thinks. The AppProject is what stops a bad deploy at the controller. Watch for that.
CODEOWNERS file routing reviews per team directory
AppProject restricting where the payments team can deploy
ApplicationSet that auto-generates Applications for the team
- Relying only on CODEOWNERS without an AppProject, so once a PR merges any team can technically deploy anywhere
- Giving every team a single shared AppProject called default with no destination restrictions, which is the same as having no project at all
- Flat-namespacing apps like apps/payments-checkout instead of using directories, then losing CODEOWNERS routing as the repo grows
- A team wants to deploy a CRD their app needs. The AppProject namespaceResourceWhitelist does not include CustomResourceDefinition. What is the right way to handle that request?
- How do you stop the platform team from becoming the bottleneck for every new AppProject change?
- What goes wrong if two teams both want to manage their own ApplicationSets without platform review?
- How would you give a team read-only access to prod Applications but full access to their dev ones?
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
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
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.