Create a deployment as follows: Name: nginx-app Using container nginx with version 1.11.10-alpine The deployment should contain 3 replicas. Next, deploy the application with new version 1.13-alpine…

Kubernetes Deployment: Rolling Update and Rollback Overall Goal This question tests your ability to manage the full lifecycle of a Kubernetes Deployment: creation, controlled updates, and recovery. This is the standard production workflow because Deployments provide declarative…

Submitted by dimitri_ru· May 4, 2026Workloads and Scheduling

Question

Create a deployment as follows: Name: nginx-app Using container nginx with version 1.11.10-alpine The deployment should contain 3 replicas. Next, deploy the application with new version 1.13-alpine, by performing a rolling update. Finally, rollback that update to the previous version 1.11.10-alpine.

Explanation

Kubernetes Deployment: Rolling Update and Rollback

Overall Goal

This question tests your ability to manage the full lifecycle of a Kubernetes Deployment: creation, controlled updates, and recovery. This is the standard production workflow because Deployments provide declarative management, zero-downtime updates, and built-in rollback history - none of which you get with raw Pods.

Step 1: Create the Deployment

kubectl create deployment nginx-app \
  --image=nginx:1.11.10-alpine \
  --replicas=3

Why this is necessary: A Deployment is the correct workload object here (not a Pod or ReplicaSet) because it manages ReplicaSets under the hood, tracks revision history, and enables the rolling update and rollback steps that follow.

Setting --replicas=3 ensures high availability. The rolling update in Step 2 relies on having multiple replicas - Kubernetes can take some down and bring new ones up without total downtime.

If skipped: Nothing to update or roll back. Steps 2 and 3 have no target.

Step 2: Perform a Rolling Update to 1.13-alpine

kubectl set image deployment/nginx-app nginx=nginx:1.13-alpine

Why this is necessary: kubectl set image triggers a rolling update - Kubernetes incrementally replaces old Pods (running 1.11.10-alpine) with new ones (running 1.13-alpine), respecting maxSurge and maxUnavailable defaults (25% each). At no point are all Pods down simultaneously.

This also creates a new revision in the Deployment's rollout history, which is what makes rollback possible.

You can verify progress with:

kubectl rollout status deployment/nginx-app

If skipped: There is no revision to roll back to. Skipping this also defeats the purpose of testing update procedures.

Step 3: Roll Back to 1.11.10-alpine

kubectl rollout undo deployment/nginx-app

Why this is necessary: rollout undo reverts the Deployment to its previous revision (revision 1, running 1.11.10-alpine). Kubernetes does this by applying another rolling update in reverse - it doesn't just swap a label; it replaces Pods in the same controlled manner.

You can confirm the image reverted:

kubectl describe deployment nginx-app | grep Image

If done out of order (before the update): There is only one revision in history, so there is nothing to undo - the command either errors or is a no-op.

What Kubernetes Is Doing Behind the Scenes

Step	ReplicaSet State
After create	RS-1 (1.11.10-alpine, 3 replicas)
After update	RS-1 scaled to 0, RS-2 (1.13-alpine, 3 replicas)
After rollback	RS-2 scaled to 0, RS-1 scaled back to 3

Kubernetes keeps old ReplicaSets around (controlled by revisionHistoryLimit, default 10) specifically to enable rollback without re-pulling images.

Memory Tip

"Create → Set → Undo" - think of it as writing a document, making a bad edit, then hitting Ctrl+Z. The Deployment's revision history is your undo stack. You can only undo what you first did.

Topics

#Deployment#Rolling Update#Rollback#ReplicaSet

Community Discussion

No community discussion yet for this question.

Full CKA Practice