Kubernetes Rollout Interview Questions: Surge, Readiness, and Safe Rollback

Your Deployment has three replicas. A new version is rolling out, one new Pod is Running but unready, and users see intermittent failures. Should you raise maxSurge, wait, or run kubectl rollout undo? A useful Kubernetes rollout interview answer starts with which Pods are Ready and receiving traffic, how much spare capacity exists, and what the release changed outside the Pod template. A rollback is a tool, not a guarantee that every side effect is reversed.

The Kubernetes mechanics below are supported by official documentation. The times, replica counts, and database migration are original interview exercises, not reports of a specific company's questions. If you want an adjacent prompt, practice Explain CI/CD, Kubernetes delivery, and troubleshooting.

What a Deployment rolling update actually controls

For a Deployment using RollingUpdate, maxSurge is the maximum number of Pods above the desired count that the controller may create during the update. maxUnavailable is the maximum number of desired Pods that may be unavailable during it. Both can be counts or percentages. Kubernetes rounds surge percentages up and unavailable percentages down. The default values are 25% each if not specified. For three replicas, those defaults produce a one-Pod surge and zero unavailable under the documented rounding rules. Confirm the admitted strategy rather than reciting a generic one-quarter effect.

The Deployment guide also describes progress deadlines, status conditions, and terminating Pods. A terminating Pod can continue using resources during its grace period, so the physical Pod count can temporarily exceed the intuitive replicas + maxSurge arithmetic. Capacity planning must account for that overlap. The rollout controller's unavailable count is based on Deployment availability semantics, which include readiness and any minReadySeconds setting. A Pod being Running does not mean it is eligible for service traffic.

The most important boundary: rolling update settings govern the controller's replacement sequence. They do not validate application correctness, perform a database rollback, or prove that requests drain gracefully. Readiness can be configured badly, and a new version can return wrong answers while passing a probe. A strong interview answer connects controller status to real service telemetry.

Interview question 1: Calculate a three-replica rollout

Assume three old Pods are Ready. The Deployment uses maxSurge: 1 and maxUnavailable: 0. The controller can create one new Pod, bringing the in-progress count to four. It should not make an old Pod unavailable until enough new capacity satisfies the availability requirement. If the new Pod is Pending because the cluster cannot fit a fourth Pod, the rollout can stall while all three old Pods keep serving. If it starts but fails readiness, the same protective constraint can stop replacement progress.

Now change maxUnavailable to one. The controller has permission to reduce available desired Pods by one during rollout. That may free capacity for an otherwise unschedulable replacement, but it also lowers the minimum serving replica count during the change. Whether two replicas can safely carry traffic is an application and load question. “Change maxUnavailable to one” is not a universal fix for insufficient cluster headroom.

For a larger replica count, compute the percentage rounding explicitly. At seven replicas with default 25%, surge rounds up to two and unavailable rounds down to one. Do the arithmetic before arguing about safety. Also distinguish configured capacity from actual readiness: if two old Pods are already unhealthy, the rollout may be constrained in a way the simple steady-state calculation did not anticipate.

An original stalled-rollout timeline

Consider a checkout API at 14:00 with three healthy replicas. At 14:02, version B creates a surge Pod. The new Pod is Running but fails its readiness probe because it cannot connect to a newly required database column. At 14:05, the deployment has not progressed and users may still be served by version A. The release also ran an irreversible data rewrite before the Pod update. What should the on-call engineer do?

Observation	Meaning	Safe decision to consider
Three old Ready Pods, one new unready Pod	maxSurge: 1 is consumed; replacement has not earned availability	Inspect new Pod logs, readiness failure, and DB compatibility
Progressing=False with ProgressDeadlineExceeded	Controller did not meet the configured progress deadline	Treat as a failed rollout signal, not automatic rollback proof
Old Pods still return traffic	The rollout strategy preserved a serving floor	Avoid deleting healthy old Pods just to force progress
DB rewrite is already applied	Pod template rollback cannot undo the data change	Assess whether version A can read the changed schema before undo

This table is an illustrative inference from Deployment behavior. In a real incident, compare the new and old Pod versions, EndpointSlice readiness, error rate, and database state. If version A cannot read the rewritten data, undoing the Deployment might worsen the outage. The correct repair could be a forward-compatible hotfix, a controlled data restoration, or a carefully planned revert—not a reflexive command.

Interview question 2: Why does Running not mean ready to receive traffic?

The kubelet can run a container before the application has initialized dependencies or can handle requests. A readiness probe tells Kubernetes whether to include the Pod in normal Service endpoints. A failing readiness probe keeps a running container out of that traffic path. A liveness probe answers a different question: whether to restart the container. Misusing liveness for slow startup can create restart loops; misusing readiness as a shallow process check can send traffic to a broken version. The probe configuration guide describes these roles.

In an interview, ask what the readiness endpoint actually tests. If it checks only that the HTTP server is listening, a version with failed DB access may become Ready and receive real traffic. If it hard-depends on an optional downstream service, an otherwise useful replica may stay unready and block the rollout. The right probe represents whether this Pod can serve its contract, with timeouts and failure thresholds appropriate to startup and transient failures.

