Articles

Argo CD Interview Questions: Sync Policies, Drift, and Stalled Waves

Practice Argo CD interview questions with automated sync, self-healing, pruning, application health, and a stalled-wave case with explicit evidence boundaries.

An Argo CD interview question often combines three different signals: an application is out of sync, a workload is unhealthy, and a later wave has not started. A useful answer separates those observations before changing configuration. Sync policy controls reconciliation; health describes resource condition; ordering determines what can proceed within a sync operation.

Start with the desired revision, the live difference, and the first blocking resource. A successful CI build does not establish any of those outcomes, and changing a wave number does not repair a failing workload.

This guide follows Argo CD release-3.3 documentation. The configurations and incident cards are original practice scenarios, not candidate reports. We checked a simplified local Python model of policy choices and wave selection. We did not install Argo CD or run a Kubernetes cluster; expected controller behavior below is document-based, not a platform test result.

How Sync Status Differs from Application Health

Official context: Argo CD evaluates resource health separately from desired-versus-live comparison. Built-in health checks use resource-specific conditions, and custom checks can change how health is assessed. Read the applicable resource check instead of treating one green indicator as universal proof. Resource health documentation

Practice question: a Deployment matches the desired manifest, but its containers cannot start. Is “Synced and unhealthy” contradictory?

No. Matching the intended specification does not make that specification operationally successful. A bad image reference can be faithfully applied. The next investigation concerns the workload and its events, while the sync comparison may already be satisfied.

Now reverse the situation. Someone changes a live replica setting, and the running application remains healthy. The live resource can differ from desired state without immediately failing its health check. First decide whether the change was intentional and which controller owns that field.

In an interview, describe both axes explicitly. “Desired and live match, but readiness has not been reached” is more actionable than “Argo is broken.” Attach the revision and observation time so the interviewer knows you are not comparing a current health result with an earlier sync attempt.

Read Three Sync-Policy Counterexamples

These snippets show only an Application's policy section. They are not complete installable Application manifests. Assume the source can be read, the target is reachable, and no unrelated constraint blocks the operation. The exercise isolates the policy distinction rather than predicting every controller decision.

Case One: Self-Healing Is Set, but Automation Is Disabled

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

Official rule: an explicit enabled: false disables automated sync even when the other automated fields are set. Automated sync policy

Practice answer: do not read selfHeal: true in isolation. Inspect the parent activation setting before expecting a live edit to be repaired automatically. The counterexample is designed to expose the difference between a configured option and an active policy.

Changing only enabled to true removes that particular gate. It does not prove that every other prerequisite for reconciliation is satisfied. In a real incident, record whether the policy was intentionally disabled before re-enabling it; the setting may be part of containment work.

Case Two: Healing Does Not Imply Automatic Deletion

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

A teammate removes one managed ConfigMap from Git and expects it to disappear automatically. The remaining desired resource set is nonempty.

Official field distinction: self-healing and pruning are separate options. This policy does not enable automatic pruning merely because healing is enabled. Application specification

Practice answer: establish whether the resource was deliberately removed, whether it is tracked by this application, and whether automatic deletion is intended. Changing prune to true changes that permission; it is not just a cosmetic way to clear an out-of-sync indicator.

Explain the consequence in terms of the resource, not the dashboard color. If another workload still depends on the ConfigMap, the important question is whether the removal is correct. A reconciliation tool cannot substitute for understanding that dependency.

Case Three: Pruning Is Enabled, but the Desired Set Is Empty

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

Official rule: automated pruning has an empty-application safeguard; allowEmpty controls permitting an empty desired resource set. Automated sync policy

Practice answer: first investigate why the desired set is empty. Did the intended change remove every resource, or did a source path, revision, or generator input change unexpectedly? Enabling allowEmpty without answering that question can authorize the wrong outcome.

For this exercise, changing only allowEmpty to true removes the empty-set safeguard. It does not turn a source error into a valid desired configuration or establish that deletion is appropriate.

The three cases can be compared without treating any result as a live observation:

Original practice case	Single-field change and expected policy effect
Automation explicitly disabled	Enable it to remove the activation gate.
Healing enabled, pruning disabled	Enable pruning to permit automatic removal of eligible missing resources.
Empty desired set protected	Enable allow-empty only when an empty result is intentional.

What the Local Model Verified

The local Python model represented only these policy gates. It returned false for healing when automation was explicitly disabled, false for pruning when only healing was enabled, false for an empty-set prune with protection retained, and true when that protection was explicitly removed.

Observed result: all four model assertions passed. This checks the consistency of the practice exercise, not Argo CD's implementation. The model does not fetch Git, compare Kubernetes objects, evaluate sync windows, process permissions, or execute a deletion.

That distinction is itself useful interview preparation. When presenting a test, say what behavior it exercised and what remains inferred from documentation. A tiny model can help explain a rule while still being insufficient evidence for production behavior.

