How does Server-Side Apply detect and report field conflicts, and how do you resolve one?
Quick Answer
When you apply as one field manager but another manager already owns a field with a different value, the API server rejects the apply and names the conflicting field and its current owner. You resolve it deliberately: either drop the field from your manifest to yield ownership, or pass --force-conflicts to seize ownership.
Detailed Answer
Because ownership is tracked per field, the server can compare your desired value against the current owner value. If Helm applies a manifest setting .spec.replicas while kubectl already owns replicas with a different value, the server returns an Apply failed with conflict error that names .spec.replicas and the owner (kubectl). This is intentional friction — it forces a decision instead of a silent overwrite. Two clean resolutions: (1) yield — remove the field from your manifest so the current owner keeps it (common when an HPA should own replicas); (2) take ownership — re-run with --force-conflicts, which transfers the field to your manager and applies your value. Use force deliberately, after reading the conflict, not reflexively.
Code Example
kubectl apply --server-side --field-manager=helm -f deploy-5-replicas.yaml # error: Apply failed with 1 conflict: conflict with "kubectl": .spec.replicas # Take ownership on purpose: kubectl apply --server-side --field-manager=helm --force-conflicts -f deploy-5-replicas.yaml
Interview Tip
Explain both resolutions (yield vs --force-conflicts) and warn that forcing reflexively defeats the purpose of SSA. Nuance beats reciting the flag.