GitOps: Declarative Deployments & Continuous Delivery

GitOps

Why Engineers Care About This

GitOps manages infrastructure and deployments using Git as the single source of truth. Infrastructure and application configurations are stored in Git, and changes are applied automatically when Git is updated. This enables versioning, auditability, and automated deployments. But GitOps requires careful design—declarative configuration, Git workflows, and reconciliation. Understanding GitOps helps you build reliable, auditable deployment processes.

When deployments are manual and error-prone, or infrastructure changes aren't tracked, or you can't rollback deployments easily, you're hitting problems that GitOps solves. These problems compound. Without GitOps, deployments require manual steps (error-prone, slow). Without versioning, infrastructure changes aren't tracked. Good GitOps solves these problems by using Git as source of truth and automating deployments.

In interviews, when someone asks "How would you manage deployments?", they're really asking: "Do you understand GitOps? Do you know how to use Git as source of truth? Do you understand declarative configuration and reconciliation?" Most engineers don't. They use traditional CI/CD without GitOps, or don't understand GitOps principles.

Core Intuitions You Must Build

• Git is the single source of truth for infrastructure and deployments. In GitOps, Git stores all infrastructure and application configurations. Changes to infrastructure or applications are made by updating Git (commits, pull requests). Git becomes the source of truth—what's in Git is what should be deployed. Don't make changes outside of Git—they won't be tracked or versioned.

• Declarative configuration describes desired state, not how to achieve it. GitOps uses declarative configuration (Kubernetes YAML, Terraform) that describes desired state (what should exist), not imperative commands (how to create it). Systems reconcile actual state with desired state (Git state), automatically applying changes. Don't use imperative configuration—it's harder to version and reconcile.

• Reconciliation ensures actual state matches desired state. GitOps tools (ArgoCD, Flux) continuously reconcile actual state (what's deployed) with desired state (what's in Git). If they differ, tools apply changes to match desired state. This enables automatic drift detection and correction. Don't manually reconcile—use GitOps tools for automatic reconciliation.

• GitOps enables fast, reliable deployments. With GitOps, deployments are automated—commit to Git, GitOps tool detects change, applies change automatically. This enables fast deployments (minutes instead of hours) and reliable deployments (automated, no manual steps). But GitOps requires proper Git workflows (branching, pull requests, approvals) to ensure quality.

• GitOps works with multiple environments. GitOps can manage multiple environments (dev, staging, prod) using Git branches or directories. Each environment's configuration is in Git, enabling environment-specific deployments. Use Git branches or directories to separate environments—don't mix environment configurations.

• GitOps requires proper Git workflows. GitOps relies on Git workflows (branching, pull requests, code review, approvals) to ensure quality. Changes should go through pull requests with code review before merging. Production deployments might require approvals. Don't bypass Git workflows—they ensure quality and prevent bad deployments.

Subtopics (Taught Through Real Scenarios)

Git as Source of Truth

What people usually get wrong:

Engineers often make infrastructure changes outside of Git (clicking in cloud console, running commands manually). But in GitOps, Git is the single source of truth—all changes should be made in Git. Changes outside of Git aren't tracked or versioned, and will be overwritten by GitOps reconciliation. Make all changes in Git—don't make changes outside of Git.

How this breaks systems in the real world:

A team used GitOps for infrastructure but made manual changes in cloud console (quick fixes, emergency changes). Manual changes weren't tracked in Git. When GitOps reconciliation ran, it overwrote manual changes (reconciled to Git state), causing issues. The fix? Make all changes in Git—no manual changes outside of Git. Now all changes are tracked and versioned. But the real lesson is: Git is the source of truth. Don't make changes outside of Git.

What interviewers are really listening for:

They want to hear you talk about Git as source of truth, versioning, and avoiding manual changes. Junior engineers say "just make changes where convenient." Senior engineers say "in GitOps, Git is the single source of truth—all infrastructure and application changes should be made in Git, changes outside of Git aren't tracked and will be overwritten by reconciliation." They're testing whether you understand that GitOps is about Git as source of truth, not just "using Git."

Declarative Configuration

What people usually get wrong:

Engineers often use imperative configuration (scripts, commands) instead of declarative configuration. But declarative configuration (Kubernetes YAML, Terraform) describes desired state, enabling reconciliation and versioning. Imperative configuration describes how to achieve state, making reconciliation harder. Use declarative configuration for GitOps—it enables automatic reconciliation.

How this breaks systems in the real world:

A team used imperative scripts for deployments (bash scripts that run commands). Scripts weren't declarative (didn't describe desired state), making reconciliation impossible. GitOps tools couldn't reconcile (didn't know desired state), so deployments were manual. The fix? Use declarative configuration (Kubernetes YAML, Terraform)—describe desired state, enable automatic reconciliation. Now GitOps tools can reconcile automatically. But the real lesson is: declarative configuration enables GitOps. Use it for GitOps.

What interviewers are really listening for:

They want to hear you talk about declarative configuration, desired state, and reconciliation. Junior engineers say "just use scripts." Senior engineers say "use declarative configuration (Kubernetes YAML, Terraform) that describes desired state—enables automatic reconciliation and versioning, imperative configuration doesn't work well with GitOps." They're testing whether you understand that GitOps requires declarative configuration, not just "configuration."

Reconciliation and Drift Detection

What people usually get wrong:

Engineers often don't understand reconciliation in GitOps. But reconciliation is how GitOps ensures actual state matches desired state (Git state). GitOps tools continuously reconcile—if they differ, tools apply changes to match desired state. This enables automatic drift detection and correction. Don't manually reconcile—use GitOps tools for automatic reconciliation.

How this breaks systems in the real world:

A team used GitOps but didn't understand reconciliation. When infrastructure drifted (manual changes, failures), actual state didn't match Git state. GitOps tools didn't reconcile automatically (weren't configured), so drift accumulated. The fix? Configure GitOps tools for automatic reconciliation—tools continuously reconcile actual state with Git state, automatically correcting drift. Now infrastructure stays in sync with Git. But the real lesson is: reconciliation ensures state matches Git. Use GitOps tools for automatic reconciliation.

What interviewers are really listening for:

They want to hear you talk about reconciliation, drift detection, and automatic correction. Junior engineers say "just deploy from Git." Senior engineers say "GitOps tools continuously reconcile actual state with desired state (Git state)—if they differ, tools apply changes to match desired state, enabling automatic drift detection and correction." They're testing whether you understand that GitOps is about reconciliation, not just "deploying from Git."

---

• Git is the single source of truth for infrastructure and deployments—all changes should be made in Git
• Declarative configuration describes desired state—enables reconciliation and versioning
• Reconciliation ensures actual state matches desired state—GitOps tools automatically reconcile
• GitOps enables fast, reliable deployments—automated deployments from Git
• GitOps works with multiple environments—use Git branches or directories for environments
• GitOps requires proper Git workflows—pull requests, code review, approvals
• Good GitOps uses Git as source of truth and automates deployments reliably

---

• CI/CD Pipelines - GitOps vs traditional CI/CD
• Infrastructure as Code - Declarative infrastructure
• Kubernetes - GitOps with Kubernetes