skip to content

ArgoCD

1 roadmap16 questions

The GitOps controller for Kubernetes: an Application points at a Git path, ArgoCD continuously compares desired against live state, reports drift, and syncs or rolls back. Interviewers ask because pull-based reconciliation keeps cluster credentials out of CI and makes Git the audit trail for what is deployed.

on this pageshow

explore

questions

16

In Argo CD, what does an Application resource declare, and what do its spec.source fields (repoURL, path, targetRevision) and spec.destination fields each specify?

level: juniorimportance: must knowfreq 78%

answer

  1. one CRD, two coordinates
  2. what to deploy, where to deploy
  3. repo, folder, revision
  4. cluster URL or name, plus namespace
  5. project fences which of each are legal

basics

~20 s

An Argo CD Application is a Kubernetes custom resource that pairs one desired-state source with one cluster destination. spec.source gives the Git repoURL, the path inside it, and the targetRevision to read; spec.destination gives the cluster and namespace to deploy into.

solid answer

~40 s

`Application` is Argo CD's own CRD (`argoproj.io/v1alpha1`), normally created in the `argocd` namespace. It answers three questions: what to deploy, where to deploy it, and under whose policy. `spec.source` holds `repoURL` (the Git or Helm repository), `path` (the directory of manifests, Kustomize overlay or Helm chart inside that repo), and `targetRevision` (branch, tag, commit SHA, or `HEAD` — for a Helm repo, a chart version). `spec.destination` holds either `server` (the cluster API URL, `https://kubernetes.default.svc` for the local cluster) or `name` (a registered cluster's name), plus `namespace` for namespaced resources. `spec.project` names the `AppProject` that constrains which sources and destinations are even allowed. Argo CD renders the manifests from the source, compares them with what is live in the destination, and reports the app `Synced` or `OutOfSync`.

go deeper

for a junior

Be able to name the three source fields and the two destination fields from memory, and say plainly that an Application is a Kubernetes custom resource, not a config file Argo CD reads from disk.

for a middle

Explain how Argo CD picks the rendering tool from the path's contents, what targetRevision accepts, and that sync status is computed from a diff rather than from a deploy job's exit code.

for a senior

Discuss how you lay Applications out for a real estate of services and clusters, where repository credentials live, and how spec.project keeps an Application from pointing itself somewhere it should not.

for a principal

Own the question of granularity: how much belongs in one Application versus many, what that does to blast radius, ownership boundaries and the number of objects your control plane must reconcile.