For a real deployment investigation, retain the effective Application configuration alongside the expected policy outcome. If the observed controller result differs, inspect the omitted conditions before declaring the documented rule incorrect.

Why a Sync Wave Stops Progressing

Official ordering: Argo CD orders by phase, wave, resource kind, and name. Waves use integer annotations, including negative values. Progress depends on the first wave containing an out-of-sync or unhealthy resource, so an unhealthy earlier wave can prevent later work from proceeding. Sync phases and waves

Consider this invented Sync-phase incident card:

Desired revision: demo-r42
wave -1  ConfigMap/settings   Synced  Healthy
wave  0  Deployment/api       Synced  Progressing
wave  1  Deployment/worker    OutOfSync  not yet applied
Evidence: api Pod events report an unavailable image tag

The statuses and event summary are supplied scenario evidence, not screenshots or logs collected from a real cluster. Both Deployments are ordinary Sync-phase resources in this example.

Question: should you move the worker to wave -2 so it starts?

Not before understanding the dependency. The first unresolved stage is the API Deployment in wave 0. Inspect its image reference and the event details that support the unavailable-tag hypothesis. Confirm whether the intended artifact exists and whether the configured reference matches it.

If the reference is wrong, repair the desired configuration or restore a compatible known revision through the agreed workflow. Then verify that the API becomes healthy and that the later wave proceeds. Merely moving the worker earlier can bypass an intended ordering constraint while leaving the original defect intact.

The local model selected wave 0 before the simulated health repair and wave 1 afterward. These two assertions passed, but they do not reproduce controller timing, watches, hooks, or Kubernetes health evaluation.

Distinguish an Ordering Problem from a Dependency Problem

An interview may change the incident: the API waits for the worker, while the worker is deliberately placed after the API becomes healthy. Now the ordering encodes a circular readiness dependency.

Editorial diagnosis: draw the actual startup requirements. Ask whether the API truly needs a ready worker to become healthy, whether the health check is too broad, or whether the deployment structure should change. Increasing a timeout cannot resolve a dependency that never becomes satisfiable.

Avoid changing health criteria solely to obtain a green status. A narrower readiness condition may be correct, but justify it using the service's real ability to receive traffic. Otherwise, the change merely hides a failed prerequisite.

Also distinguish phases from wave numbers. A negative wave number is not a universal instruction to run before every possible phase. State the phase and resource role when explaining order, especially if a migration or other hook is involved.

If deletion is part of the incident, inspect the actual prune options and operation results rather than assuming creation order describes every deletion decision. The documented PruneLast option places pruning in an implicit final wave after other resources are deployed and healthy. Sync options

The purpose of this reasoning is to preserve the intended dependency while identifying the smallest change that permits safe progress. A different integer is not an explanation unless you can defend the new order.

Why a Manual Policy Edit May Not Persist

Official management boundary: ApplicationSet can reconcile generated Applications back to its template. Its documentation provides controls for ignored Application differences, including temporarily allowing sync-policy changes. Inspect the parent management configuration when a child Application edit is overwritten. ApplicationSet resource modification

Practice scenario: you disable automated sync on a generated Application during an incident, then see the old setting return. Do not assume a teammate secretly reverted your work. Identify the owning controller and the desired configuration it applies.

A durable repair should be made at the appropriate source of ownership, or through a documented temporary exception. Record the exception's purpose and how normal reconciliation will be restored. Otherwise, the incident can end with an undocumented policy gap.

This is different from a workload's self-healing setting. One question concerns who manages the Application object; another concerns how that Application reconciles its child resources. Keeping those layers separate prevents a long, confusing argument about why a checkbox “does not work.”

Present a Focused Recovery Update

A useful status update names the desired revision, the first unresolved resource, the evidence for its failure, and the next check. For the stalled-wave case: “The API manifest is applied, but its image cannot start; later resources remain pending behind wave 0. We are correcting the image reference and will check health before confirming later-wave progress.”

Do not report recovery solely because Git contains the fix. Verify that the intended revision was observed, that the relevant live resource changed, and that the health condition improved. Then check the dependent workload and a meaningful application behavior.

Keep uncertainty specific. If you have not inspected the controller's operation result, say that rather than implying the whole system is unexplained. A bounded unknown gives the next engineer a concrete investigation step.

Practice the Related Engineering Decisions

Practice question	Apply it to this article
Design a Dependency-Aware CI/CD Pipeline	Explain the prerequisites between deployment stages.
Implement Kubernetes Service Dependency Queries	Identify which service actually blocks another.
Execute Dependency-Constrained Work at Scale	Separate ordering from successful completion.
Dependency-Safe Deletion Order	Reason about removal without assuming creation and deletion are identical.
Mitigate an Emergency During On-Call	Communicate containment, repair, and verification.

Start with the dependency-aware pipeline exercise, then explain all three policy cases without reading the answers. A strong explanation links a specific setting or resource condition to the next observable action.