GitOps Principles Interview Questions & Answers

Q: What is GitOps?

GitOps is an operational model where the desired state of infrastructure and applications is declaratively defined in Git, and an automated agent continuously reconciles the live system to match Git. Git becomes the single source of truth; changes are made via pull requests, giving version control, review, auditability, and easy rollback.

Q: What are the core principles of GitOps?

The widely cited principles are: the system is described declaratively; the desired state is versioned and immutable in Git; approved changes are pulled and applied automatically; and software agents continuously reconcile and alert on drift. Together they make deployments reproducible, auditable, and self-healing.

Q: How does ArgoCD implement GitOps?

ArgoCD is a declarative, Kubernetes-native GitOps continuous-delivery tool. It runs in the cluster, watches Git repositories holding Kubernetes manifests, compares the desired state in Git to the live state, and syncs the cluster to match. It reports sync and health status and can auto-heal drift.

Q: What is the difference between push-based and pull-based deployment?

In push-based CD, an external pipeline (e.g., Jenkins) has cluster credentials and pushes changes into the cluster. In pull-based GitOps, an in-cluster agent pulls the desired state from Git and applies it. Pull-based keeps credentials inside the cluster, reduces attack surface, and continuously reconciles rather than firing once per pipeline run.

Q: What is configuration drift and how does GitOps handle it?

Drift is when the live cluster state diverges from the declared state in Git—e.g., someone manually edits a deployment. GitOps detects drift by continuously comparing live vs desired, marks the app OutOfSync, and can auto-heal by reapplying Git's state, restoring the intended configuration and preventing untracked changes.

Q: What are the benefits of GitOps over traditional deployment approaches?

GitOps gives a single source of truth, full audit trail via Git history, easy rollback (revert a commit), consistent reproducible environments, faster and safer deployments through PR review, self-healing against drift, and improved security by keeping credentials in-cluster. It also aligns operations with familiar developer workflows.

Q: How do you perform a rollback in a GitOps workflow?

The GitOps way is to revert the change in Git (revert the commit or point the app to a previous revision/tag), letting the agent reconcile the cluster back. ArgoCD also offers an app-level rollback to a previous synced revision from history, but the durable approach keeps Git as truth so the rollback is itself versioned.

Q: What belongs in Git and what should not in a GitOps setup?

Git holds declarative desired state: Kubernetes manifests, Helm charts/values, Kustomize overlays, and config. It should not hold plaintext secrets. Sensitive data is handled via sealed secrets, external secret operators, or SOPS-encrypted files so Git stays the source of truth without exposing credentials.

Q: How are secrets managed securely in a GitOps workflow?

Because plaintext secrets can't live in Git, common patterns are: Bitnami Sealed Secrets (encrypt secrets that only the in-cluster controller can decrypt), the External Secrets Operator (sync from Vault/AWS/GCP secret managers), or SOPS with age/KMS to store encrypted secrets in Git. ArgoCD applies the encrypted/referencing resource and the operator resolves the real value.

Q: How do you structure Git repositories for GitOps at scale?

Common patterns separate application source code from deployment config (config/manifests in their own repos), and often split per-environment or per-team. Monorepo vs multi-repo trade-offs balance simplicity against blast radius and access control. Kustomize overlays or Helm values manage environment differences from a shared base, and the App of Apps or ApplicationSets manage many apps.

What is GitOps?

Beginner

GitOps is an operational model where the desired state of infrastructure and applications is declaratively defined in Git, and an automated agent continuously reconciles the live system to match Git. Git becomes the single source of truth; changes are made via pull requests, giving version control, review, auditability, and easy rollback.

Real-world example A team deploys only by merging YAML to a Git repo; ArgoCD detects the change and applies it to the cluster automatically.

Common follow-ups: What are the core GitOps principles? | Why is Git the source of truth?

Applications Sync & Health GitOps Principles

What are the core principles of GitOps?

Beginner

The widely cited principles are: the system is described declaratively; the desired state is versioned and immutable in Git; approved changes are pulled and applied automatically; and software agents continuously reconcile and alert on drift. Together they make deployments reproducible, auditable, and self-healing.

Real-world example A platform team documents these four principles as the standard for how every service is deployed and managed.

Common follow-ups: What does 'declarative' mean here? | What is continuous reconciliation?

Sync & Health Applications GitOps Principles

How does ArgoCD implement GitOps?

Beginner

ArgoCD is a declarative, Kubernetes-native GitOps continuous-delivery tool. It runs in the cluster, watches Git repositories holding Kubernetes manifests, compares the desired state in Git to the live state, and syncs the cluster to match. It reports sync and health status and can auto-heal drift.

Real-world example ArgoCD is installed in the cluster and pointed at a Git repo; from then on it keeps the cluster matching the repo.