## What the object is Argo CD does not read a config file; it reads Kubernetes objects. The central one is `Application`, a custom resource in the `argoproj.io/v1alpha1` API group, usually created in the namespace Argo CD itself runs in (`argocd` by default). One `Application` is one unit of delivery: one bundle of manifests, going to one place, with one sync status. ```yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: checkout namespace: argocd spec: project: payments source: repoURL: https://github.com/acme/manifests.git path: apps/checkout/overlays/prod targetRevision: main destination: server: https://kubernetes.default.svc namespace: checkout ``` ## spec.source — what to deploy `repoURL` is the repository Argo CD clones (HTTPS or SSH Git, or a Helm chart repository / OCI registry). Credentials for it are configured separately as repository secrets, not inline in the Application. `path` is the directory inside that repository whose contents Argo CD renders. Argo CD detects the tool automatically: plain YAML directory, a Kustomize overlay if `kustomization.yaml` is present, a Helm chart if `Chart.yaml` is present, or a config-management plugin. Tool-specific settings live under `source.helm` (for example `valueFiles`, `parameters`) or `source.kustomize`. For a Helm *repository* rather than a Git repo you set `chart:` instead of `path:`. `targetRevision` is the revision of that repository to read: a branch name, a tag, a full commit SHA, or `HEAD` meaning the repository's default branch. For a Helm chart repository it is a chart version and may be a semver range. Which of those you choose changes the guarantee you get — a branch moves under you, a SHA does not. Newer Argo CD versions also accept `spec.sources` (plural) so one Application can combine, for example, an upstream chart with a values file from your own repo. ## spec.destination — where to deploy The destination is a *cluster plus namespace*. Give it either `server`, the cluster's API server URL — `https://kubernetes.default.svc` is the cluster Argo CD itself runs in — or `name`, the friendly name of a cluster registered with `argocd cluster add`. Setting both is rejected. `namespace` is the default namespace for any manifest that does not carry its own `metadata.namespace`; cluster-scoped resources ignore it. If the namespace does not exist, the sync fails unless you enable the `CreateNamespace=true` sync option. This is the field that makes multi-cluster delivery possible without a second Argo CD: one control plane holds credentials for many clusters, and each Application points at one of them. ## spec.project — the policy fence Every Application belongs to an `AppProject`; `default` if you say nothing. The project restricts which `repoURL`s, which destinations, and which resource kinds that Application may use, so a compromised or careless Application manifest cannot point itself at production. ## What Argo CD does with it The application controller periodically refreshes the source (roughly every three minutes by default, and immediately on a repository webhook), renders the manifests, and diffs them against live cluster state. The result is the **sync status**: `Synced` when live matches the rendered desired state, `OutOfSync` when it does not. Whether Argo CD then *acts* on that difference is a separate decision made by `spec.syncPolicy`; with no sync policy, an out-of-sync Application simply sits there until someone runs `argocd app sync` or clicks Sync in the UI. ## Why interviewers start here Because the whole model follows from it: the source of truth is a repository coordinate, the target is a cluster coordinate, and nothing in between is imperative. There is no "deploy step" that pushes; there is an object saying what should be true, and a controller that keeps checking. Candidates who cannot name the three source fields usually also cannot explain why a rollback in this model is a Git revert rather than a pipeline re-run.

  • Where do the credentials for a private repoURL live, since the Application manifest contains none?
    In Argo CD's own namespace, as repository credential secrets labelled `argocd.argoproj.io/secret-type: repository` (or `repo-creds` for a URL prefix), managed through `argocd repo add` or the UI. The Application references only the URL, so the manifest stays safe to commit; Argo CD matches the URL to a stored credential when it clones.
  • What happens if spec.destination.namespace names a namespace that does not exist?
    The sync fails, because Argo CD applies manifests into a namespace it has not been told to create. Adding `CreateNamespace=true` to `spec.syncPolicy.syncOptions` makes Argo CD create the namespace as part of the sync. Many teams instead manage the namespace as a manifest in Git, which also lets them set labels and quotas on it.
  • Can one Application deploy to two clusters?
    No. `spec.destination` is a single cluster and namespace, so one Application is one target. To deploy the same manifests to several clusters you create one Application per cluster, which is exactly the repetition ApplicationSet generators exist to remove.

saying these in an interview costs you the question

  • Thinking the Application manifest itself stores repository credentials
  • Saying targetRevision must be a branch
  • Setting both destination.server and destination.name
  • Assuming Argo CD creates the destination namespace by default
  • Believing one Application can target several clusters

context

resolving links…

open as a page

In Argo CD, an Application reports both a sync status and a health status. What does each one tell you, and what values can each take?

level: juniorimportance: must knowfreq 78%

basics

~20 s

Argo CD tracks two independent axes. Sync status compares live cluster objects with the manifests at the target Git revision (Synced, OutOfSync). Health status judges whether those objects actually work (Healthy, Progressing, Degraded, Suspended, Missing, Unknown).

open as a page

In Argo CD, what does an AppProject constrain, and what does the built-in project named default permit out of the box?

level: juniorimportance: must knowfreq 70%

basics

~20 s

An Argo CD AppProject is a tenancy boundary. It lists which Git repositories its Applications may deploy from, which destination clusters and namespaces they may deploy to, and which resource kinds they may create. The built-in default project allows all of those.

open as a page

In an Argo CD Application's spec.syncPolicy.automated block, what do prune: true and selfHeal: true each change, and what happens when each of them is left off?

level: middleimportance: must knowfreq 80%

basics

~20 s

prune lets automated sync delete live resources that were removed from Git; selfHeal lets it re-apply Git over changes made directly in the cluster. With both off, automated sync only applies new Git revisions and reports everything else as OutOfSync without touching it.

open as a page

In Argo CD, what are resource hooks, which phases can you attach one to, and how would you use them to run a database migration before a new version rolls out?

level: middleimportance: must knowfreq 62%

basics

~20 s

Argo CD resource hooks are ordinary Kubernetes manifests annotated with argocd.argoproj.io/hook so they run at a chosen point of a sync: PreSync, Sync, PostSync or SyncFail. A schema migration is a Job annotated PreSync, so the sync stops if it fails.

open as a page

In Argo CD, how is the RBAC policy in the argocd-rbac-cm ConfigMap written, and how does a user who arrives through SSO in a group get permission to sync one project's applications?

level: middleimportance: must knowfreq 62%

basics

~20 s

Argo CD RBAC is a CSV in the argocd-rbac-cm ConfigMap. Permission lines start with p and grant a subject an action on a resource object; lines starting with g map an SSO group or user to a role. Objects for applications are written project/application.

