What's the difference between Argo CD's 'prune' sync option and just letting old resources sit in the cluster, and why is prune considered higher-risk?

Argo CD's default behavior (prune: false, or not set) is conservative: it applies whatever's in Git, but if a manifest is removed from the tracked Git path, Argo CD doesn't infer that means 'delete this from the cluster too' — the corresponding resource is simply no longer managed/tracked but stays running, becoming what's often called an orphaned resource. This avoids accidental deletions but means cluster cleanliness degrades over time unless someone manually cleans up orphaned resources.

prune: true in the sync policy makes Argo CD's reconciliation symmetric: anything present in the live cluster that Argo CD manages but that's NOT present in the current target Git revision gets deleted on the next sync. This keeps the cluster's actual state exactly matching Git, which is the more 'complete' GitOps promise, but it also means a mistake in Git — someone accidentally deleting a manifest file, a bad rebase/merge that drops a resource, a misconfigured Kustomize overlay that stops including something — now automatically deletes real running resources on the very next automated sync, potentially including things like PersistentVolumeClaims if not explicitly protected.

Because of this, teams often combine prune with additional safety nets: PrunePropagationPolicy to control cascade behavior, explicit preserveResourcesOnDeletion for stateful resources, requiring manual sync (not fully automated) for particularly sensitive Applications even if prune is enabled, and strong Git branch protection/review requirements specifically because a bad merge is now a production deletion risk, not just a drift risk.