BLUF: Drift happens when someone (a person or another tool) changes the live cluster without going through Git. The fix isn't more discipline — it's automated, continuous reconciliation. ArgoCD's sync loop detects drift and self-heals it automatically, which is the entire point of GitOps and the reason "just be careful" doesn't work as a strategy.

Terraform and ArgoCD solving two different halves of the same problem is exactly why they disagree so often. Terraform provisions infrastructure — the cluster, the network, the IAM roles. ArgoCD reconciles what's running inside that infrastructure against Git. The moment someone runs kubectl edit directly on a live resource, or Terraform re-applies from stale state, the two sources of truth diverge.

Where Drift Actually Comes From

• A manual kubectl change made "just to fix it quickly" during an incident
• A Helm chart deployed outside the GitOps pipeline, once, and never again — except the manual change stuck
• Terraform state going stale because someone changed a resource in the cloud console directly
• Two GitOps controllers (or ArgoCD and a legacy CI/CD pipeline) both trying to manage the same resource

Making Git the Actual Source of Truth

The fix is architectural, not procedural. ArgoCD continuously compares the live cluster state against what's declared in Git, and by default can automatically correct any divergence:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: platform-services
spec:
  source:
    repoURL: https://github.com/org/platform-gitops
    targetRevision: main
    path: apps/platform
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

selfHeal: true is the setting that actually matters here — without it, ArgoCD will show you drift exists but won't correct it. With it, a manual change gets reverted automatically the next reconciliation cycle, which trains your team out of "quick manual fixes" faster than any policy document will.

Where Terraform Fits (and Where It Shouldn't)

Terraform should own things that change rarely and require careful planning — the cluster itself, VPCs, IAM roles, managed databases. It should not be reapplied routinely against workloads that ArgoCD already manages, because you'll get exactly the disagreement this post is named after: two tools each convinced they're the source of truth for the same resource.

Terraform  →  provisions  →  EKS cluster, VPC, IAM roles, node groups
ArgoCD     →  reconciles  →  everything running inside the cluster

Keep that boundary explicit. The moment Terraform starts managing Kubernetes resources that ArgoCD also touches (via the Kubernetes provider, for example), drift conflicts become routine instead of rare.

Detecting Drift Before It Bites You

# ArgoCD CLI — check for drift without triggering a sync
argocd app diff platform-services

# Terraform — check for drift against live cloud state
terraform plan -detailed-exitcode

Run both checks on a schedule, not just when something breaks. Silent drift that nobody notices for weeks is far more dangerous than drift caught within an hour of happening.

Bottom Line

Drift isn't a discipline problem you solve by asking people to stop clicking around in consoles — it's an architecture problem you solve by giving one tool actual authority to enforce the declared state automatically. That's what selfHeal: true and a clean Terraform/ArgoCD boundary actually buy you: not fewer mistakes, but mistakes that don't survive past the next reconciliation loop.

Need help implementing this? I help teams architect and scale this exact infrastructure. Explore my consulting and freelance services.