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?

Mid-Level questions

GitOpsintermediate

// interview question

Should your application source code and Kubernetes manifests live in the same repo or in separate repos? What is your take?

Sample answer

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.

Why this matters

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.

Code examples

CI step that bumps the image tag in the manifests repo

yaml

# .github/workflows/build.yml
name: build-and-promote
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push image
        run: |
          IMAGE_TAG=$(git rev-parse --short HEAD)
          docker build -t ghcr.io/org/web:${IMAGE_TAG} .
          docker push ghcr.io/org/web:${IMAGE_TAG}
          echo "IMAGE_TAG=${IMAGE_TAG}" >> $GITHUB_ENV

      - name: Bump image in manifests repo
        env:
          GH_TOKEN: ${{ secrets.MANIFESTS_REPO_TOKEN }}
        run: |
          git clone https://x-access-token:${GH_TOKEN}@github.com/org/manifests.git
          cd manifests/apps/web/overlays/dev
          kustomize edit set image web=ghcr.io/org/web:${IMAGE_TAG}
          git config user.email bot@example.com
          git config user.name ci-bot
          git add kustomization.yaml
          git commit -m "web: bump dev to ${IMAGE_TAG}"
          git push

Two-repo layout

bash

# Repo 1: org/web (application code)
src/
Dockerfile
Makefile
.github/workflows/build.yml

# Repo 2: org/manifests (Kubernetes manifests, watched by Argo CD)
argocd/
  applications/
    web-dev.yaml
    web-prod.yaml
apps/
  web/
    base/
    overlays/
      dev/
      prod/
platform/
  ingress-nginx/
  cert-manager/
  prometheus/

Common mistakes to avoid

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

Likely follow-ups

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?

Answer out loud first, then check yourself against the model answer.

Practice all Mid-Level questions More GitOps questions

#gitops#argocd#deployments#repository-structure#cicd

Also worth your time on this topic

Checklist

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

Interview

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

Article

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.

Application Code vs Kubernetes Manifests in Separate Repos

More GitOps interview questions

Also worth your time on this topic

Argo CD Multi-Environment Repository Structure Checklist

Bootstrapping Argo CD and Letting It Manage Itself

GitOps with Argo CD: Structuring Your Repository for Multi-Environment Deployments