open as a page

In Argo CD, what does the argocd.argoproj.io/sync-wave annotation change about a sync operation, and what does Argo CD do between one wave and the next?

level: middleimportance: should knowfreq 40%

basics

~20 s

The sync-wave annotation gives a resource an integer ordering key within a sync. Argo CD applies resources wave by wave, from the lowest number upward, and waits for the resources in each wave to report healthy before applying the next.

open as a page

An Argo CD Application sets spec.source.targetRevision. What are the practical differences between pointing it at a branch, a tag, and a full commit SHA?

level: middleimportance: should knowfreq 52%

basics

~20 s

A branch tracks a moving pointer, so any merge changes what Argo CD deploys; a tag is stable but can be moved or deleted by whoever owns the repository; a full commit SHA is immutable, so the deployed content cannot change without editing the Application itself.

open as a page

An Argo CD Application is permanently OutOfSync on a Deployment that nobody has edited, and the diff shows a field written by another controller. How do you diagnose that, and what does spec.ignoreDifferences do about it?

level: seniorimportance: should knowfreq 46%

basics

~20 s

Inspect the actual diff with argocd app diff to find which field differs and who writes it — usually a mutating admission webhook, a defaulting controller or an autoscaler. Then declare that field under spec.ignoreDifferences so Argo CD stops counting it as drift.

open as a page

An Argo CD sync applies every manifest successfully, then the PostSync smoke-test Job fails. What does Argo CD do with the already-applied resources, and how do you get an actual rollback?

level: seniorimportance: should knowfreq 45%

basics

~20 s

Nothing is reverted. Argo CD marks the sync operation Failed, runs any SyncFail hooks, and leaves the new manifests live — the bad version keeps serving. Rolling back means changing Git or delegating the abort to a progressive-delivery controller.

open as a page

In Argo Rollouts, how does an AnalysisTemplate attached to a canary step decide whether to promote or abort, and what does Argo CD show for a Rollout that is paused mid-canary?

level: seniorimportance: should knowfreq 38%

basics

~20 s

An AnalysisRun queries a metrics provider on an interval and evaluates each metric's successCondition; exceeding failureLimit aborts the Rollout, shifting traffic back to the stable ReplicaSet. Argo CD's bundled health check reports a paused Rollout as Suspended, and an aborted one as Degraded.

open as a page

A team owns its own Argo CD AppProject and can commit anything to the repository that project allows. How can that still let them take over the whole cluster, and which AppProject fields prevent it?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Argo CD applies manifests with its own cluster credentials, not the committer's, so a manifest that grants cluster-wide privileges is applied with full rights. The AppProject's destinations and cluster resource whitelist are what stop it, by refusing kinds and namespaces outside the tenant's fence.

open as a page

You run one Argo CD instance for a dozen teams. How do you decide what each team may self-serve through projects and RBAC, and when would you give a team its own Argo CD instance instead?

level: principalimportance: should knowfreq 38%

basics

~20 s

Delegate inside the AppProject and keep the project itself privileged: teams get project roles, tokens and sync rights over their own applications, while the platform owns project definitions and cluster registrations. A separate instance is warranted when the isolation or upgrade coupling of a shared control plane is unacceptable.

open as a page

In Argo CD, what does a sync window configured on an AppProject do, and what happens when an allow window and a deny window overlap?

level: middleimportance: nice to knowfreq 26%

basics

~20 s

An Argo CD sync window is a recurring time range on an AppProject during which syncing its matching applications is allowed or denied. Deny windows take precedence, so an overlapping deny blocks the sync even while an allow window is active.

open as a page

Argo CD reports a third-party custom resource as Healthy the moment it is created, even while its controller is still provisioning the underlying thing. How do you make Argo CD assess that kind's health properly?

level: seniorimportance: nice to knowfreq 32%

basics

~20 s

Register a custom health check for that kind. Argo CD evaluates a Lua script, configured in the argocd-cm ConfigMap under resource.customizations.health.<group>_<kind>, which reads the resource's status and returns Healthy, Progressing, Degraded or Suspended plus a message.

open as a page

Your team hand-maintains around two hundred Argo CD Application manifests across several clusters. How would you decide whether to replace them with ApplicationSet generators, and what risks does that introduce?

level: principalimportance: nice to knowfreq 33%

basics

~20 s

Replace hand-written Applications when the set is derived from data you already have — a list of clusters, directories in a repo, or repositories in an org. ApplicationSet generates Applications from that data plus one template, which removes the copy-paste but concentrates blast radius in a single object.

open as a page