ArgoCD
Topics in this category
App of Apps Applications GitOps Principles Multi-cluster RBAC Sync & Health Sync Waves & Hooks
ArgoCD

Applications

29 question(s)

What namespace do ArgoCD Application resources live in?

Beginner
By default, Application CRs live in the argocd namespace (where ArgoCD is installed). Newer versions support apps in other namespaces (apps-in-any-namespace) with configuration, but the classic model keeps Application resources in the argocd control-plane namespace while the workloads they deploy live in their target namespaces.
Real-world example The guestbook Application object sits in argocd, but it deploys the guestbook workloads into the guestbook namespace.

Common follow-ups: Can Applications live outside argocd? | Where do the workloads go?

RBAC GitOps Principles Applications

How do you set an Application to auto-create its target namespace?

Intermediate
Add the CreateNamespace=true sync option so ArgoCD creates the destination namespace if it doesn't exist during sync, avoiding a separate namespace manifest. You can also add managed namespace metadata (labels/annotations) via the syncPolicy in newer versions.
syncPolicy:
  syncOptions:
    - CreateNamespace=true
Real-world example A new app deploys cleanly on first sync because ArgoCD creates its namespace automatically.

Common follow-ups: What if the namespace needs labels? | Does this replace a namespace manifest?

Sync & Health GitOps Principles Applications

How do Application parameters differ between Helm and Kustomize sources?

Intermediate
For Helm you override via helm.parameters, helm.values, or helm.valueFiles. For Kustomize you use kustomize.images, namePrefix/nameSuffix, and commonLabels/commonAnnotations. Each maps to that tool's native override mechanism, applied when ArgoCD renders the manifests.
kustomize:
  images: [ myapp=repo/myapp:v3 ]
helm:
  parameters: [ { name: image.tag, value: v3 } ]
Real-world example The Helm app overrides image.tag while the Kustomize app overrides the image via kustomize.images.

Common follow-ups: Which section overrides Helm values? | How does Kustomize override images?

GitOps Principles Sync & Health Applications

What is a config management plugin (CMP) and when do you need one?

Advanced
A CMP extends ArgoCD to render manifests with tools it doesn't natively support (e.g., cdk8s, jsonnet bundler, custom templating). You define the plugin in the repo-server (sidecar) and reference it in the Application. Use it when your manifests are generated by a tool outside Helm/Kustomize/Jsonnet.
source:
  plugin:
    name: my-cmp
Real-world example A team generating manifests with cdk8s wires a CMP so ArgoCD can render and sync that output.

Common follow-ups: How is a CMP deployed? | When is a CMP unnecessary?

GitOps Principles Sync & Health Applications

How do you temporarily pause management of an Application?

Intermediate
Switch it to manual sync (remove syncPolicy.automated) or use sync windows to block syncs, so ArgoCD stops applying changes while you investigate. You can also disable selfHeal to allow manual live changes. These pause reconciliation without deleting the app.
Real-world example During an incident, the team disables auto-sync on an app so a manual hotfix isn't immediately reverted.

Common follow-ups: How do you stop selfHeal reverting a hotfix? | What are sync windows?

Sync & Health RBAC Applications

How do you handle large Applications that hit apply size or performance limits?

Advanced
Split into multiple smaller Applications (by component), use ServerSideApply to avoid last-applied-config size limits, enable ApplyOutOfSyncOnly to apply only changed resources, and consider sharding the controller. Smaller, focused apps reconcile faster and reduce blast radius.
syncPolicy:
  syncOptions: [ ServerSideApply=true, ApplyOutOfSyncOnly=true ]
Real-world example A monolithic app that reconciled slowly is broken into per-component Applications that sync quickly and independently.

Common follow-ups: What does ApplyOutOfSyncOnly do? | Why split large apps?

Multi-cluster Sync & Health Applications

What is the targetRevision HEAD and when should you avoid it?

Beginner
targetRevision: HEAD tracks the default branch's latest commit. It's convenient for dev but risky for production because any merge deploys immediately; production should pin to an immutable tag or SHA so releases are deliberate and reproducible.
Real-world example Staging tracks HEAD for fast iteration while production pins to tag v2.3.0 for controlled releases.

Common follow-ups: Why avoid HEAD in production? | What should production pin to?

GitOps Principles Sync & Health Applications

How do you view an Application's sync history and roll back to a prior revision?

Intermediate
Use `argocd app history <app>` to list previously synced revisions with IDs, and `argocd app rollback <app> <id>` to sync back to one. The durable GitOps approach is reverting in Git, but history rollback is useful for quick recovery to a known-good synced state.
argocd app history web
argocd app rollback web 12
Real-world example After a bad sync, the operator rolls back to history id 12 to restore service, then reverts in Git.

Common follow-ups: Where is history stored? | Why also revert in Git after a rollback?

Sync & Health GitOps Principles Applications

How do you manage shared/common configuration across many Applications?

Advanced
Factor shared config into a common Helm chart or Kustomize base that apps reference, use ApplicationSet templates for consistency, and centralize cross-cutting policy in Projects. This avoids duplication so a change to shared defaults propagates to all consuming apps.
Real-world example All services inherit standard labels, resource limits, and network policies from a shared Kustomize base.

Common follow-ups: How do ApplicationSets reduce duplication? | Where do cross-cutting policies live?

App of Apps Multi-cluster Applications