minReadySeconds adds another guard: a newly Ready Pod must stay Ready for the configured duration before it counts as available to the Deployment. This can catch rapid flapping. It does not detect semantic errors that the probe misses. Compare rollout availability with service error rate and latency during the update.

Interview question 3: What does ProgressDeadlineExceeded tell you?

It tells you the Deployment failed to make progress within its configured deadline. It does not by itself tell you whether the cause is image pull, unschedulable surge capacity, crash loop, failing readiness, a blocked volume, or an application defect. Kubernetes reports a status condition; it does not automatically repair the release. Read kubectl describe deployment, ReplicaSet and Pod events, rollout status, and logs. Identify the first new Pod's lifecycle stage and compare it with the old version.

If the new Pod is Pending, inspect scheduling events and capacity. If it is ImagePullBackOff, fix image access or tag. If it is Running but unready, inspect readiness and dependencies. If it becomes Ready while users still fail, investigate application behavior and traffic distribution. The sequence matters because it selects the smallest safe correction; “increase the deadline” only changes when the controller reports a problem and can hide a real defect.

In a live release, pause or stop further changes while gathering evidence. Capture the image digest or exact release revision so a purported rollback does not accidentally deploy another mutable tag. State who owns the release and how users are affected. Interviewers often value that operational discipline as much as command recall.

Interview question 4: Is kubectl rollout undo a safe rollback?

It restores a previous Deployment revision's Pod template when the revision is available. This is useful for reverting a bad container image or Pod-level configuration. It does not reverse a database migration, delete a message already published, refund a charge, restore an altered external service, or undo an incompatible data rewrite. It also cannot guarantee old Pods remain compatible with the current world.

Before undoing, answer three questions. First, what changed outside Kubernetes? Second, can the old version still run against the current schema and data? Third, does returning the old Pod template actually address the observed failure? If the answer is yes, execute the rollback and monitor until the old version is Ready and service metrics recover. If the answer is no or unknown, prefer a contained forward fix or a separately planned data restoration, with the relevant owner involved.

Design releases for reversibility ahead of time. An expand-and-contract database migration can add a new field in a backward-compatible phase, deploy code that can read both states, backfill safely, and only later remove old behavior. That is an engineering pattern, not a Kubernetes guarantee. It makes a Pod-template rollback more likely to work because old and new versions coexist during a controlled transition.

Interview question 5: What would you set for surge and unavailable capacity?

Start from the minimum serving capacity established by load testing and the spare resources in every eligible node pool or zone. If three of three replicas are needed at peak, maxUnavailable: 0 protects the controller's planned replacement floor, but you need room for at least the allowed surge and terminating-Pod overlap. If the cluster cannot fit surge, pre-provision eligible capacity or schedule the update at lower demand; a zero-unavailable setting by itself can leave the rollout stuck. If two replicas safely handle peak with headroom, maxUnavailable: 1 might be acceptable, subject to fault-domain and concurrent-disruption analysis.

Coordinate with PodDisruptionBudgets and node maintenance. Deployment rolling updates are governed by their strategy, while drains use the Eviction API and PDB. A rollout can reduce healthy Pods and thereby leave no PDB allowance for a concurrent drain. Do not stack a rollout, node upgrade, and autoscaler scale-down without checking their combined serving capacity. Where traffic is sensitive to startup or termination, use suitable readiness, startup, and graceful termination behavior and verify connection draining in the actual proxy path.

State the desired failure tolerance. If a single-zone outage must be tolerated mid-rollout, the capacity calculation should include that condition, not merely steady-state replica count. An interviewer is looking for a defended availability budget, not a magic 25% copied from an example.

A concise answer for the whiteboard

“With three replicas, maxSurge: 1 and maxUnavailable: 0, the controller can start a fourth Pod but cannot intentionally drop below three available replicas during replacement. I would check whether the new Pod is Pending, crashing, or failing readiness, then correlate rollout conditions with actual error rate. Before rollout undo, I would identify DB and external side effects and confirm the old version remains compatible. I would monitor the rollback, not equate command success with service recovery.”

That answer names the arithmetic, the observable bottleneck, and the rollback boundary. Avoid saying a Running Pod is serving, a progress deadline performs an automatic rollback, or a Deployment revision reverses schema changes.

Practice question	What to rehearse
Explain CI/CD, Kubernetes delivery, and troubleshooting	Describe release gates and failed rollout triage.
Design and operate a monolith on Kubernetes	Calculate serving capacity and graceful rollout needs.
Explain How Microservices Run and Fail on Kubernetes	Connect Pod readiness to downstream behavior.
Debug Kubernetes crashes and review Python ingestion script	Investigate a new version that never becomes Ready.
Design secure Kubernetes with CI/CD	Defend rollout, access, and rollback controls.

For a timed exercise, use Explain CI/CD, Kubernetes delivery, and troubleshooting and give a 90-second diagnosis before suggesting any rollback command.

Sources and further reading

• Kubernetes: Deployments — rolling update arithmetic, progress and rollback behavior.
• Kubernetes: Perform a Rolling Update — operational rollout commands.
• Kubernetes: Configure Liveness, Readiness and Startup Probes — probe roles and readiness gates.
• Kubernetes: Disruptions — the separate Eviction API and PDB interaction.