Overview
Domain 2 covers running applications on the cluster. You need to create and update Deployments, watch a rolling update, and roll back to an earlier revision; inject configuration from ConfigMaps and Secrets as environment variables or mounted files; configure a HorizontalPodAutoscaler; and choose the right self-healing primitive, whether a Deployment, StatefulSet, DaemonSet, Job or probe. The final competency covers how Pods are admitted and placed: resource requests and limits, LimitRange and ResourceQuota, nodeSelector, node affinity, and taints with tolerations.
Most tasks are short and benefit from imperative commands such as kubectl create deployment, kubectl set image and kubectl rollout undo, finished with a small YAML edit. The domain feeds directly into Troubleshooting, where Pending Pods, CrashLoopBackOff and OOMKilled containers are usually caused by the probe, resource and scheduling settings learned here.
How it's tested
Domain 2 tasks ask you to create or change a workload so it behaves a specific way: update an image and record the rollout, roll back, mount a ConfigMap at a path, add a probe, scale on CPU, or place Pods on certain nodes. The grader inspects the object specification and the running Pods, so fields must be exact.
-
Imperative start, YAML finish
Generate a manifest with kubectl create ... --dry-run=client -o yaml, then add the field the command cannot set, such as a volume mount, probe or toleration.
-
Rollout control
Change an image, check kubectl rollout status, and return to a specific revision with kubectl rollout undo --to-revision when the new version fails.
-
Placement puzzle
Make Pods land on, or stay off, particular nodes by combining labels, node affinity, taints and tolerations, and resource requests.
A task says Pods must run only on nodes labelled disk=ssd, and one such node is tainted dedicated=db:NoSchedule. Two mechanisms are needed: node affinity (or nodeSelector) attracts Pods to disk=ssd, and a toleration for dedicated=db:NoSchedule permits the tainted node. A toleration alone does not attract Pods anywhere, and affinity alone cannot pass the taint.
Competencies 5
Official competencies from the Linux Foundation outline, in outline order.
2.1 Understand application deployments and how to perform rolling update and rollbacksDeployments, ReplicaSets, rollout strategy and revision history.
- What it means
- A Deployment manages ReplicaSets; changing the Pod template creates a new ReplicaSet and shifts Pods to it according to the strategy, either RollingUpdate (the default) or Recreate.
- What to understand
- maxSurge and maxUnavailable both default to 25% and control how many extra or missing Pods are allowed during the change. kubectl rollout history shows revisions, kubectl rollout undo returns to the previous one, and --to-revision=N selects a specific one. Only Pod template changes create a revision; scaling does not.
- How it shows up
- An image update leaves Pods in ImagePullBackOff and you must restore the last working version, or set a strategy so no Pod is ever unavailable during updates.
- Common confusion
- Expecting kubectl scale to create a new revision that rollout undo can reverse.
2.2 Use ConfigMaps and Secrets to configure applicationsInjecting configuration as environment variables or files.
- What it means
- ConfigMaps hold non-sensitive key-value data and Secrets hold sensitive data; Pods consume either through env with valueFrom, envFrom for all keys, or a volume that mounts each key as a file.
- What to understand
- Secret values are only base64 encoded in the API, not encrypted, unless encryption at rest is configured. Environment variables are fixed at container start, while mounted volumes are refreshed by the kubelet after a delay, except when mounted with subPath.
- How it shows up
- A task asks you to create a Secret from literals and expose one key as a specific environment variable name, or mount a ConfigMap read-only at a given path.
- Common confusion
- Using envFrom when the task asks for one key under a renamed variable, which needs env with secretKeyRef or configMapKeyRef.
2.3 Configure workload autoscalingScaling replicas automatically with the HorizontalPodAutoscaler.
- What it means
- The HorizontalPodAutoscaler (HPA) adjusts a workload's replica count between a minimum and maximum to hold a target metric, most often average CPU utilisation as a percentage of requests.
- What to understand
- The HPA depends on the metrics-server for resource metrics and on containers having resource requests, because utilisation is measured against the request. Create one with kubectl autoscale or an autoscaling/v2 manifest, and check it with kubectl get hpa.
- How it shows up
- You are asked to keep a Deployment between 2 and 8 replicas at 60% average CPU, and the HPA must show a real current value, not unknown.
- Common confusion
- Blaming the HPA when TARGETS shows unknown, when the cause is missing CPU requests or a missing metrics-server.
2.4 Understand the primitives used to create robust, self-healing, application deploymentsControllers, probes and restart behaviour that keep apps running.
- What it means
- Self-healing comes from controllers that replace failed Pods (Deployment, StatefulSet, DaemonSet, Job) and from the kubelet restarting containers according to restartPolicy and probe results.
- What to understand
- Liveness probe failure restarts the container, readiness probe failure removes the Pod from Service endpoints without restarting it, and a startup probe holds off the other probes until a slow application has started. Pick the controller by need: stable identity and storage per replica means StatefulSet, one Pod per node means DaemonSet, run-to-completion means Job.
- How it shows up
- A slow-starting application is killed in a restart loop and you must add the probe that stops it, or choose the controller for a per-node agent.
- Common confusion
- Using a liveness probe to keep traffic away from a warming-up Pod, which restarts it instead of simply withholding traffic.
2.5 Configure Pod admission and scheduling (limits, node affinity, etc.)Requests, limits, quotas, affinity, taints and tolerations.
- What it means
- Admission controls such as LimitRange and ResourceQuota set defaults and caps when a Pod is created, and the scheduler then places it using requests, nodeSelector, node affinity, taints and tolerations.
- What to understand
- The scheduler uses requests, not limits, to find space; at run time CPU over the limit is throttled and memory over the limit is OOMKilled. A ResourceQuota on compute resources rejects Pods that do not declare requests and limits unless a LimitRange supplies defaults. Taint effects are NoSchedule, PreferNoSchedule and NoExecute, and NoExecute also evicts running Pods that lack a toleration.
- How it shows up
- Pods must be kept off a node, placed on labelled nodes, or given defaults so they are admitted into a namespace with a quota.
- Common confusion
- Thinking a toleration attracts a Pod to the tainted node; it only permits placement there.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Rollout revisions
Every change to a Deployment's Pod template creates a new ReplicaSet and a new numbered revision.
- Remember
- kubectl rollout history deployment/NAME lists revisions, and kubectl rollout undo deployment/NAME --to-revision=N returns to one.
- Tested as
- Rollback tasks name a specific revision or the last working image.
- Trap
- Assuming scaling or label edits outside the template create revisions.
-
maxSurge and maxUnavailable
These RollingUpdate settings limit how many Pods above desired count, and how many below, may exist during an update.
- Remember
- Both default to 25%; maxUnavailable: 0 with maxSurge: 1 gives a zero-downtime update one Pod at a time.
- Tested as
- Tasks phrase this as 'never fewer than N Pods available'.
- Trap
- Setting both to 0, which the API rejects because the rollout could never progress.
-
kubectl set image
This command changes a container image in a workload's Pod template and triggers a rollout.
- Remember
- The syntax is kubectl set image deployment/NAME CONTAINER=IMAGE:TAG, and the container name must match exactly.
- Tested as
- It is the fastest way to complete image update tasks.
- Trap
- Using the Deployment name in place of the container name.
-
env vs. envFrom vs. volume
ConfigMaps and Secrets can be consumed key by key, all at once as variables, or as files.
- Remember
- env with valueFrom selects one key and lets you rename it; envFrom imports every key; a volume creates one file per key.
- Tested as
- Tasks specify a variable name or a mount path, which tells you the method.
- Trap
- Choosing envFrom when the variable must have a different name from the key.
-
Secret encoding
Secret data in manifests and the API is base64 encoded, which is reversible and not encryption.
- Remember
- Use stringData or kubectl create secret generic --from-literal to avoid encoding by hand; encryption at rest needs an EncryptionConfiguration on the API server.
- Tested as
- Questions test whether a Secret is protected by default.
- Trap
- Treating base64 as encryption.
-
HPA requirements
The HorizontalPodAutoscaler needs metrics to compare against a target.
- Remember
- metrics-server must be running and the target containers must declare CPU or memory requests for utilisation targets.
- Tested as
- An HPA showing unknown targets is a classic exam scenario.
- Trap
- Editing the HPA repeatedly instead of adding requests to the Deployment.
-
Liveness vs. readiness vs. startup
Three probe types answer different questions: is it alive, can it take traffic, has it finished starting.
- Remember
- Liveness failure restarts the container; readiness failure only removes it from endpoints; startup delays the others.
- Tested as
- Scenarios describe a symptom and ask which probe to add or fix.
- Trap
- Using liveness for a dependency check, which restarts healthy containers when the dependency is down.
-
Requests vs. limits
Requests reserve capacity for scheduling; limits cap use at run time.
- Remember
- Over the CPU limit means throttling; over the memory limit means OOMKilled, exit code 137.
- Tested as
- Pending Pods and OOMKilled containers trace back to these values.
- Trap
- Assuming the scheduler considers limits or actual usage when placing Pods.
-
Taint effects
A taint on a node repels Pods that do not tolerate it, with an effect that sets how strictly.
- Remember
- NoSchedule blocks new Pods, PreferNoSchedule avoids when possible, NoExecute also evicts running Pods; kubectl taint nodes NODE key=value:Effect- removes one.
- Tested as
- Tasks ask you to dedicate or drain a node by tainting it.
- Trap
- Adding a toleration with a different effect or value than the taint.
-
Node affinity
Node affinity selects nodes by labels with richer operators than nodeSelector.
- Remember
- requiredDuringSchedulingIgnoredDuringExecution is a hard rule; preferredDuringSchedulingIgnoredDuringExecution is a weighted preference; neither moves Pods already running.
- Tested as
- Tasks ask for hard placement or soft preference.
- Trap
- Using preferred when the task says must, which allows Pods elsewhere.
-
LimitRange and ResourceQuota
LimitRange sets per-container defaults and bounds, while ResourceQuota caps totals for a namespace.
- Remember
- With a compute quota in place, Pods without requests and limits are rejected unless a LimitRange provides defaults.
- Tested as
- Creation failures in a namespace often point to a quota.
- Trap
- Reading a 'must specify limits' error as a scheduling problem rather than admission.
-
Choosing a controller
Different controllers keep different kinds of workload running.
- Remember
- Deployment for stateless replicas, StatefulSet for stable names and per-replica storage, DaemonSet for one Pod per node, Job and CronJob for run-to-completion.
- Tested as
- Questions ask which object fits a stated requirement.
- Trap
- Using a Deployment with a node selector to emulate a per-node agent.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Liveness vs. readiness vs. startup probes
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Liveness probe | Checks whether the container should be restarted | Failure kills and restarts the container | Adding it to a slow starter without a startup probe, causing a restart loop |
| Readiness probe | Checks whether the Pod should receive Service traffic | Failure removes the Pod from endpoints; no restart | Expecting it to fix a hung process |
| Startup probe | Checks whether the application has finished starting | Disables liveness and readiness checks until it succeeds | Setting failureThreshold times periodSeconds shorter than real startup time |
nodeSelector vs. node affinity vs. taints and tolerations
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| nodeSelector | Exact label match that a node must have | Hard rule, equality only | Expecting it to support In, NotIn or preferences |
| Node affinity | Label expressions, required or preferred | Can express OR across values and soft preferences | Thinking IgnoredDuringExecution evicts Pods when labels change |
| Taint and toleration | The node repels Pods; the Pod declares what it tolerates | Pushes Pods away; a toleration only allows, never attracts | Using a toleration alone to place Pods on a dedicated node |
Requests vs. limits vs. ResourceQuota
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Requests | Amount reserved per container for scheduling | Decides whether a Pod fits on a node | Thinking a Pod is Pending because of its limits |
| Limits | Maximum a container may use | CPU is throttled, memory triggers OOMKilled | Expecting CPU over-use to kill the container |
| ResourceQuota | Namespace-wide totals for resources or object counts | Enforced at admission, before scheduling | Missing that it forces every Pod to declare the quota'd resources |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Toleration without attraction
- What candidates pick
- Adding only a toleration to place Pods on a dedicated tainted node.
- Why it looks right
- The taint was the obstacle, so tolerating it seems sufficient.
- Why it's wrong
- A toleration permits the node but does not prefer it, so Pods can still land on any untainted node.
Clue to watch for Wording such as 'only on' or 'must run on', which requires node affinity or nodeSelector as well.
-
Mismatched toleration
- What candidates pick
- Copying a toleration with a different value or effect from the taint shown in kubectl describe node.
- Why it looks right
- The key matches, and the rest looks like detail.
- Why it's wrong
- With operator Equal, key, value and effect must all match, so the Pod stays Pending.
Clue to watch for The exact taint string, for example dedicated=db:NoSchedule.
-
HPA with unknown target
- What candidates pick
- Recreating or editing the HPA when TARGETS shows unknown.
- Why it looks right
- The HPA is the object that looks broken.
- Why it's wrong
- Utilisation is computed against requests, so without CPU requests on the containers, or without metrics-server, there is nothing to compute.
Clue to watch for kubectl describe hpa events that mention missing requests or failed metrics.
-
Undo to the wrong revision
- What candidates pick
- Running kubectl rollout undo with no revision after several bad updates.
- Why it looks right
- Undo sounds like it restores the last good state.
- Why it's wrong
- It returns to the immediately previous revision, which may also be broken.
Clue to watch for A task that names a specific image or revision, which calls for rollout history and --to-revision.
-
Renamed variable via envFrom
- What candidates pick
- Using envFrom to inject a Secret when the task names a variable different from the key.
- Why it looks right
- envFrom is shorter and imports everything.
- Why it's wrong
- envFrom keeps key names, so the required variable name never exists.
Clue to watch for A sentence like 'expose key password as DB_PASS'.
-
Liveness for slow start
- What candidates pick
- Adding a liveness probe with a long initialDelaySeconds to protect a slow application.
- Why it looks right
- Delaying the probe seems to give the app time.
- Why it's wrong
- Start time varies, so a fixed delay either wastes time or still kills slow starts; the startup probe exists for this.
Clue to watch for Phrases about variable or long startup time and restart loops during start.
Answer framework
Apply this order to any workload or placement task so the object and its running Pods both match the request.
- Identify the controller and the requirement words: must versus prefer, only versus also, a named key versus all keys.
- Generate the base object imperatively with --dry-run=client -o yaml and save it to a file instead of writing YAML from nothing.
- Add the fields the command cannot set, copying exact values such as taint strings and label keys from kubectl describe output.
- Apply, then watch the result with kubectl rollout status, kubectl get pods -o wide or kubectl get hpa until it settles.
- Confirm the requirement directly, such as the node each Pod landed on, the environment variable inside a container, or the rollout revision now active.
Practice question
Want more like this? The CKA practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with Deployments and rollouts, since they underpin everything else and practise the imperative-then-YAML workflow the exam rewards. Create, update, break with a bad image, inspect history and roll back until you can do it without notes.
Next, work through configuration injection: create ConfigMaps and Secrets every way kubectl allows and consume them as single variables, all variables and files. Then add probes and resources to the same Deployment so you see restarts, endpoint changes, throttling and OOMKilled with your own eyes.
The area candidates most often underestimate is scheduling. Taints, tolerations, nodeSelector and affinity look simple on paper but fail on exact field matching, so build a small lab with labelled and tainted nodes and predict where each Pod will land before applying. Also set up an HPA on a cluster with metrics-server, then remove the requests to see the unknown target appear.
Afterwards, move to timed drills of five-minute tasks, and practise the troubleshooting side by deliberately breaking each field you learned and diagnosing it with kubectl describe.
FAQ
How much is Workloads and Scheduling worth on the CKA?
The Linux Foundation weights it at 15%. Its tasks tend to be short, so they are efficient points if your kubectl is fast.
Should I write YAML by hand?
Generate a starting manifest with kubectl create or kubectl run plus --dry-run=client -o yaml, then edit only what is missing. It is faster and avoids indentation and apiVersion errors.
What is the difference between a taint and node affinity?
A taint is set on a node and repels Pods that do not tolerate it, while node affinity is set on a Pod and attracts it to matching nodes. Dedicated nodes usually need both.
Why does my HPA show unknown?
Usually because the target containers have no resource requests or metrics-server is not running. The HPA computes utilisation as a percentage of the request, so it needs both.
Does updating a ConfigMap restart my Pods?
No. Mounted ConfigMap files are refreshed by the kubelet after a delay, unless mounted with subPath, while environment variables keep their old values until the Pod is recreated, for example with kubectl rollout restart.
Which probe should I use for a slow-starting app?
A startup probe. It holds off liveness and readiness checks until the application reports it has started, which prevents restart loops during boot.
How does this domain relate to Troubleshooting?
Most Pending, CrashLoopBackOff and OOMKilled problems in Troubleshooting come from scheduling, probe and resource settings covered here, so knowing them speeds diagnosis.
Test your Domain 2 knowledge
Practise rollouts, configuration injection and placement rules as short timed tasks, and confirm where each Pod actually landed.