Back to Blog

CKAD Deployments: Rolling Updates, Rollbacks, and Strategies (2026)

Master Kubernetes Deployments for the CKAD exam. Rolling updates, rollbacks, deployment strategies, scaling, and pause/resume — with kubectl recipes, YAML templates, and exam-style scenarios.

By Sailor Team , April 27, 2026

Deployments are the most-used Kubernetes resource in production and the heart of the CKAD’s “Application Deployment” domain. The exam consistently tests rolling updates, rollbacks, and scaling — often in chained questions where you must update an image, watch the rollout, then roll it back. Get fluent with the four kubectl rollout commands and you’ll bank these points fast.

This guide covers every Deployment pattern the CKAD tests, with copy-paste commands, YAML templates, and the gotchas that cost candidates points.

What a Deployment Actually Is

A Deployment is a controller that manages a ReplicaSet, which manages Pods. When you change the Deployment’s pod template, the controller creates a new ReplicaSet and gradually shifts pods from the old to the new — a rolling update. The old ReplicaSets stick around (configurable history) so you can roll back.

The CKAD tests three things repeatedly:

  1. Creating and configuring Deployments.
  2. Performing rolling updates and watching them complete.
  3. Rolling back when something breaks.

Creating a Deployment Fast

# Imperative
k create deploy web --image=nginx --replicas=3

# Generate YAML for editing
k create deploy web --image=nginx --replicas=3 --dry-run=client -o yaml > deploy.yaml

# With a port (for service-creation questions)
k create deploy web --image=nginx --replicas=3 --port=80 --dry-run=client -o yaml > deploy.yaml

The imperative form covers basic Deployments. For probes, multi-container pods, volumes, or resource limits, generate YAML and edit.

Scaling

# Scale up or down
k scale deploy web --replicas=5

# Conditional scale (only if current replicas match)
k scale deploy web --current-replicas=3 --replicas=5

# Verify
k get deploy web

The --current-replicas flag is rarely tested on the CKAD but useful in real life.

Updating Container Images

The most common Deployment task on the exam.

# Update an image (triggers rolling update)
k set image deploy/web web=nginx:1.25

# Update multiple containers
k set image deploy/web web=nginx:1.25 sidecar=fluent/fluent-bit:2.0

# Watch the rollout
k rollout status deploy web

The format is <container-name>=<new-image>. The container name comes from the Deployment’s pod template, not the deployment name.

Updating Other Spec Fields

# Change resource requests/limits
k set resources deploy web --limits=cpu=500m,memory=512Mi --requests=cpu=200m,memory=256Mi

# Set or update an env var
k set env deploy/web LOG_LEVEL=debug

# Remove an env var
k set env deploy/web LOG_LEVEL-

# Edit anything
k edit deploy web

kubectl set is faster than kubectl edit for simple changes — and less risk of YAML errors.

Rolling Update Strategy

Deployments have two strategy types:

RollingUpdate (default)

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1     # how many pods can be unavailable during the update
      maxSurge: 1           # how many extra pods above replicas can run

maxUnavailable and maxSurge can be absolute numbers or percentages ("25%").

For a 10-replica Deployment with maxUnavailable: 1, maxSurge: 1:

  • During the update, between 9 and 11 pods exist.
  • The controller adds new pods up to the surge, terminates old pods up to maxUnavailable, repeats until done.

Recreate

spec:
  strategy:
    type: Recreate

All old pods are killed before new pods start. There’s downtime. Use this when:

  • The app can’t run two versions concurrently (e.g., schema migrations).
  • The exam explicitly says “no two versions running at once.”

The CKAD often tests recognizing when to switch from RollingUpdate to Recreate.

Watching a Rollout

# Wait until rollout completes (blocks until ready or failed)
k rollout status deploy web

# Watch deployments in real time
k get deploy web -w

# Watch the underlying ReplicaSets (multiple during a rolling update)
k get rs -w

# Watch pods
k get pods -l app=web -w

kubectl rollout status returns when the rollout is done — exit code 0 if successful, non-zero if failed. Use it in scripts and as the verification step on every update question.

Pausing and Resuming a Rollout

You can pause a rollout mid-stream — useful when you want to apply multiple changes and have them roll out together.

# Pause
k rollout pause deploy web

# Make multiple changes — none of them roll out yet
k set image deploy/web web=nginx:1.25
k set env deploy/web LOG_LEVEL=debug
k set resources deploy web --limits=cpu=500m

# Resume — all changes roll out together
k rollout resume deploy web

# Verify
k rollout status deploy web

The CKAD occasionally asks for a paused-then-resumed flow. Watch for “make these changes without triggering multiple rollouts.”

Rollback Patterns

Rollback to the Previous Revision

k rollout undo deploy web

This is the simple one. Roll back to the immediately previous revision. The current revision becomes a “rollback target” if you need to roll forward again.

Rollback to a Specific Revision

# View the revision history
k rollout history deploy web

# Inspect a specific revision
k rollout history deploy web --revision=3

# Roll back to revision 3
k rollout undo deploy web --to-revision=3

The history is limited by revisionHistoryLimit in the Deployment spec (default 10). Rolling back to a revision that’s been pruned will fail.

Rollback Verification

k rollout status deploy web
k describe deploy web | grep Image

Always verify after a rollback — the exam grader checks the running image, not the history command output.

Restart a Deployment (Force a Rollout Without Changing Anything)

Useful when an env var, ConfigMap, or Secret has changed and you want to force pods to pick up the new value.

k rollout restart deploy web

