Context
GitOps makes configuration changes repeatable, but repeatability does not make every change reversible. A resource removed from Git may be deleted from the cluster when pruning is enabled. A manual emergency edit may be restored to the Git version when self-healing is enabled. These are powerful behaviours that need an explicit operating contract.
Consider an illustrative application repository where a refactor accidentally removes a resource manifest. The next synchronization deletes the live object. Reverting the commit restores the manifest, but it may not restore data that was removed with the original resource. The important review begins with resource lifecycle and data ownership, not only the Git diff.
Separate the automation switches
Argo CD documents automated sync, automatic pruning, allow-empty behaviour, and self-healing as related but distinct controls. Their defaults and interactions determine whether differences are applied, removed resources are pruned, and live changes are reconciled. Current documentation also describes restrictions and timing around automatic synchronization and rollback. 1
Record the actual Application policy and any higher-level controller managing it. An ApplicationSet or other source can restore settings that an operator changed manually. The recovery procedure must name the authoritative configuration, not only the UI switch visible during the incident.
Classify resources by consequence
List stateless workloads, persistent claims, secrets, external-resource controllers, and shared cluster components separately in the internal review. For each, identify what deletion means and whether recreating the manifest recreates the original state. A Deployment and a database resource managed by an operator can have very different consequences.
Inspect ownership and finalization behaviour for stateful or external resources. A Kubernetes object can trigger changes outside the cluster through a controller. Do not assume that deleting the object only removes a harmless API record. Keep the application's backup and restore procedure connected to those resource lifecycles.
Review the rendered change, not just source files
Charts, overlays, conditionals, and values can produce a large difference from a small source edit. Inspect the rendered target set and the proposed live diff. A renamed resource may appear as one deletion plus one creation rather than a harmless in-place rename.
Check that the application still renders the expected population before enabling any empty-target behaviour. An empty result can be an intentional retirement or a template failure. The operating procedure should make that distinction visible instead of treating every empty render as an instruction to remove the application.
Give emergency edits a reconciliation path
When self-heal is enabled, a live hotfix may be reverted automatically. Decide how an authorized emergency change is paused, applied, recorded in Git, and returned to normal reconciliation. Keep this workflow short enough to use during an incident but explicit enough to avoid competing controllers.
Do not leave automation disabled indefinitely because one incident needed a manual edit. Record an owner and a restoration checkpoint. Compare the final live state with the approved repository state before resuming. Otherwise the next sync can undo the recovery or reintroduce the original failure unexpectedly.
Treat database migrations as a separate state transition
A Git revert can restore an older application image while the database remains on a newer schema. Migration jobs may also run again during reconciliation or recovery, depending on their design. Make migrations idempotent where appropriate and track their actual completion independently of a sync status.
Use a compatibility strategy that supports the intended rollout and rollback window. Additive schema changes and later cleanup may be safer than immediately removing fields an older release still needs. The right plan depends on the application, but the evidence must show that the old and new components can coexist for the required interval.
Test deletion and restoration in a safe environment
Use a representative nonproduction application to remove a stateless resource, introduce a live edit, and exercise the intended recovery process. For stateful resources, test the documented backup and restore path with isolated data rather than casually deleting production storage to see what happens.
Observe which controller performs each action and how long reconciliation takes. Record the resulting resource identities and data state. A restored object with a new identity may have different relationships or credentials, so validate the application rather than declaring success when the resource count returns to its original number.
Make promotion evidence understandable
Before enabling broader automation, retain the reviewed rendered diff, selected policies, resource lifecycle notes, and recovery exercise results. Define which changes require a separate approval because of their consequence within the organization's process. Do not invent extra gates for routine harmless edits, but do make destructive lifecycle changes visible.
An illustrative acceptance check should show that a normal image update synchronizes successfully, an emergency live change follows the documented path, and a deliberately removed stateful definition does not surprise the data owner. These are different behaviours and deserve distinct evidence.
A focused operator exercise: A rendered-deletion review example
In a nonproduction application, rename a harmless resource in the configuration source and inspect the rendered diff before synchronization. Verify the review identifies the old object's deletion and the new object's creation. Then apply the change through the documented policy and confirm the resulting application state.
Use a separate stateful test resource to review deletion consequences without removing important data. Record whether recreation restores only an API object or also the underlying information the application needs. This comparison gives the team a practical example of why a Git revert and a data restore are different recovery actions, even when both begin from a familiar repository revision.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Rendered difference | Review resources to create, change and delete | Identify data-bearing objects |
| Reconciliation policy | Understand prune and self-heal triggers | Gate stateful transitions deliberately |
| Recovery sequence | Rehearse the application and data path | Avoid assuming Git revert restores data |
Frequently asked questions
Does reverting Git restore all application state? No. Data changes, external side effects, and resource deletion can require separate recovery.
Clouvenix can review Argo CD policy alongside application data lifecycle, helping teams automate routine convergence while keeping deletion and recovery consequences concrete.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.