A city API Deployment cannot drop capacity during updates. The rollingUpdate strategy sets maxUnavailable to 0 and maxSurge to 1. What behavior should the candidate expect?
Select an answer to reveal the explanation.
Short Explanation
Think of a bridge that must stay open while workers swap planks—you add one temporary plank before you remove any. With maxUnavailable 0 and maxSurge 1, the cluster surges by one Pod first and only drains an old Pod after the new one is Ready, so serving capacity never dips below the target.
Full Explanation
For a city API Deployment that must not lose serving capacity during updates, RollingUpdate with maxUnavailable 0 and maxSurge 1 implements a surge-first pattern. Kubernetes may temporarily create one Pod above .spec.replicas so a new replica can become Ready before any old Pod is terminated. Because maxUnavailable forbids dropping Ready capacity below the desired count, the controller only drains an old Pod after the surged replacement is available. Municipal APIs that back 311 or permitting therefore keep at least the target replica count Ready throughout the rollout, trading a small temporary over-capacity cost for uninterrupted civic traffic.
Why the other options fail by concept: Immediately terminating all old Pods and accepting a zero-capacity window describes Recreate (or a reckless maxUnavailable equal to all replicas), not this surge-only RollingUpdate. Claiming maxUnavailable 0 permanently blocks every rollout misunderstands the field—progress continues via maxSurge creating Ready Pods first. Asserting that maxSurge 1 forces Recreate confuses a RollingUpdate tuning knob with the strategy type itself; the strategy remains RollingUpdate.
Exam caveat: Percentages and absolute counts both work for maxSurge/maxUnavailable; 0 and 1 here are absolute. If new Pods never become Ready (bad image, failed probes, scheduling pressure), the surge Pod sits unavailable and the rollout stalls even though capacity never intentionally dipped—watch progressDeadlineSeconds. Also remember “available” for Deployment progress ties to readiness and minReadySeconds, not merely Running.
Operational check: After applying the strategy, run kubectl rollout status on the city API Deployment and watch kubectl get pods -l <selector> during the update. Confirm peak Pod count reaches replicas+1 and Ready count never falls below .spec.replicas. If Ready dips, re-check the rollingUpdate fields, readiness probes, and whether another change (for example a mistaken Recreate strategy) overrode the intended surge-only settings.