This adds an annotation to the pod template, which triggers a rolling restart. The new pods see the latest ConfigMap/Secret values via env vars (if mounted as env vars; volume mounts don’t need this).

Adding Probes During an Update

The CKAD often chains tasks: “Update the image, then add a readiness probe, then verify.”

k set image deploy/web web=nginx:1.25
k edit deploy web
# add the probe under containers
k rollout status deploy web

For the probe shape, see our CKAD probes guide.

RevisionHistoryLimit

Controls how many old ReplicaSets are kept for rollback purposes:

spec:
  revisionHistoryLimit: 5      # keep last 5 revisions

The exam may ask you to limit history (production hygiene) — set this to a low number like 3 or 5.

Common Deployment Question Variants

Variant 1: Update an Image and Watch the Rollout

“Update deployment web to use image nginx:1.25. Confirm the rollout completes successfully.”

k set image deploy/web web=nginx:1.25
k rollout status deploy web
k describe deploy web | grep Image     # verify

Variant 2: Roll Back After a Bad Image

“Deployment web was updated to nginx:broken-tag and is failing. Roll back to the previous working version.”

k rollout undo deploy web
k rollout status deploy web
k describe deploy web | grep Image

Variant 3: Switch to Recreate Strategy

“Modify deployment migrate to use the Recreate strategy so old pods are fully terminated before new pods start.”

k edit deploy migrate
# change spec.strategy.type to Recreate, remove the rollingUpdate block

Or with a patch:

k patch deploy migrate -p '{"spec":{"strategy":{"type":"Recreate","rollingUpdate":null}}}'

The null clears the rollingUpdate block (Recreate doesn’t allow it).

Variant 4: Pause, Make Several Changes, Resume

“Pause deployment api. Update its image to v2, change LOG_LEVEL to debug, and increase replicas to 5. Resume so all changes roll out as one update.”

k rollout pause deploy api
k set image deploy/api api=myapp:v2
k set env deploy/api LOG_LEVEL=debug
k scale deploy api --replicas=5
k rollout resume deploy api
k rollout status deploy api

Variant 5: Configure maxSurge and maxUnavailable

“Configure deployment web so that during a rolling update, at most 25% of pods can be unavailable and at most 50% extra pods can run.”

k patch deploy web -p '
spec:
  strategy:
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 50%
'

Common Mistakes (and How to Avoid Them)

  1. Wrong container name in kubectl set image. The format is <container>=<image>. Container name comes from spec.template.spec.containers[].name, not the deployment name.
  2. Forgetting to verify with rollout status. A successful kubectl set image doesn’t mean the rollout completed. Always wait for it.
  3. Using kubectl edit for simple changes. It’s slower and easier to break with YAML errors. Prefer kubectl set, kubectl patch, or kubectl scale.
  4. Rolling back without checking history. kubectl rollout undo (without --to-revision) goes one step back — sometimes that’s not what the question asks.
  5. Switching to Recreate but leaving the rollingUpdate block. Setting type: Recreate with rollingUpdate: in the spec is invalid. Remove the block.
  6. Editing the ReplicaSet instead of the Deployment. The Deployment owns the ReplicaSets — edit the Deployment, and it propagates.

How to Practice Deployments

Drill these on a kind cluster under a 4-minute timer each:

  1. Create a Deployment with 3 replicas, expose it as a service.
  2. Update the image and watch the rollout complete.
  3. Roll back to the previous image.
  4. Pause, change image and env var, resume.
  5. Switch from RollingUpdate to Recreate.
  6. Configure maxSurge and maxUnavailable.
  7. Use kubectl rollout history and roll back to a specific revision.

If you can do all seven in under 30 minutes total, Deployments won’t slow you down on exam day.

Validate Your Speed Under Exam Conditions

The CKAD tests Deployments in the context of full application chains — create a Deployment, expose it, update the image, add a probe, roll back when something fails. Drilling each operation in isolation isn’t enough. Take a full-length scored simulator with our CKAD Mock Exam Bundle — every simulator includes Deployment questions in realistic context with time pressure.

Frequently Asked Questions

Q: How many Deployment questions are on the CKAD? A: Deployments touch nearly every CKAD question. Direct deployment-management tasks (update, rollback, scale, strategy) account for ~15-20% of the score.

Q: Can I use kubectl apply with a YAML file instead of kubectl set image? A: Yes, and it’s often what production-grade workflows use. But kubectl set image is faster and less error-prone on the exam.

Q: What’s the difference between RollingUpdate and Recreate? A: RollingUpdate replaces pods gradually with no downtime. Recreate kills all pods first and then starts new ones, with downtime.

Q: How do I find the previous image after a rolling update? A: kubectl rollout history deploy <name> lists revisions; kubectl rollout history deploy <name> --revision=<n> shows the pod template for that revision.

Q: Does kubectl rollout undo work after the history is pruned? A: Only if the target revision is still in history. By default, revisionHistoryLimit: 10. Beyond that, you can’t roll back.

Q: Can I do a rolling restart without changing anything? A: Yes — kubectl rollout restart deploy <name> triggers a restart by adding an annotation to the pod template.

Q: What happens to pods during kubectl rollout pause? A: Existing pods stay running. New changes don’t propagate until kubectl rollout resume. The current rollout doesn’t progress further if it was mid-stream.

Ready to make Deployments automatic points on your CKAD? Run a scored full-length simulator with our CKAD Mock Exam Bundle and find out exactly where you stand.

Limited Time Offer: Get 80% off all Mock Exam Bundles | Sale ends in 7 days. Start learning today.

Claim Now