Argo CD / Automation, lifecycle, and trust / Lesson 7

Automated sync, pruning, and self-healing

Treat source-driven adoption, resource removal, live-drift correction, and empty output as separate policy choices.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain the release-3.1 automated.enabled field and related settings.
Assess deletion and live-change behavior before enabling automation.

Automation changes who initiates a sync

Automated sync lets the controller initiate eligible adoption when desired and observed state differ under documented semantics, reducing the need for a separate pipeline to call the deployment API. That does not eliminate source review, permission boundaries, verification, or recovery. Parcel’s source repository becomes part of the authorization path because accepted changes can lead to target mutations. Read the actual policy and release behavior rather than equating any automated block with unrestricted continuous deployment. Generation or comparison errors are not repaired simply by enabling automatic action.

Read enabled explicitly for this baseline

The release-3.1 documentation supports automated.enabled to explicitly turn automated sync on or off. A null value is treated as enabled in that documented model, while false disables automated sync even if related flags are set. The fragment below intentionally disables all displayed choices and is not applied. Omitting a field and explicitly setting false can therefore communicate different intent depending on schema and controller version. Check installed support before translating a learning example into configuration; this course makes no current-version or support-lifecycle claim.

yaml An explicitly inactive automated-policy fragment

spec:
  syncPolicy:
    automated:
      enabled: false
      prune: false
      selfHeal: false
      allowEmpty: false

This is not a complete Application and is never submitted. It illustrates release-3.1 field semantics, not the effective policy of an existing controller or an ApplicationSet-managed child.

Deletion needs its own ownership decision

Automated pruning permits removal of resources no longer represented in the desired set under tracking and policy. It is not the same as updating an existing field. Empty-output protection and allowEmpty address another boundary: accidental generation of no target resources can otherwise interact with removal. Review rename, path change, source loss, shared ownership, finalizers, and durable data implications before approving deletion behavior. A valid empty set may be intentional during retirement, but it needs an explicit lifecycle decision rather than a blanket flag chosen to silence an error.

Live-drift correction is another choice

Self-healing can trigger correction when live state deviates from the declared state under documented conditions. That can reverse an emergency manual edit unless the source and policy are reconciled through the owner’s process. Disabling one self-heal flag is not a universal guarantee that another source change or multi-source sync cannot reapply the desired field. Review all triggering paths. Automated retry and deduplication semantics also depend on revision and parameters, so do not expect every repeated observation to create another identical sync indefinitely.

Show capability choices without emulating scheduling

The complete local model below derives three allowed policy capabilities from declared booleans. It does not decide whether Argo CD will schedule a particular operation, model history, retry delays, ApplicationSet inheritance, or inspect a cluster. It shows the narrower point that enabling source adoption need not enable removal or live-drift correction. Real policy review must include the effective Application, its owner, generated configuration, project restrictions, target authority, and evidence required after any automatic action.

python A synthetic automation-capability model

def capabilities(enabled, prune, self_heal):
    return {"source_adoption": enabled, "removal": enabled and prune, "live_correction": enabled and self_heal}
result = capabilities(True, False, False)
for key in ["source_adoption", "removal", "live_correction"]:
    print(key, result[key])

Expected output

source_adoption True
removal False
live_correction False

Only boolean logic is evaluated. The result is not an Argo CD scheduling prediction or an authorization grant.

Common errors and fixes

Automated adoption is assumed to enable safe deletion automatically.

Why it happens: Update, removal, and empty-output boundaries were conflated.
How to fix it: Review prune and allowEmpty separately with ownership and recovery evidence.
Prevent it next time: Document each automation choice and retirement case.

A manual emergency edit is assumed durable despite live reconciliation.

Why it happens: Runtime intervention was not reconciled with desired source and effective policy.
How to fix it: Coordinate the incident change and source correction through the owner.
Prevent it next time: Rehearse drift and emergency-change behavior before relying on it.

A child Application’s automation field is edited without considering its ApplicationSet owner.

Why it happens: Generated configuration is treated as independently authoritative.
How to fix it: Review the generating template and supported override behavior.
Prevent it next time: Record which controller owns each policy input.

Check your understanding

1. The policy enables source adoption but leaves prune false. Does a desired resource omission necessarily authorize automatic deletion?

Show worked solution

No. Removal has its own effective policy and ownership semantics. Review the actual target and tracking state and do not infer deletion permission from source-sync automation alone. The local capability model illustrates that separation without performing it.

2. Why is allowEmpty not a general fix for a broken source path?