Common follow-ups: Is ArgoCD push or pull based? | What does ArgoCD compare?

Applications Sync & Health GitOps Principles

What is the difference between push-based and pull-based deployment?

Beginner

In push-based CD, an external pipeline (e.g., Jenkins) has cluster credentials and pushes changes into the cluster. In pull-based GitOps, an in-cluster agent pulls the desired state from Git and applies it. Pull-based keeps credentials inside the cluster, reduces attack surface, and continuously reconciles rather than firing once per pipeline run.

Real-world example Instead of the CI server holding kubeconfig secrets, ArgoCD inside the cluster pulls manifests from Git, so CI never touches the cluster.

Common follow-ups: Why is pull-based more secure? | Can you combine CI with GitOps CD?

Multi-cluster Applications GitOps Principles

What is configuration drift and how does GitOps handle it?

Intermediate

Drift is when the live cluster state diverges from the declared state in Git—e.g., someone manually edits a deployment. GitOps detects drift by continuously comparing live vs desired, marks the app OutOfSync, and can auto-heal by reapplying Git's state, restoring the intended configuration and preventing untracked changes.

spec:
  syncPolicy:
    automated:
      selfHeal: true   # revert manual drift back to Git state

Real-world example An engineer manually scales a deployment; ArgoCD flags OutOfSync and, with selfHeal on, reverts it to the Git-defined replica count.

Common follow-ups: What is selfHeal? | How is drift surfaced to users?

Sync & Health Applications GitOps Principles

What are the benefits of GitOps over traditional deployment approaches?

Intermediate

GitOps gives a single source of truth, full audit trail via Git history, easy rollback (revert a commit), consistent reproducible environments, faster and safer deployments through PR review, self-healing against drift, and improved security by keeping credentials in-cluster. It also aligns operations with familiar developer workflows.

Real-world example After a bad release, the team rolls back simply by reverting the Git commit, and ArgoCD restores the previous state.

Common follow-ups: How does GitOps improve auditability? | How is rollback done?

Applications Sync & Health GitOps Principles

How do you perform a rollback in a GitOps workflow?

Intermediate

The GitOps way is to revert the change in Git (revert the commit or point the app to a previous revision/tag), letting the agent reconcile the cluster back. ArgoCD also offers an app-level rollback to a previous synced revision from history, but the durable approach keeps Git as truth so the rollback is itself versioned.

# Git-first rollback
git revert <bad-commit> && git push
# or ArgoCD history rollback
argocd app rollback my-app <history-id>

Real-world example A regression is undone by reverting the offending commit; ArgoCD syncs the cluster to the known-good state within a minute.

Common follow-ups: Why prefer a Git revert over an imperative rollback? | Where is app history stored?

Sync & Health Applications GitOps Principles

What belongs in Git and what should not in a GitOps setup?

Intermediate

Git holds declarative desired state: Kubernetes manifests, Helm charts/values, Kustomize overlays, and config. It should not hold plaintext secrets. Sensitive data is handled via sealed secrets, external secret operators, or SOPS-encrypted files so Git stays the source of truth without exposing credentials.

Real-world example Manifests and Helm values live in Git, while database passwords are pulled at runtime from a secrets manager via the External Secrets Operator.

Common follow-ups: How are secrets managed in GitOps? | Should generated artifacts be committed?

Applications RBAC GitOps Principles

How are secrets managed securely in a GitOps workflow?

Intermediate

Because plaintext secrets can't live in Git, common patterns are: Bitnami Sealed Secrets (encrypt secrets that only the in-cluster controller can decrypt), the External Secrets Operator (sync from Vault/AWS/GCP secret managers), or SOPS with age/KMS to store encrypted secrets in Git. ArgoCD applies the encrypted/referencing resource and the operator resolves the real value.

# SealedSecret committed to Git; controller decrypts in-cluster
kind: SealedSecret
spec:
  encryptedData:
    password: AgB2b3c...

Real-world example The team commits SealedSecrets to Git; only the cluster's controller can decrypt them, keeping the repo safe to share.

Common follow-ups: How do Sealed Secrets differ from External Secrets? | What is SOPS?

RBAC Applications GitOps Principles

How do you structure Git repositories for GitOps at scale?

Advanced

Common patterns separate application source code from deployment config (config/manifests in their own repos), and often split per-environment or per-team. Monorepo vs multi-repo trade-offs balance simplicity against blast radius and access control. Kustomize overlays or Helm values manage environment differences from a shared base, and the App of Apps or ApplicationSets manage many apps.

Real-world example Source code lives in app repos while a central 'gitops' repo holds environment overlays that ArgoCD watches per cluster.

Common follow-ups: Monorepo vs multi-repo for GitOps? | Why separate app code from config?

App of Apps Multi-cluster GitOps Principles