Application updates, rollbacks, and rollout strategies. This is the core of how you change a live application without taking it offline or accidentally breaking everything for every user. For CKAD, you must prove you can update a Kubernetes deployment, monitor the rollout health, and undo a bad change — all from the command line — because that is exactly what a real application developer does every day.
Jump to a section
A simple way to picture Application Updates, Rollbacks, and Rollout Strategies
12 food trucks are parked at a busy city square, each one selling a different menu item. Today, your signature dish — the spicy jackfruit burrito — has a new recipe with a different sauce, and you need to update every truck without ever shutting down the whole operation. You decide to update 3 trucks at a time. While those 3 are closed, customers just walk to the other 9 trucks and buy their regular burrito. Once the first 3 are back open with the new sauce, you update the next 3, and so on until all 12 trucks serve the new recipe.
Halfway through, a customer at truck 4 complains the new sauce is too spicy. You need to roll back immediately. You tell the next 3 trucks in line: 'Stop changing. Switch back to the old sauce.' Then you change the trucks that already updated — one by one — back to the old recipe. Customers never noticed the chaos because there were always 9 trucks open and selling something.
That planned, gradual switch is a rolling update. The emergency reversal is a rollback. Your decision to update 3 trucks at a time instead of all 12 at once is the rollout strategy. Every real-world IT system that must stay live 24/7 uses this exact logic to change software without breaking the customer experience.
In Kubernetes, an application runs as a Deployment. A Deployment is a blueprint that tells Kubernetes: 'Keep 5 copies of my app running at all times.' Each copy is called a Pod — a single running instance of your containerised software. When you want to change the container image (for example, upgrade from version 2.0 to 2.1), you do a rollout. A rollout is the process of gradually replacing old Pods with new ones.
The default rollout strategy is called a Rolling Update. This means Kubernetes does not kill all old Pods at once. Instead, it creates a new Pod with the new image, waits until that Pod is healthy, then kills one old Pod. It repeats this cycle until every old Pod has been replaced.
But you can configure two important parameters: maxSurge and maxUnavailable. maxSurge controls how many extra Pods can be created above your desired count during the update. If you set maxSurge to 1, Kubernetes can create one extra Pod beyond the 5 you want — so you might have 6 Pods temporarily. maxUnavailable controls how many Pods can be unavailable during the update. If set to 0, Kubernetes will never have fewer than your desired 5 Pods running. These settings let you balance speed against risk.
If something goes wrong during a rollout — your new image crashes, or health checks fail — you need a rollback. A rollback reverts the Deployment to its previous stable version. Kubernetes stores the history of changes to a Deployment. You can see the history with 'kubectl rollout history deployment/my-app'. To undo the last change, you run 'kubectl rollout undo deployment/my-app'. You can also roll back to a specific revision number using '--to-revision=2'.
Kubernetes also supports a second rollout strategy: Recreate. With Recreate, Kubernetes kills every running Pod first, then creates all new Pods from the new image. This causes downtime because there is a period when zero Pods are running. Recreate is rarely used for production services that must stay available, but it can be useful for batch jobs or test environments where a clean slate matters more than uptime.
The rollout process itself goes through several states: Progressing (the update is happening), Complete (all Pods are updated and healthy), or Failed (new Pods cannot start). You check the status with 'kubectl rollout status deployment/my-app'. If it hangs or fails, you can add '--watch' to see real-time progress.
Why does all this matter? Before Kubernetes, updating a live application meant either taking the whole site offline or using complex scripting to drain traffic from one server, update it, and repeat. Kubernetes automates this with a declarative model: you tell the system what you want (image version 2.1, 5 replicas, RollingUpdate strategy) and it figures out how to get there safely. Your job as a CKAD candidate is to know the commands, understand the parameters, and handle emergencies when a rollout goes wrong.
Edit the Deployment YAML
Change the container image tag (e.g., from nginx:1.18 to nginx:1.19) or other fields. You can edit the YAML file directly or use 'kubectl edit deployment/name'. This defines the desired state.
Apply the change
Run 'kubectl apply -f deployment.yaml' to send the new YAML to the Kubernetes API server. This triggers the rollout, and Kubernetes begins comparing the current state to the desired state.
Monitor the rollout status
Use 'kubectl rollout status deployment/name --watch' to see if new Pods are created and old ones removed. The command exits with success or failure, showing you the progress of each step.
Check Pod health with readiness probes
Kubernetes uses readinessProbe to decide if a new Pod is ready to serve traffic. If the probe fails, the rollout stalls. You can see this by looking at 'kubectl get pods' and checking the 'READY' column.
Perform a rollback if needed
If the rollout fails or you decide the new version is bad, run 'kubectl rollout undo deployment/name'. This reverts to the previous revision's Pod template, creating old-version Pods and removing new ones.
Verify the rollback succeeded
Check 'kubectl rollout status deployment/name' again, and use 'kubectl get pods' to confirm all Pods are running the old image. This ensures the application is stable before you move on.
Imagine you work for a ride-sharing app company. Your team maintains the microservice that calculates surge pricing. The service runs as a Kubernetes Deployment with 20 replicas spread across multiple availability zones. Today, your team is releasing version 4.2, which uses a new machine-learning model to predict demand.
You start by editing the Deployment YAML to change the container image tag from 'surge-engine:4.1' to 'surge-engine:4.2'. You save the file and apply it with 'kubectl apply -f deployment.yaml'. Immediately, Kubernetes begins a rolling update. It creates one new Pod with version 4.2. The Pod starts, but its readiness probe fails because the new model needs a different API key that hasn't been provisioned yet.
Kubernetes waits. The readiness probe keeps failing after the configured timeout. Kubernetes marks that new Pod as unhealthy and stops the rollout. The Deployment status shows 'Progressing' for a while, then 'Failed'. At this moment, the old 20 replicas are still running with version 4.1 — no customers are affected.
You check 'kubectl rollout history deployment/surge-engine' and see that revision 12 is the current stable one. You run 'kubectl rollout undo deployment/surge-engine --to-revision=12'. Kubernetes kills the one failed 4.2 Pod and goes back to 20 healthy 4.1 Pods. The incident is resolved in under two minutes.
Later, your colleague fixes the API key issue. This time, before applying the update, you change the Deployment's strategy to: maxSurge: 2 and maxUnavailable: 1. This means up to 2 extra Pods can be created, and only 1 Pod can be unavailable at a time — so 21 Pods total at peak, never fewer than 19. You apply the new YAML, watch 'kubectl rollout status deployment/surge-engine --watch', and see each Pod come up green. The entire rollout completes in 90 seconds. Customers never experience a delay or an error.
Key actions an IT professional performs:
Editing the Deployment YAML to change the container image tag and rollout parameters.
Running 'kubectl apply -f deployment.yaml' to trigger the update.
Monitoring progress with 'kubectl rollout status' and 'kubectl get pods -w'.
Checking rollout history with 'kubectl rollout history deployment/my-app'.
Executing a rollback with 'kubectl rollout undo deployment/my-app'.
Pausing a rollout with 'kubectl rollout pause deployment/my-app' if you need to investigate mid-update.
Resuming a paused rollout with 'kubectl rollout resume deployment/my-app'.
CKAD exam tasks on this topic are practical and command-line based. You will be given a scenario and must type the correct kubectl commands to perform an update or a rollback. Traps are common, and the time pressure is real.
Question types you will see:
'Update the image of Deployment X to nginx:1.19 and verify the rollout succeeds.' You must edit the Deployment, apply the change, and check status.
'A recent rollout of Deployment Y caused pods to crashLoopBackOff. Roll back to the previous revision.' You must identify the failed state, find the previous revision number, and use 'kubectl rollout undo'.
'Configure Deployment Z so that during rolling updates, no more than 2 Pods are unavailable and exactly 1 extra Pod can be created.' You must edit the strategy spec with maxUnavailable: 2 and maxSurge: 1 (or similar numbers).
'Pause the rollout of Deployment A after 3 Pods have been updated, then verify it's paused, then resume it.' You must use 'kubectl rollout pause' and 'kubectl rollout resume'.
Traps to watch for:
The exam may ask you to roll back to a specific revision, not just the previous one. Use '--to-revision=N'.
You might need to edit a Deployment that has no strategy specified. Default strategy is RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. You must understand that percentages are rounded up or down — Kubernetes rounds percentages up for maxSurge and down for maxUnavailable, so with 3 replicas, maxSurge: 25% becomes 1, maxUnavailable: 25% becomes 0.
If a rollout fails, the Deployment is still considered 'progressing' if you check during the retry cycle. You must wait for the status to settle or use '--timeout' to fail fast.
The exam may give you a Deployment name but not tell you the namespace. Use '--namespace' or set your context.
Rolling back does not automatically update the YAML file in the cluster's etcd store in a way you can see with 'kubectl get deployment -o yaml' — the revision history is separate from the applied YAML. You must check history to see previous configurations.
Key definitions to memorise:
RollingUpdate: Default strategy. Replaces Pods gradually.
Recreate: Kills all Pods before creating new ones. Causes downtime.
maxSurge: Maximum number of Pods allowed above the desired count during update.
maxUnavailable: Maximum number of Pods allowed to be unavailable during update.
readinessProbe: Health check that tells Kubernetes when a Pod is ready to serve traffic. If this fails during a rollout, the update stops.
rollout status: Command to check if a rollout succeeded or failed.
rollout history: Shows revision history for undo operations.
rollout undo: Reverts to a previous revision.
rollout pause / resume: Controls the rollout flow manually.
The default rollout strategy in Kubernetes is RollingUpdate, which replaces Pods gradually without downtime.
Use 'kubectl rollout undo deployment/name' to revert a deployment to its previous revision, or add '--to-revision=N' for a specific revision.
maxSurge controls how many extra Pods can be created above the desired count during a rollout; it rounds percentages up.
maxUnavailable controls how many Pods can be down during a rollout; it rounds percentages down.
A failing readiness probe during a rollout causes Kubernetes to stop the update and keep the old Pods running.
The 'kubectl rollout status deployment/name --watch' command shows real-time progress and succeeds or fails explicitly.
The Recreate strategy kills all existing Pods before creating new ones, which causes downtime and is rarely used in production.
You can pause a rollout with 'kubectl rollout pause' and resume later with 'kubectl rollout resume'.
Rollout history stores old ReplicaSet configurations, allowing you to roll back to any previous revision number.
Always verify a rollout with 'kubectl get pods' and 'kubectl rollout status' before declaring success.
These come up on the exam all the time. Here's how to tell them apart.
RollingUpdate Strategy
Pods are replaced gradually, one or few at a time.
Zero downtime during the update.
Default strategy for Deployments.
Recreate Strategy
All Pods are deleted first, then new Pods are created.
Complete downtime during the transition.
Must be explicitly configured; rarely used for production.
rollout undo
One command reverts to a previous revision.
Preserves rollout history for future undo operations.
Kubernetes automatically manages the old ReplicaSet.
manual YAML revert
You edit the YAML file and re-apply it.
You must know the exact previous image tag and settings.
Risks human error if you misremember the old config.
maxSurge
Controls extra Pods above desired count.
Can be set as percentage (rounded up).
Helps speed up rollout by creating Pods in parallel.
maxUnavailable
Controls Pods allowed to be down during update.
Can be set as percentage (rounded down).
Helps maintain minimum availability during rollout.
Mistake
A rollback always goes back to the exact previous version before the update.
Correct
You can roll back to any revision in the history, not just the immediately previous one. Use --to-revision flag to specify.
Beginners assume rollback is an 'undo last action' button, like Ctrl+Z in a word processor. In Kubernetes, you have a full history of revisions, and you can jump to any of them.
Mistake
If a rollout fails, you must manually delete the new Pods and reapply the old YAML.
Correct
You simply run 'kubectl rollout undo deployment/name'. Kubernetes automatically reverts to the previous revision's Pod template and cleans up.
New users think they must manually intervene because they do not trust Kubernetes automation. The whole point of rollbacks is that Kubernetes handles the revert for you.
Mistake
maxSurge and maxUnavailable percentages apply to the number of Pods exactly as you set them — 25% of 4 replicas means exactly 1 Pod.
Correct
Percentages are rounded: maxSurge rounds up (25% of 4 = 1) and maxUnavailable rounds down (25% of 4 = 0). This can cause unexpected behaviour with small replica counts.
Mathematically, 25% of 4 is 1, but the rounding rules are not symmetrical. Beginners often assume clean division and are confused when they see 0 unavailable during a rollout.
Mistake
A Recreate strategy is safer than a RollingUpdate because it gives a clean start.
Correct
Recreate causes complete downtime and is generally less safe for production. RollingUpdate is safer because it maintains service continuity during the update.
'Clean start' sounds appealing to someone who dislikes partial states. But in real systems, downtime is the worst outcome, so Recreate is only used for non-live workloads.
Mistake
The rollout status command tells you immediately if the rollout succeeded or failed.
Correct
The command waits for the rollout to complete (or times out). It shows 'successfully rolled out' only after all new Pods pass readiness probes. If it hangs, you may need to set a timeout.
Beginners expect an instant answer. In reality, Kubernetes waits for health checks, and a slow Pod startup can make the command appear stuck.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A rollout is the process of updating a Deployment to a new configuration (e.g., a new image version). A rollback is the process of reverting a Deployment to a previous configuration from its history.
Run 'kubectl rollout undo deployment/my-app --to-revision=3', replacing '3' with the revision number you want. You can see all revision numbers with 'kubectl rollout history deployment/my-app'.
maxSurge is the maximum number of extra Pods allowed above the desired count during a rolling update. maxUnavailable is the maximum number of Pods that can be unavailable during the update. Both can be set as a number or percentage.
Kubernetes stops creating new Pods and keeps the old Pods running. The Deployment's status shows 'Progressing' or 'Failed'. You can then roll back to a previous revision to restore service.
Yes. Use 'kubectl rollout pause deployment/my-app' to pause the rollout at its current state. Use 'kubectl rollout resume deployment/my-app' to continue it from where it stopped.
Run 'kubectl rollout history deployment/my-app'. It lists each revision with a change-cause annotation if set. To see details of a specific revision, add '--revision=2'.
You've finished Application Updates, Rollbacks, and Rollout Strategies. Continue through the CKAD study guide to build a complete picture of the exam.
Done with this chapter?