When should a platform team adopt Server-Side Apply versus staying on classic client-side apply?
Quick Answer
Adopt SSA when multiple controllers or tools manage the same objects and you need the API server to track ownership and surface contested fields — for example Git plus an HPA plus Helm all touching one Deployment. For simple, single-writer objects, classic apply is perfectly fine; SSA is about coordinating many writers safely.
Detailed Answer
The decision is about how many writers share an object. If one manifest is the only thing that ever changes an object, client-side apply is simple and adequate. But as soon as several actors co-manage it — GitOps reconciling the template, an HPA owning replicas, admission webhooks defaulting fields, operators writing status — you want per-field ownership and loud conflicts, which is exactly what SSA provides. Practically, teams standardize on stable field-manager names, remove autoscaled/defaulted fields from Git so the right owner holds them, prefer apply over imperative edits to keep managedFields clean, and plan the Helm 4 migration. The payoff is that shared objects stop silently reverting and every change is attributable.
Code Example
# Rule of thumb # single writer -> classic apply is fine # many writers/object -> server-side apply (ownership + conflicts)
Interview Tip
Answer with the decision axis (number of writers per object), not a blanket "always use SSA" — architects reason about trade-offs.