A school district public portal briefly went dark during an image change because every Pod was terminated before new ones started. Which Deployment strategy causes that downtime pattern?
Select an answer to reveal the explanation.
Short Explanation
Recreate is the all-stop-then-restart remodel: tear down every Pod first, then bring new ones up—so the portal can go dark in between. RollingUpdate is the usual HA choice when citizens need the site up during upgrades.
Full Explanation
A school district public portal that briefly went dark during an image change because every Pod was terminated before new ones started exhibits the Recreate Deployment strategy. Recreate terminates all existing Pods first, then creates Pods for the new template. That all-stop-then-restart pattern produces a deliberate capacity gap: while old Pods are gone and new Pods are not yet Ready, the Service has no backends and citizens see downtime—exactly the outage signature described.
RollingUpdate with a low maxUnavailable is the opposite pattern: it keeps most Pods up by limiting concurrent unavailability, so it does not cause an all-Pod blackout by design. A headless Service alone changes DNS to return Pod IPs; it is not a Deployment update strategy and does not itself replace Pods. HorizontalPodAutoscaler scale-up only adds replicas based on metrics; it does not implement an image-bump strategy that terminates every Pod before creating replacements.
Exam caveat: know strategy.type Recreate versus RollingUpdate and when Recreate’s downtime is unacceptable for citizen-facing portals. Operational check: if an unexpected full outage hits mid-image-change, inspect .spec.strategy on the Deployment; if Recreate is set, plan a move to RollingUpdate with appropriate maxUnavailable/maxSurge for the next release.