App of Apps Interview Questions & Answers

Q: In App of Apps, what is the 'root' application?

The root (parent) application is the single Application you apply manually that points at a directory of child Application manifests. Syncing it creates all the children, which in turn deploy the actual workloads—making the root the one entry point for a whole environment.

Q: How do you install the root app to bootstrap an environment?

After installing ArgoCD, apply the root Application manifest (kubectl apply -f root.yaml or argocd app create). ArgoCD then syncs it, creating the child Applications. This single command bootstraps the environment declaratively.

Q: How do child applications reference different repos or paths?

Each child Application manifest has its own source (repoURL/path/targetRevision), so children can point at entirely different repos, chart paths, or revisions. The parent just aggregates the child manifests; each child independently defines where its manifests come from.

Q: How do you add a new application in an App of Apps setup?

Commit a new child Application manifest into the directory the root watches; on the next sync the root creates the new child, which then deploys its workloads. Adding an app is thus a simple Git commit, keeping the process GitOps-native.

Q: How do you prevent accidental deletion of all child apps?

Be cautious with the resources-finalizer and prune on the root. Omit the cascading finalizer if you don't want deleting the root to delete children, protect critical children with Prune=false, review parent changes via PR, and scope roots per domain to limit blast radius.

Q: How do you structure directories for an App of Apps repo?

A common layout has a root app pointing at an apps/ (or per-environment) directory of child Application manifests, with each child referencing its own manifests path. Separate directories per environment/cluster let one root per env manage that env's apps cleanly.

Q: When should you migrate from App of Apps to ApplicationSets?

Migrate when you're hand-maintaining many near-identical child manifests, deploying to many clusters, or need dynamic generation (per-PR, per-directory). ApplicationSets template these automatically. Keep App of Apps for a small, static, curated set where explicit manifests are clearer.

Q: How do you manage secrets for child apps in App of Apps?

Secrets are handled the same as any GitOps app—via Sealed Secrets, External Secrets, or SOPS—referenced by child apps, not stored plaintext in the parent or children. The App of Apps structure doesn't change secret handling; each child pulls secrets through the chosen mechanism.

Q: How do you use sync waves on child applications for ordered platform bootstrap?

Annotate child Application resources with sync waves so the parent creates foundational apps first (CRDs, ingress, cert-manager in low waves) before dependent workloads (higher waves). This ensures the platform layer is Healthy before apps that rely on it are created.

Q: What's the benefit of a single sync point in App of Apps?

A single root gives one place to see and control an environment's whole app set: sync all children together, get an overview of status, and recreate everything from one manifest. It simplifies operations and disaster recovery compared to managing dozens of apps individually.

In App of Apps, what is the 'root' application?

Beginner

The root (parent) application is the single Application you apply manually that points at a directory of child Application manifests. Syncing it creates all the children, which in turn deploy the actual workloads—making the root the one entry point for a whole environment.

Real-world example Applying one root app spins up child apps for ingress, monitoring, and every service.

Common follow-ups: What does the root deploy? | Why is it applied manually?

Applications Multi-cluster App of Apps

How do you install the root app to bootstrap an environment?

Beginner

After installing ArgoCD, apply the root Application manifest (kubectl apply -f root.yaml or argocd app create). ArgoCD then syncs it, creating the child Applications. This single command bootstraps the environment declaratively.

kubectl apply -n argocd -f root-app.yaml

Real-world example A fresh cluster is bootstrapped by installing ArgoCD and applying the root app once.

Common follow-ups: What's the single bootstrap command? | What happens after the root syncs?

GitOps Principles Multi-cluster App of Apps

How do child applications reference different repos or paths?

Intermediate

Each child Application manifest has its own source (repoURL/path/targetRevision), so children can point at entirely different repos, chart paths, or revisions. The parent just aggregates the child manifests; each child independently defines where its manifests come from.

Real-world example One child pulls a Helm chart from a chart repo while another pulls Kustomize overlays from a Git monorepo.

