Overview
Application Deployment is about changing what runs without breaking it. You update a Deployment image with kubectl set image, watch kubectl rollout status, read rollout history and undo to a named revision. You tune maxSurge and maxUnavailable to control how fast old Pods are replaced, or switch to the Recreate strategy when two versions must never run together. Kubernetes has no built-in blue/green or canary object, so you build them from primitives: two Deployments with different version labels, and a Service selector that you point at one, the other, or both.
The tooling half covers Helm and Kustomize. With Helm you add a repository, search it, install a chart into a namespace with overridden values, upgrade and roll back. With Kustomize you write a kustomization.yaml that sets images, namespaces, labels, patches and generated ConfigMaps, then apply it with kubectl apply -k.
How it's tested
Deployment tasks give a starting state, such as a Deployment at version one or a chart in a repository, and a target state. You might roll an image forward and then back, split traffic between two versions, or install a chart with specific values. The grader inspects the live objects and release metadata.
-
Rollout and rollback
Update a container image, record the change, check rollout history and undo to a specific earlier revision named in the task.
-
Traffic split with labels
Create a second Deployment and adjust replicas and Service selectors so a stated share of Pods, or all traffic, moves to the new version.
-
Package tooling
Install, upgrade or uninstall a Helm release with values in a named namespace, or render a Kustomize overlay that changes images and labels.
A task asks for a canary where about 20% of requests to Service web reach version two. Keeping Deployment web-v1 at four replicas, creating web-v2 with one replica, and giving both Pod templates the label app=web that the Service selects produces a one-in-five split. Changing the Service selector to version=v2 would send everything to the canary instead.
Competencies 4
Official competencies from the CNCF / The Linux Foundation outline, in outline order.
2.1 Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary)Blue/green and canary releases built from Deployments, labels and Services.
- What it means
- Kubernetes ships RollingUpdate and Recreate strategies on Deployments but no dedicated blue/green or canary resource. You assemble those patterns from separate Deployments, Pod labels and Service selectors.
- What to understand
- For blue/green, run blue and green Deployments side by side with labels such as version=blue and version=green, then switch the Service selector once green is ready; switching back is the rollback. For a canary, give both Deployments a shared label the Service selects plus a distinguishing version label, and set replica counts to approximate the traffic share. Distribution is per Pod, not exact per request.
- How it shows up
- Expect to create the second version, adjust replicas for a percentage, or flip a Service selector.
- Common confusion
- Forgetting that the Deployment selector must still match its own Pod template labels after edits.
2.2 Understand Deployments and how to perform rolling updatesRolling update settings, rollout status, history, pause and undo.
- What it means
- A Deployment rolls out changes by creating a new ReplicaSet and scaling it up while scaling the old one down. Only changes to the Pod template trigger a new rollout and revision.
- What to understand
- maxSurge sets how many extra Pods may exist and maxUnavailable how many may be missing, as numbers or percentages. Use kubectl set image, kubectl rollout status, history, undo --to-revision=N, pause and resume. Annotate kubernetes.io/change-cause to label revisions. revisionHistoryLimit controls how many old ReplicaSets are kept, minReadySeconds delays counting Pods as available, and the Recreate strategy stops all old Pods first.
- How it shows up
- You may update an image, then roll back to a stated revision and confirm the image in use.
- Common confusion
- Scaling replicas does not create a new revision, so it never appears in rollout history.
2.3 Use the Helm package manager to deploy existing packagesFinding, installing, upgrading and removing Helm charts.
- What it means
- Helm packages Kubernetes manifests as charts with configurable values. Installing a chart creates a named release that Helm tracks, so you can upgrade, roll back or uninstall it as one unit.
- What to understand
- Core commands: helm repo add and update, helm search repo, helm show values, helm install release repo/chart -n ns --create-namespace with --set or -f values.yaml, helm upgrade, helm rollback release revision, helm uninstall, helm list -A and helm history. helm template renders manifests without installing. Release names are scoped to a namespace, so -n must match on every later command.
- How it shows up
- Expect to install a chart with one or two overridden values into a given namespace, or find and remove a release.
- Common confusion
- Running helm list without -n or -A and concluding a release does not exist.
2.4 KustomizeTemplate-free customization with kustomization.yaml, bases and overlays.
- What it means
- Kustomize customizes plain YAML without templates. A kustomization.yaml lists resources and transformations, and kubectl has it built in through kubectl kustomize and the -k flag of apply and delete.
- What to understand
- Know resources, namespace, namePrefix and nameSuffix, labels, images (newName and newTag), replicas, patches with strategic merge or JSON 6902 targets, and configMapGenerator and secretGenerator, which add a content hash to the name and update references. An overlay directory points at a base and adds its own changes. Render with kubectl kustomize dir to check output before kubectl apply -k dir.
- How it shows up
- A task may give a base and ask for an overlay that changes the image tag, namespace or replica count.
- Common confusion
- Running kubectl apply -f on the directory, which ignores kustomization.yaml.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
maxSurge and maxUnavailable
Control extra and missing Pods during a rolling update.
- Remember
- Both default to 25%; setting maxUnavailable 0 keeps full capacity.
- Tested as
- Tasks often specify exact values.
- Trap
- Setting both to 0, which the API rejects.
-
kubectl rollout undo
Returns a Deployment to a previous Pod template.
- Remember
- --to-revision picks a specific revision from rollout history.
- Tested as
- Rollback tasks name the target revision.
- Trap
- Undoing without the flag and landing on the wrong revision after several updates.
-
Revision history
Each Pod template change creates a revision backed by a ReplicaSet.
- Remember
- revisionHistoryLimit caps how many are kept; 0 disables rollback.
- Tested as
- Explains missing revisions in history output.
- Trap
- Expecting scale changes to show as revisions.
-
Recreate strategy
Terminates all old Pods before creating new ones.
- Remember
- Causes downtime but avoids running two versions together.
- Tested as
- Fits tasks where versions cannot coexist.
- Trap
- Leaving rollingUpdate settings in the spec, which fails validation.
-
Blue/green with Services
Two full Deployments; the Service selector decides which receives traffic.
- Remember
- Cut-over and rollback are a single selector change.
- Tested as
- A common traffic-switch task.
- Trap
- Deleting blue before green is ready.
-
Canary by replica ratio
A shared label puts old and new Pods behind one Service.
- Remember
- Traffic share approximates replicas of each version over total replicas.
- Tested as
- Percentage tasks need correct arithmetic.
- Trap
- Counting only the canary replicas in the total.
-
helm install flags
--namespace, --create-namespace, --set and -f supply target and values.
- Remember
- --version pins a chart version.
- Tested as
- Installs are graded on namespace and values.
- Trap
- Putting --set values in the wrong key path; check helm show values.
-
helm rollback
Restores a release to an earlier revision number.
- Remember
- helm history lists revision numbers and statuses.
- Tested as
- Release recovery tasks rely on it.
- Trap
- Confusing Helm revisions with Deployment rollout revisions.
-
Kustomize images transformer
Rewrites image names and tags across resources.
- Remember
- newTag and newName change the reference without editing YAML.
- Tested as
- Fast way to version an overlay.
- Trap
- Patching the container image by hand and leaving other resources unchanged.
-
configMapGenerator
Builds a ConfigMap from files or literals with a hash suffix.
- Remember
- References in workloads are rewritten to the hashed name.
- Tested as
- Changing config then triggers a rollout automatically.
- Trap
- Referencing the unhashed name in a manifest outside the kustomization.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Release strategies
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| RollingUpdate | Gradually replaces old Pods with new ones | Both versions serve briefly | Assuming it pauses on failure without readiness probes |
| Recreate | Stops old Pods, then starts new ones | Downtime but no version overlap | Choosing it when zero downtime is required |
| Blue/green | Two complete versions, one live through the Service | Instant switch and rollback | Needing double capacity during the switch |
| Canary | Small share of Pods run the new version | Gradual exposure by replica ratio | Expecting exact per-request percentages |
Helm compared with Kustomize
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Helm chart | Templated package installed as a release | Tracks revisions and supports rollback | Expecting kubectl to list Helm releases |
| Kustomize overlay | Plain YAML plus transformations | No release object; kubectl applies the output | Looking for a kustomize rollback command |
Rollback commands
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| kubectl rollout undo | Reverts a Deployment's Pod template | Works on one workload | Using it on a Helm-managed Deployment and drifting from the release |
| helm rollback | Reverts every object in a release | Uses Helm revision numbers | Passing a Deployment revision number |
| Service selector switch | Points traffic back to the old Deployment | Used for blue/green | Forgetting to keep the old Deployment running |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Selector that excludes the canary
- What candidates pick
- Copying the stable Service selector including version=v1.
- Why it looks right
- It already works for the stable Pods.
- Why it's wrong
- A Service matches only Pods carrying every selector label, so canary Pods labelled v2 never receive requests.
Clue to watch for Any task asking for traffic to reach both versions.
-
Wrong rollback target
- What candidates pick
- Running rollout undo once.
- Why it looks right
- It feels like a simple step back.
- Why it's wrong
- Undo returns to the previous revision only; after several updates that may not be the revision requested.
Clue to watch for A revision number or image tag named in the task.
-
Helm release in the wrong place
- What candidates pick
- helm install without a namespace flag.
- Why it looks right
- The command succeeds and the Pods start.
- Why it's wrong
- The release and its objects are created in default, so checks in the target namespace find nothing.
Clue to watch for A namespace mentioned anywhere in the task.
-
Values set at the wrong key
- What candidates pick
- --set replicas=3 for a chart that uses replicaCount.
- Why it looks right
- Many charts use slightly different names.
- Why it's wrong
- Unknown keys are ignored silently, so the release installs with the default value.
Clue to watch for Any chart value requirement; read helm show values first.
-
Unready Pods counted as rolled out
- What candidates pick
- Declaring success once new Pods exist.
- Why it looks right
- kubectl get shows the new ReplicaSet.
- Why it's wrong
- Without a passing readiness probe the rollout can stall; check rollout status until it completes.
Clue to watch for Tasks that ask you to confirm the rollout finished.
-
Overlay applied without its base
- What candidates pick
- Copying base files into the overlay folder.
- Why it looks right
- It seems simpler than referencing a path.
- Why it's wrong
- The task usually grades the overlay's resources entry pointing at the base, and duplicates cause name conflicts.
Clue to watch for A directory layout with base and overlays folders.
Answer framework
Use this sequence for any task that changes which application version is running.
- Identify the starting objects, such as Deployments, Services, Helm releases or kustomization directories, and the namespace each one lives in.
- Decide the mechanism the task implies: rolling update, Recreate, label-based traffic switch, Helm command or Kustomize overlay.
- Check selectors and labels before changing anything, so Services, Deployments and Pod templates still match afterwards, and read helm show values for charts.
- Make the change with the native command, such as kubectl set image, helm upgrade or kubectl apply -k, keeping release, image and namespace names exact.
- Verify with rollout status, rollout history, helm list or kubectl get endpoints that the intended version is serving.
Practice question
Want more like this? The CKAD practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with plain Deployments. Create one, change its image three times with kubectl set image, annotate each change-cause, and practise rolling back to each revision by number. Then set maxUnavailable to 0 and maxSurge to 1 and watch kubectl get rs -w to see exactly how Pods are replaced.
Build blue/green and canary releases by hand next. Keep a Service fixed and move traffic only through labels, checking kubectl get endpoints after each change. Calculate replica ratios for 10%, 20% and 25% so the arithmetic is quick.
Spend the remaining time on tooling. Add a public chart repository, read helm show values for one chart, install it twice in different namespaces with different values, upgrade one and roll it back. For Kustomize, create a base with a Deployment and Service, then two overlays that change namespace, image tag and replicas. Render each with kubectl kustomize before applying. Finally, run a mixed drill of six deployment tasks in thirty minutes and note which commands slowed you down.
FAQ
How much of the CKAD exam is Application Deployment?
Application Deployment is weighted at 20% in the official CKAD curriculum. Expect three or four tasks covering rollouts, release strategies, Helm and Kustomize.
Is Helm installed in the exam environment?
The curriculum lists Helm explicitly, so tasks that need it provide the helm CLI on the task host. Know the commands without relying on autocompletion, since the Helm documentation is not on the main kubernetes.io site.
Do I need to write Helm charts?
No. The competency is deploying existing packages, so focus on repository, install, upgrade, rollback, list and uninstall commands with values overrides.
Does Kustomize need a separate binary?
No. kubectl includes Kustomize, so kubectl kustomize renders output and kubectl apply -k applies a directory containing kustomization.yaml.
Can kubectl do blue/green deployments automatically?
No. Kubernetes has no blue/green resource. You run two Deployments and change the Service selector to move traffic between them.
Why is my rollout stuck?
New Pods may be failing readiness checks, pulling a bad image or lacking resources. Check kubectl rollout status, describe the new ReplicaSet's Pods and read events before undoing.
What does the change-cause annotation do?
kubernetes.io/change-cause on the Deployment is copied into rollout history, so each revision shows why it was made. It replaces the deprecated --record flag.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
Practise timed rollouts, rollbacks, label-based traffic switches, Helm releases and Kustomize overlays across this 20% domain before a full mock exam.