What is Argo CD and How Does GitOps Deployment Work?
Learn how Argo CD reconciles Kubernetes clusters against Git using GitOps, including sync states, self-heal, and rollback via Git revert.
Expected Interview Answer
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes that continuously compares the live cluster state against manifests stored in a Git repository and automatically (or on approval) reconciles the cluster to match that desired state.
Argo CD runs as a controller inside the cluster, watching one or more Git repositories that hold Kubernetes manifests, Helm charts, or Kustomize overlays defined as the single source of truth. It continuously diffs the live resources against the Git-declared desired state and reports the Application as `Synced` or `OutOfSync`; when out of sync it can auto-heal by reapplying the desired manifests, or wait for manual sync approval depending on policy. Because deployment happens by merging to Git rather than by a pipeline pushing directly to the cluster, every change is auditable through Git history, rollbacks are simply a Git revert, and cluster drift caused by manual `kubectl` edits is automatically detected and can be corrected. Argo CD’s UI and CLI surface diffs, sync history, and application health so teams get visibility into exactly what changed and when, decoupling the CI process (building and testing an image) from the CD process (Argo CD reconciling the cluster).
- Git becomes the single, auditable source of truth for cluster state
- Automatic drift detection and self-healing against manual changes
- Rollback is just a Git revert, no special deployment tooling needed
- Decouples CI (build/test) from CD (cluster reconciliation)
AI Mentor Explanation
Argo CD is like a ground staff supervisor who continuously checks the pitch against the official pitch specification document rather than trusting whatever changes were made overnight. If someone mowed the grass to the wrong length without updating the document, the supervisor notices the mismatch and either restores the pitch to spec automatically or flags it for the curator to approve. Any legitimate change to the pitch only happens by first updating the specification document, never by directly altering the pitch. This means the pitch’s history is fully traceable through the document’s revision log, and reverting to an old spec instantly restores the old pitch condition.
Step-by-Step Explanation
Step 1
Store manifests in Git
Kubernetes YAML, Helm charts, or Kustomize overlays live in a Git repo as the desired state.
Step 2
Register an Application
Argo CD watches the repo path and maps it to a target cluster/namespace as an Application resource.
Step 3
Continuously diff state
Argo CD compares live cluster resources against Git and marks the Application Synced or OutOfSync.
Step 4
Sync or self-heal
Argo CD reconciles automatically (auto-sync) or waits for manual approval, and can auto-heal manual drift.
What Interviewer Expects
- Clear articulation of the GitOps pull-based reconciliation model
- Understanding of Synced vs OutOfSync application states
- Awareness that rollback is a Git revert, not a special CD command
- Knowledge of how Argo CD decouples CI (build/test) from CD (deploy)
Common Mistakes
- Confusing Argo CD (GitOps CD) with a CI tool like Jenkins or GitHub Actions
- Pushing changes via kubectl directly and expecting Argo CD to leave them alone
- Not understanding automatic sync vs manual sync policy tradeoffs
- Forgetting that Argo CD needs cluster RBAC permissions scoped to what it manages
Best Answer (HR Friendly)
“Argo CD watches our Kubernetes manifests in Git and keeps the actual cluster matching what is declared there — if someone changes something manually or a deployment drifts, Argo CD detects it and can automatically fix it. Because everything is driven by Git, every deployment is auditable, and rolling back is as simple as reverting a Git commit.”
Code Example
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/example/myapp-manifests.git
targetRevision: main
path: overlays/production
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: trueFollow-up Questions
- How does Argo CD detect and correct configuration drift?
- What is the difference between automated sync and self-heal?
- How would you roll back a bad deployment managed by Argo CD?
- How does Argo CD fit alongside a CI tool like Jenkins or GitHub Actions?
MCQ Practice
1. What is the source of truth in Argo CD's GitOps model?
GitOps treats Git as the single source of truth; Argo CD reconciles the cluster to match what is declared there.
2. What does it mean when an Argo CD Application shows "OutOfSync"?
OutOfSync means the actual cluster resources no longer match the desired state declared in the Git repository.
3. How would you typically roll back a bad change in an Argo CD-managed application?
Since Git is the source of truth, reverting the manifest commit and letting Argo CD reconcile is the standard rollback.
Flash Cards
What is Argo CD? — A declarative GitOps continuous delivery tool that reconciles a Kubernetes cluster to match Git.
What does Synced vs OutOfSync mean? — Whether the live cluster state matches (Synced) or differs from (OutOfSync) the Git-declared state.
How do you roll back with Argo CD? — Revert the Git commit; Argo CD reconciles the cluster back to the prior state.
What does self-heal do? — Automatically corrects manual drift in the cluster back to the Git-declared desired state.