Two common GitOps repository layouts for multiple environments

WHAT THIS TESTS: The interviewer wants to know if you understand that GitOps at scale is a state-store architecture problem, not just a tooling problem. They care whether you can reason about repository boundaries, reconciler performance, blast radius, and access control in a multi-cluster setup. The question separates candidates who have run GitOps in production from those who have only seen single-cluster demos.

A GOOD ANSWER COVERS: First, the monorepo with path-based or overlay separation. In this model, one Git repository contains directories like envs/dev and envs/prod or uses Kustomize overlays per environment. The pros are a single source of truth, atomic pull requests that can modify multiple environments simultaneously, and straightforward dependency tracking. The cons are that as YAML file counts grow into the thousands, GitOps controllers suffer polling bottlenecks because they must scan the entire repository to detect changes. There is also a larger blast radius since a misconfigured commit can affect every environment, and fine-grained access control is harder because everyone with write access sees all environments.

Second, the repository-per-environment model. Here, each environment gets its own Git repository, for example myapp-dev-gitops and myapp-prod-gitops. The pros are smaller repository sizes that reduce controller polling overhead, tighter access controls since you can restrict who can push to production, and isolated blast radius. The cons are harder change promotion because you must replicate commits or use automation to propagate changes across repositories, increased risk of configuration drift between environments, and more repositories to manage and secure.

COMMON WRONG ANSWERS: Recommending Git branch-per-environment as a valid strategy. Branches violate the GitOps principle that desired state must be versioned and immutable; a branch is a mutable pointer, not a permanent artifact, so you lose traceability and invite drift. Another red flag is ignoring reconciler performance entirely and claiming a monorepo scales infinitely. A third is suggesting that Helm charts with heavy conditional logic belong in Git; the reference notes that complex templating reduces visibility into what will actually run, so treating Git as data storage rather than code storage matters.

LIKELY FOLLOW-UPS: How would you promote a change from staging to production safely? How do you handle secrets in a GitOps repo without storing them in plain text? At what point does a monorepo become too large for Argo CD or Flux, and what do you do about it? How do you prevent a bad commit from taking down every environment at once?

ONE CONCRETE EXAMPLE: Imagine a platform team managing 15 microservices across 3 environments. With a monorepo, a single Kustomize overlay change for a CPU limit can be reviewed in one pull request, but Argo CD must poll a repository containing 4000 YAML files, causing noticeable lag in reconciliation. Switching to repo-per-environment cuts the polling payload by two thirds and lets the team give only senior SREs write access to the production repository, but they must now build a small promotion pipeline that opens automated pull requests from the staging repo to the production repo rather than simply merging a branch.