GitOps Principles Interview Questions & Answers

Q: What is the reconciliation loop and how often does ArgoCD run it?

The reconciliation loop continuously compares desired (Git) vs live (cluster) state and acts on differences. ArgoCD polls Git on an interval (default ~3 minutes) and can react instantly to webhooks; it also watches cluster resources. Reconciliation computes the diff, updates sync/health status, and applies changes if auto-sync is enabled.

Q: How does GitOps support disaster recovery?

Because the entire desired state is in Git, recovering a cluster means installing ArgoCD and pointing it at the same Git repos; it rebuilds all applications to match. This makes clusters reproducible and reduces recovery time. Combined with backups of stateful data and cluster-level bootstrap (App of Apps), whole environments can be recreated declaratively.

Q: What is declarative vs imperative configuration?

Declarative configuration states the desired end state ('there should be 3 replicas') and lets the system converge to it; imperative issues step-by-step commands ('scale to 3 now'). GitOps is declarative: you commit the desired state and the agent makes it so, which is idempotent, reproducible, and self-correcting versus one-off imperative commands.

Q: How does GitOps improve security and compliance?

Every change is a reviewed, attributable Git commit, giving a complete audit trail and enforced approvals via branch protection. Cluster credentials stay inside the cluster (pull model), reducing exposure. Policy checks and CI can gate merges, and drift detection ensures only approved state persists—supporting compliance evidence and least-privilege access.

Q: What are the trade-offs and limitations of GitOps?

GitOps excels for declarative Kubernetes config but adds friction for imperative or highly dynamic actions, secret handling needs extra tooling, and Git becomes a critical dependency. Debugging can require understanding reconciliation timing, and very large fleets need patterns (ApplicationSets) to avoid sprawl. It's not ideal for one-off tasks or non-declarative systems.

Q: What is a source of truth and why does GitOps use Git for it?

A single source of truth is the one authoritative record of desired state. GitOps uses Git because it provides versioning, history, code review, access control, and rollback out of the box, and it's a familiar developer tool—making desired state auditable and collaborative.

Q: What is continuous reconciliation?

Continuous reconciliation is an agent repeatedly comparing desired state (Git) to actual state (cluster) and correcting differences, rather than applying changes only once. It keeps the system converged over time and detects drift automatically.

Q: How does GitOps enable auditability and compliance evidence?

Because every change is a Git commit with author, timestamp, and review, Git history is a complete, tamper-evident audit trail of who changed what and when. Branch protection enforces approvals, satisfying change-management and separation-of-duties requirements.

Q: What is the difference between GitOps and Infrastructure as Code (IaC)?

IaC is codifying infrastructure declaratively; GitOps is an operating model that uses IaC plus Git as the source of truth and an agent that continuously reconciles. All GitOps uses IaC, but not all IaC is GitOps—IaC run manually via a pipeline isn't GitOps without pull-based continuous reconciliation.

Q: How do you handle non-Kubernetes resources in a GitOps model?

For cloud resources outside Kubernetes, use operators that reconcile external state from CRDs (e.g., Crossplane, cloud provider operators). ArgoCD then manages those CRs in Git like any manifest, extending GitOps to databases, queues, and cloud infra via Kubernetes-native controllers.

What is the reconciliation loop and how often does ArgoCD run it?

Advanced

The reconciliation loop continuously compares desired (Git) vs live (cluster) state and acts on differences. ArgoCD polls Git on an interval (default ~3 minutes) and can react instantly to webhooks; it also watches cluster resources. Reconciliation computes the diff, updates sync/health status, and applies changes if auto-sync is enabled.

# argocd-cm: change polling interval
data:
  timeout.reconciliation: 180s

Real-world example A Git webhook triggers ArgoCD to reconcile immediately on merge instead of waiting for the next poll cycle.

Common follow-ups: How do webhooks speed reconciliation? | What does the loop compare?

Sync & Health Applications GitOps Principles

How does GitOps support disaster recovery?

Advanced

Because the entire desired state is in Git, recovering a cluster means installing ArgoCD and pointing it at the same Git repos; it rebuilds all applications to match. This makes clusters reproducible and reduces recovery time. Combined with backups of stateful data and cluster-level bootstrap (App of Apps), whole environments can be recreated declaratively.

Real-world example After losing a cluster, the team provisions a new one, installs ArgoCD, applies the root app, and the platform rebuilds from Git.

Common follow-ups: What still needs separate backup beyond Git? | How does App of Apps help DR?

App of Apps Multi-cluster GitOps Principles