Common follow-ups: Can children use different repos? | What does the parent actually manage?

Applications GitOps Principles App of Apps

How do you add a new application in an App of Apps setup?

Intermediate

Commit a new child Application manifest into the directory the root watches; on the next sync the root creates the new child, which then deploys its workloads. Adding an app is thus a simple Git commit, keeping the process GitOps-native.

Real-world example Onboarding a new service is just adding its Application YAML to the apps directory and merging.

Common follow-ups: What triggers the new child's creation? | Is any manual step needed after merge?

Applications GitOps Principles App of Apps

How do you prevent accidental deletion of all child apps?

Advanced

Be cautious with the resources-finalizer and prune on the root. Omit the cascading finalizer if you don't want deleting the root to delete children, protect critical children with Prune=false, review parent changes via PR, and scope roots per domain to limit blast radius.

# Omit this on the root if you don't want cascade deletes:
finalizers: [ resources-finalizer.argocd.argoproj.io ]

Real-world example The root omits the resources finalizer so removing it doesn't wipe every child environment by accident.

Common follow-ups: What does the resources-finalizer trigger? | How do you protect critical children?

Applications RBAC App of Apps

How do you structure directories for an App of Apps repo?

Intermediate

A common layout has a root app pointing at an apps/ (or per-environment) directory of child Application manifests, with each child referencing its own manifests path. Separate directories per environment/cluster let one root per env manage that env's apps cleanly.

gitops/
  root-app.yaml
  apps/
    ingress.yaml
    monitoring.yaml
    service-a.yaml

Real-world example The prod root watches clusters/prod/apps/, a folder of that cluster's child Application manifests.

Common follow-ups: How do you separate environments? | Where do child manifests point?

Multi-cluster GitOps Principles App of Apps

When should you migrate from App of Apps to ApplicationSets?

Advanced

Migrate when you're hand-maintaining many near-identical child manifests, deploying to many clusters, or need dynamic generation (per-PR, per-directory). ApplicationSets template these automatically. Keep App of Apps for a small, static, curated set where explicit manifests are clearer.

Real-world example Growing from 5 to 50 clusters, the team replaces per-cluster child manifests with a cluster-generator ApplicationSet.

Common follow-ups: What signals it's time for ApplicationSets? | When is App of Apps still fine?

Applications Multi-cluster App of Apps

How do you manage secrets for child apps in App of Apps?

Intermediate

Secrets are handled the same as any GitOps app—via Sealed Secrets, External Secrets, or SOPS—referenced by child apps, not stored plaintext in the parent or children. The App of Apps structure doesn't change secret handling; each child pulls secrets through the chosen mechanism.

Real-world example Child apps reference External Secrets that resolve from Vault, so no secrets sit in the App of Apps repo.

Common follow-ups: Does App of Apps change secret handling? | How do children get secrets?

GitOps Principles RBAC App of Apps

How do you use sync waves on child applications for ordered platform bootstrap?

Advanced

Annotate child Application resources with sync waves so the parent creates foundational apps first (CRDs, ingress, cert-manager in low waves) before dependent workloads (higher waves). This ensures the platform layer is Healthy before apps that rely on it are created.

# child app
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"   # platform before wave 1 apps

Real-world example cert-manager and ingress (wave 0) become Healthy before the workloads (wave 1) that need TLS and routing.

Common follow-ups: What ordering do waves give across children? | Why bootstrap platform first?

Sync Waves & Hooks Multi-cluster App of Apps

What's the benefit of a single sync point in App of Apps?

Beginner

A single root gives one place to see and control an environment's whole app set: sync all children together, get an overview of status, and recreate everything from one manifest. It simplifies operations and disaster recovery compared to managing dozens of apps individually.

Real-world example The team monitors and re-syncs the entire environment from the one root app in the ArgoCD UI.

Common follow-ups: How does it aid disaster recovery? | What does the root give operationally?

GitOps Principles Multi-cluster App of Apps