GitOps Principles Interview Questions & Answers

Q: How do you promote changes across environments in GitOps?

Promotion moves a tested, immutable artifact/revision from one environment's config to the next, typically via a pull request that updates the target env's image tag or manifest revision. This keeps promotions reviewed, auditable, and reversible, avoiding rebuilding artifacts per environment.

Q: What are common anti-patterns in GitOps?

Anti-patterns include: manual kubectl changes bypassing Git, plaintext secrets in Git, mixing app code and config confusingly, giving CI direct cluster credentials (push), not pinning revisions in prod, and huge blast-radius roots. Each undermines the source-of-truth, security, or reproducibility goals of GitOps.

Q: What tools implement GitOps besides ArgoCD?

Flux CD is the other major CNCF GitOps tool. Both reconcile Git to Kubernetes; ArgoCD emphasizes a rich UI and Application CRD model, while Flux is controller/CRD-centric and composable. Jenkins X and others also offer GitOps workflows, but ArgoCD and Flux are the leading Kubernetes-native choices.

Q: How does GitOps improve developer experience?

Developers use familiar Git workflows (branch, PR, review) to deploy, with no need for cluster credentials or bespoke deploy scripts. They get fast feedback, easy rollback via revert, and visibility of desired vs live state, lowering the barrier to safe, self-service deployments.

Q: How do you validate manifests before they reach the cluster (policy as code)?

Gate merges in CI with schema validation (kubeconform), policy engines (OPA/Gatekeeper, Kyverno, Conftest), and dry-runs. Admission controllers on the cluster enforce policy at apply time too. This shifts errors left so only compliant, valid manifests are merged and reconciled.

Q: What role do webhooks play in GitOps with ArgoCD?

Git webhooks notify ArgoCD immediately when a repo changes, triggering reconciliation without waiting for the poll interval. This shortens deploy latency from minutes to seconds and reduces unnecessary polling load, while polling remains a fallback if a webhook is missed.

Q: What is idempotency and why does it matter in GitOps?

Idempotency means applying the same declared state repeatedly yields the same result. GitOps relies on it: the agent can reconcile continuously and safely re-apply desired state without side effects, so the cluster converges to Git regardless of its current state.

Q: How do you separate application code repos from configuration repos, and why?

Keep source code in app repos and deployment manifests/config in separate config repos (or a dedicated GitOps repo). This decouples build from deploy, lets ArgoCD watch only config, avoids triggering deploys on every code commit, and cleanly separates developer and operational concerns and access.

How do you promote changes across environments in GitOps?

Advanced

Promotion moves a tested, immutable artifact/revision from one environment's config to the next, typically via a pull request that updates the target env's image tag or manifest revision. This keeps promotions reviewed, auditable, and reversible, avoiding rebuilding artifacts per environment.

Real-world example A release validated in staging is promoted by a PR bumping the same image tag in the prod overlay.

Common follow-ups: Why promote the same artifact, not rebuild? | How is promotion made reviewable?

App of Apps Applications GitOps Principles

What are common anti-patterns in GitOps?

Advanced

Anti-patterns include: manual kubectl changes bypassing Git, plaintext secrets in Git, mixing app code and config confusingly, giving CI direct cluster credentials (push), not pinning revisions in prod, and huge blast-radius roots. Each undermines the source-of-truth, security, or reproducibility goals of GitOps.

Real-world example A team eliminates ad-hoc kubectl edits by enabling selfHeal so all changes must go through Git.

Common follow-ups: Why avoid manual kubectl edits? | What's wrong with CI holding cluster creds?

RBAC Sync & Health GitOps Principles

What tools implement GitOps besides ArgoCD?

Beginner

Flux CD is the other major CNCF GitOps tool. Both reconcile Git to Kubernetes; ArgoCD emphasizes a rich UI and Application CRD model, while Flux is controller/CRD-centric and composable. Jenkins X and others also offer GitOps workflows, but ArgoCD and Flux are the leading Kubernetes-native choices.

Real-world example A team evaluates ArgoCD's UI-driven model against Flux's controller-based approach before standardizing on one.

Common follow-ups: How does Flux differ from ArgoCD? | Are they CNCF projects?

Applications Multi-cluster GitOps Principles

How does GitOps improve developer experience?

Intermediate

Developers use familiar Git workflows (branch, PR, review) to deploy, with no need for cluster credentials or bespoke deploy scripts. They get fast feedback, easy rollback via revert, and visibility of desired vs live state, lowering the barrier to safe, self-service deployments.

Real-world example A developer ships to production by merging a PR, never touching kubectl or holding cluster access.

Common follow-ups: Why don't developers need cluster creds? | How does PR review fit deployment?

Applications RBAC GitOps Principles

How do you validate manifests before they reach the cluster (policy as code)?

Advanced

Gate merges in CI with schema validation (kubeconform), policy engines (OPA/Gatekeeper, Kyverno, Conftest), and dry-runs. Admission controllers on the cluster enforce policy at apply time too. This shifts errors left so only compliant, valid manifests are merged and reconciled.

Real-world example A CI step runs Conftest policies so a manifest missing resource limits fails the PR before it can be synced.

Common follow-ups: What is policy as code? | Where do admission controllers fit?

RBAC Sync & Health GitOps Principles

What role do webhooks play in GitOps with ArgoCD?

Intermediate

Git webhooks notify ArgoCD immediately when a repo changes, triggering reconciliation without waiting for the poll interval. This shortens deploy latency from minutes to seconds and reduces unnecessary polling load, while polling remains a fallback if a webhook is missed.

# Configure a webhook to POST to /api/webhook on push

Real-world example A push to main triggers an ArgoCD webhook, syncing the change within seconds instead of the next 3-minute poll.

Common follow-ups: What happens if a webhook is missed? | How much latency do webhooks save?

Sync & Health Applications GitOps Principles

What is idempotency and why does it matter in GitOps?

Beginner

Idempotency means applying the same declared state repeatedly yields the same result. GitOps relies on it: the agent can reconcile continuously and safely re-apply desired state without side effects, so the cluster converges to Git regardless of its current state.

Real-world example Reconciling the same manifest ten times leaves the cluster identical to reconciling it once.

Common follow-ups: Why is idempotency needed for reconciliation? | How does it enable self-healing?

Sync & Health Applications GitOps Principles

How do you separate application code repos from configuration repos, and why?

Advanced

Keep source code in app repos and deployment manifests/config in separate config repos (or a dedicated GitOps repo). This decouples build from deploy, lets ArgoCD watch only config, avoids triggering deploys on every code commit, and cleanly separates developer and operational concerns and access.

Real-world example CI builds an image and opens a PR to the config repo bumping the tag; ArgoCD watches only that config repo.

Common follow-ups: Why not watch the app code repo? | How does the image tag get updated?

App of Apps Applications GitOps Principles