What is declarative vs imperative configuration?

Beginner

Declarative configuration states the desired end state ('there should be 3 replicas') and lets the system converge to it; imperative issues step-by-step commands ('scale to 3 now'). GitOps is declarative: you commit the desired state and the agent makes it so, which is idempotent, reproducible, and self-correcting versus one-off imperative commands.

# Declarative desired state
spec:
  replicas: 3
# vs imperative: kubectl scale deploy/app --replicas=3

Real-world example The repo declares 3 replicas; whether the cluster had 1 or 5, ArgoCD converges it to 3.

Common follow-ups: Why is declarative idempotent? | How does this enable self-healing?

Applications Sync & Health GitOps Principles

How does GitOps improve security and compliance?

Intermediate

Every change is a reviewed, attributable Git commit, giving a complete audit trail and enforced approvals via branch protection. Cluster credentials stay inside the cluster (pull model), reducing exposure. Policy checks and CI can gate merges, and drift detection ensures only approved state persists—supporting compliance evidence and least-privilege access.

Real-world example Auditors trace every production change to a signed, reviewed pull request, satisfying change-management controls.

Common follow-ups: How do branch protections enforce approvals? | Why does the pull model reduce risk?

RBAC Applications GitOps Principles

What are the trade-offs and limitations of GitOps?

Advanced

GitOps excels for declarative Kubernetes config but adds friction for imperative or highly dynamic actions, secret handling needs extra tooling, and Git becomes a critical dependency. Debugging can require understanding reconciliation timing, and very large fleets need patterns (ApplicationSets) to avoid sprawl. It's not ideal for one-off tasks or non-declarative systems.

Real-world example The team keeps ad-hoc database migrations in a controlled Job with hooks rather than forcing every imperative action through GitOps.

Common follow-ups: When is GitOps a poor fit? | How do you handle imperative tasks?

Sync Waves & Hooks Applications GitOps Principles

What is a source of truth and why does GitOps use Git for it?

Beginner

A single source of truth is the one authoritative record of desired state. GitOps uses Git because it provides versioning, history, code review, access control, and rollback out of the box, and it's a familiar developer tool—making desired state auditable and collaborative.

Real-world example Every environment's desired state lives in Git, so 'what should be running' is always answerable from one place.

Common follow-ups: Why Git specifically? | What does 'authoritative' mean here?

Applications Sync & Health GitOps Principles

What is continuous reconciliation?

Beginner

Continuous reconciliation is an agent repeatedly comparing desired state (Git) to actual state (cluster) and correcting differences, rather than applying changes only once. It keeps the system converged over time and detects drift automatically.

Real-world example Even with no new commits, ArgoCD keeps checking and correcting the cluster so it never quietly diverges from Git.

Common follow-ups: How is this different from a one-off apply? | What detects drift?

Sync & Health Applications GitOps Principles

How does GitOps enable auditability and compliance evidence?

Intermediate

Because every change is a Git commit with author, timestamp, and review, Git history is a complete, tamper-evident audit trail of who changed what and when. Branch protection enforces approvals, satisfying change-management and separation-of-duties requirements.

Real-world example An auditor reconstructs the entire change history of production from Git logs and merged pull requests.

Common follow-ups: How do branch protections help? | Why is Git history tamper-evident?

RBAC Applications GitOps Principles

What is the difference between GitOps and Infrastructure as Code (IaC)?

Intermediate

IaC is codifying infrastructure declaratively; GitOps is an operating model that uses IaC plus Git as the source of truth and an agent that continuously reconciles. All GitOps uses IaC, but not all IaC is GitOps—IaC run manually via a pipeline isn't GitOps without pull-based continuous reconciliation.

Real-world example Terraform applied by hand is IaC; the same declarations reconciled continuously by an in-cluster agent is GitOps.

Common follow-ups: Is all IaC GitOps? | What does GitOps add to IaC?

Applications Multi-cluster GitOps Principles

How do you handle non-Kubernetes resources in a GitOps model?

Intermediate

For cloud resources outside Kubernetes, use operators that reconcile external state from CRDs (e.g., Crossplane, cloud provider operators). ArgoCD then manages those CRs in Git like any manifest, extending GitOps to databases, queues, and cloud infra via Kubernetes-native controllers.

Real-world example An S3 bucket is declared as a Crossplane CR in Git; ArgoCD syncs it and Crossplane provisions the real bucket.

Common follow-ups: What is Crossplane? | How does an operator extend GitOps beyond K8s?

Applications Multi-cluster GitOps Principles