Argo CD / Desired state and evidence foundations / Lesson 6

Reviewing a sync before authorizing adoption

Examine resolved inputs, resource identities, operation options, and verification without executing a sync.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Build a resource-change review plan from declared desired and observed sets.
Explain why a preview cannot guarantee every admission and runtime outcome.

A sync is an authorized state-changing decision

A manual sync asks Argo CD to act on a selected desired state under configured policy and permissions. The review should identify the Application, resolved source and render inputs, destination, resources, operation options, and decision authority. Parcel’s request must not change to another latest revision while a reviewer believes they are approving known bytes. A UI button is a convenient interface to this decision, not its complete safety model. This course neither invokes a CLI sync nor sends an API request.

Review additions, modifications, and removals separately

A desired set can introduce new resource identities, change fields on existing identities, or omit previously tracked objects. Omission is not automatically approved deletion. Pruning, deletion propagation, finalizers, ownership, and target state affect what removal means. Existing updates may also be disruptive if immutable fields or replace behavior are involved. Read the full group-kind-namespace-name identity and relevant field changes. A short diff summary can hide a namespace switch or renamed resource that is actually a create-and-remove transition.

Calculate a synthetic identity-set plan

The complete local model below identifies a new Service and an obsolete ConfigMap from declared sets. It performs no Kubernetes discovery or mutation and does not decide whether the obsolete resource should be pruned. The update intersection merely identifies shared identities, not whether their fields differ. A real plan must compare relevant desired and observed fields and account for normalization, ownership, admission, and policy. This separation prevents a useful set calculation from being mistaken for a complete deployment preview.

python A local synthetic resource-set review

desired = {("apps", "Deployment", "parcel-lab", "parcel"), ("", "Service", "parcel-lab", "parcel")}
observed = {("apps", "Deployment", "parcel-lab", "parcel"), ("", "ConfigMap", "parcel-lab", "old-settings")}
print(sorted(desired - observed))
print(sorted(observed - desired))
print("removal candidates require a separate decision")

Expected output

[('', 'Service', 'parcel-lab', 'parcel')]
[('', 'ConfigMap', 'parcel-lab', 'old-settings')]
removal candidates require a separate decision

Only tuple sets are evaluated. No resource is created, updated, deleted, queried, or authorized. The output is not Argo CD’s actual sync plan.

Preview evidence has limits

A diff or dry-run-style review can expose intended changes without proving final admission or runtime health. The cluster can change between observation and apply, admission can mutate resources, and dependencies can fail after acceptance. A preview is still valuable when its revision and scope are clear. Record limitations and choose bounded verification. Do not claim that a no-error preview establishes a database migration’s reversibility or an external side effect’s idempotency. Those need application-specific contracts and compatible recovery material.

Retain the decision and completion criteria

The JSON record below is a synthetic editorial review plan rather than an Argo CD operation schema. It states that removal remains unapproved and that observed identity plus a user check are needed after adoption. A real decision needs authenticated authority and target evidence. Preserve the operation record and partial outcomes if sync fails; a failed client view does not imply no resources changed. Repeating the entire operation can repeat hooks or other side effects, so inspect the incomplete boundary before choosing recovery.

json A synthetic sync review record

{"application":"parcel-lab","revision":"lab-r6","target":"parcel-lab-cluster","removal_decision":"not-approved","completion":["observed-resource-identity","bounded-user-check"]}

This is not a live request, approval, endpoint, or complete release policy. No sync or verification operation is performed, and the target label identifies no real cluster.

Common errors and fixes

A reviewer approves a moving latest selection instead of a resolved candidate.

Why it happens: The decision is not bound to the inputs actually adopted.
How to fix it: Resolve and retain the intended source and rendering identity before approval.
Prevent it next time: Reevaluate material changes during waiting.

An omitted resource is deleted without an ownership review.

Why it happens: Set difference was treated as automatic pruning authorization.
How to fix it: Review tracking, ownership, deletion effects, and policy separately.
Prevent it next time: Keep removal decisions explicit in sync plans.

A successful preview is described as guaranteed healthy adoption.

Why it happens: Pre-apply evidence was stretched into admission and runtime outcomes.
How to fix it: Verify accepted state, observed identity, health, and relevant user behavior.
Prevent it next time: Document preview assumptions and race limits.

Check your understanding

1. A Deployment keeps its name but moves to another namespace. Is that merely a field update to the same identity?

Show worked solution

No. Namespace participates in namespaced resource identity. Review the new identity and the old resource’s lifecycle separately, including ownership and pruning. A name-only summary can hide a significant transition.

2. A sync fails after one resource changes. Should the reviewer assume the target is untouched?