Library catalog search pods must be replaced gradually so some healthy instances always serve patrons. Which deployment pattern applies?
Select an answer to reveal the explanation.
Short Explanation
Rolling updates are the "swap a few catalog carts at a time so the aisle never empties" plan. Killing the whole fleet first leaves patrons staring at a dark search page.
Full Explanation
Rolling updates replace instances in batches so some healthy capacity keeps serving traffic throughout the deployment. Library catalog search pods that must be replaced gradually while patrons still get answers should use a rolling pattern: take a subset out, replace it, wait for readiness, then continue. That keeps the search aisle open instead of darkening the entire fleet first.
Shutting down the entire catalog fleet before starting any new pods fails by concept because it creates a full outage window—the opposite of gradual replacement with continuous capacity. Keeping a second full idle catalog stack forever without gradual replacement describes a blue-green-style dual stack, not a rolling update of the live pool. Overwriting the shared database schema only and never touching running pods fails because a rolling update is about instance replacement; a schema-only change does not roll search pods.
Exam caveat: rolling updates trade dual-environment cost for temporary mixed-version capacity, so instances must be compatible with the data plane during the roll. Do not confuse "rolling" with "blue-green idle twin" or with "schema migration without pod replacement" when the question asks which pattern replaces instances gradually.
Operational check: start a rolling update and watch pod counts—some old and new pods coexist while ready replicas stay above the minimum. Confirm search traffic continues during the roll and that a too-large batch size that drains capacity is rejected by policy.