Sync Waves & Hooks Interview Questions & Answers

Q: How do you retry a failed hook Job?

Configure the Job's own backoffLimit and restartPolicy for pod-level retries, and ArgoCD's sync retry (syncPolicy.retry) to re-run the operation. Combine with BeforeHookCreation so each retry starts a fresh Job rather than colliding with the failed one.

Q: Can hooks use sync waves to order among themselves?

Yes—hooks honor the sync-wave annotation within their phase, so multiple PreSync hooks can be ordered (e.g., provision in wave -2, migrate in wave -1). This gives fine control over multi-step preparation or teardown sequences inside a single sync.

Q: How do sync waves handle deletion order during pruning?

When pruning, ArgoCD reverses wave order—higher waves are deleted before lower ones—so dependents are removed before their dependencies (mirroring creation order). This prevents deleting a prerequisite while something still depends on it.

Q: What resource kinds make good hooks and why Jobs specifically?

Run-to-completion resources like Jobs are ideal because ArgoCD tracks their success/failure to gate the sync. Pods can work for simple tasks, but Jobs give retries, completions, and clean semantics for migrations, tests, and one-off tasks.

Q: How do you ensure a hook runs on every sync versus only on change?

Hooks run each time a sync applies them. To force a hook (like tests) to run every sync even without changes, ensure the resource differs (e.g., generateName or a changing annotation) or trigger a sync explicitly. For run-once semantics, use appropriate delete policies and stable naming.

Q: How do you notify an external system after a successful deployment using hooks?

Add a PostSync hook Job that calls the external system (webhook, deployment tracker, ChatOps). Because it runs only after resources are Healthy, it reliably signals a completed deployment. Alternatively, use the Notifications controller for event-driven alerts without a hook.

Q: What are pitfalls of overusing hooks and waves?

Too many waves/hooks slow syncs (each wave waits for health), complicate debugging, and can hide ordering assumptions. Long-running or flaky hooks stall deployments. Keep ordering minimal, make hooks fast and idempotent, and prefer proper readiness/health over artificial waits.

Q: What is the Sync phase (as opposed to PreSync/PostSync)?

The Sync phase is the main phase where the application's regular resources are applied. Sync-phase hooks run alongside these resources. PreSync runs before this phase and PostSync after it completes and is Healthy.

Q: How do you seed initial data on first deployment only?

Use a PreSync or Sync hook Job with BeforeHookCreation deletion and idempotent seeding logic, or gate it so re-runs are no-ops. Because hooks run each sync, the seed script itself should detect existing data and skip, giving effectively run-once behavior safely.

How do you retry a failed hook Job?

Advanced

Configure the Job's own backoffLimit and restartPolicy for pod-level retries, and ArgoCD's sync retry (syncPolicy.retry) to re-run the operation. Combine with BeforeHookCreation so each retry starts a fresh Job rather than colliding with the failed one.

spec:                     # Job spec
  backoffLimit: 3
  template:
    spec:
      restartPolicy: OnFailure

Real-world example A flaky migration hook retries three times at the pod level before the sync is considered failed.

Common follow-ups: What controls Job-level retries? | How does BeforeHookCreation help retries?

Applications Sync & Health Sync Waves & Hooks

Can hooks use sync waves to order among themselves?

Intermediate

Yes—hooks honor the sync-wave annotation within their phase, so multiple PreSync hooks can be ordered (e.g., provision in wave -2, migrate in wave -1). This gives fine control over multi-step preparation or teardown sequences inside a single sync.

metadata:
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/sync-wave: "-1"

Real-world example Provisioning runs in an earlier PreSync wave than the migration that depends on it.

Common follow-ups: Do hooks respect waves? | How do you order two PreSync hooks?

Applications Sync & Health Sync Waves & Hooks

How do sync waves handle deletion order during pruning?

Advanced

When pruning, ArgoCD reverses wave order—higher waves are deleted before lower ones—so dependents are removed before their dependencies (mirroring creation order). This prevents deleting a prerequisite while something still depends on it.

Real-world example On teardown, the frontend (wave 2) is pruned before the database (wave 1), the reverse of deployment order.

Common follow-ups: Why reverse order for deletion? | How does this protect dependencies?

Applications Sync & Health Sync Waves & Hooks

What resource kinds make good hooks and why Jobs specifically?

Beginner

Run-to-completion resources like Jobs are ideal because ArgoCD tracks their success/failure to gate the sync. Pods can work for simple tasks, but Jobs give retries, completions, and clean semantics for migrations, tests, and one-off tasks.

Real-world example Migrations and smoke tests are Jobs so ArgoCD can wait for completion and detect failure.

Common follow-ups: Why not use a Deployment as a hook? | What do Jobs provide over bare Pods?

Applications Sync & Health Sync Waves & Hooks

How do you ensure a hook runs on every sync versus only on change?

Advanced

Hooks run each time a sync applies them. To force a hook (like tests) to run every sync even without changes, ensure the resource differs (e.g., generateName or a changing annotation) or trigger a sync explicitly. For run-once semantics, use appropriate delete policies and stable naming.

metadata:
  generateName: smoke-test-

Real-world example Using generateName makes a fresh smoke-test Job on every sync rather than skipping an unchanged one.

Common follow-ups: How do you force a hook to rerun? | What gives run-once behavior?

Applications Sync & Health Sync Waves & Hooks

How do you notify an external system after a successful deployment using hooks?

Intermediate

Add a PostSync hook Job that calls the external system (webhook, deployment tracker, ChatOps). Because it runs only after resources are Healthy, it reliably signals a completed deployment. Alternatively, use the Notifications controller for event-driven alerts without a hook.

metadata:
  annotations:
    argocd.argoproj.io/hook: PostSync

Real-world example A PostSync hook posts a 'deployed' event to the release dashboard once the app is healthy.

Common follow-ups: Hook vs Notifications controller for alerts? | Why PostSync for deployment notifications?

Sync & Health Applications Sync Waves & Hooks

What are pitfalls of overusing hooks and waves?

Advanced

Too many waves/hooks slow syncs (each wave waits for health), complicate debugging, and can hide ordering assumptions. Long-running or flaky hooks stall deployments. Keep ordering minimal, make hooks fast and idempotent, and prefer proper readiness/health over artificial waits.

Real-world example A team collapses excessive waves after syncs became slow, keeping only the essential CRD-before-workload ordering.

Common follow-ups: Why can many waves slow syncs? | How do you keep hooks reliable?

Applications Sync & Health Sync Waves & Hooks

What is the Sync phase (as opposed to PreSync/PostSync)?

Beginner

The Sync phase is the main phase where the application's regular resources are applied. Sync-phase hooks run alongside these resources. PreSync runs before this phase and PostSync after it completes and is Healthy.

Real-world example The Deployment and Service apply during the Sync phase, between the PreSync migration and PostSync tests.

Common follow-ups: What runs in the Sync phase? | How does it relate to Pre/PostSync?

Applications Sync & Health Sync Waves & Hooks

How do you seed initial data on first deployment only?

Intermediate

Use a PreSync or Sync hook Job with BeforeHookCreation deletion and idempotent seeding logic, or gate it so re-runs are no-ops. Because hooks run each sync, the seed script itself should detect existing data and skip, giving effectively run-once behavior safely.

metadata:
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded

Real-world example A seed Job checks whether the table is populated and exits early on subsequent syncs.

Common follow-ups: How do you make seeding idempotent? | Why can't you assume run-once?

Applications Sync & Health Sync Waves & Hooks