4 free Linux Foundation CKA practice tasks from the CertStash pack of 40, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 4 free here, all 40 in the pack, and each step includes the one before it.
Get all 40 tasks (US$39) · Download the first 10 as a PDF · Read the study guide
Question 1
Show the case study this question is based on
SIMULATION
Context
You have been asked to create a new ClusterRole for a deployment pipeline and bind it to a specific ServiceAccount scoped to a specific namespace.
Task
Create a new ClusterRole named deployment-clusterrole, which only allows to create the following resource types:
• Deployment
• Stateful Set
• DaemonSet
Create a new ServiceAccount named cicd-token in the existing namespace app-team1.
Bind the new ClusterRole deployment-clusterrole to the new ServiceAccount cicd-token, limited to the namespace app-team1.
Completed Answer
Create a ClusterRole with specific resource permissions, a ServiceAccount in a namespace, and bind them with a RoleBinding in that namespace.
Step 1 → kubectl config use-context k8s
Step 2 → kubectl create clusterrole deployment-clusterrole --verb=create --resource=Deployment,StatefulSet,DaemonSet
Step 3 → kubectl create sa cicd-token --namespace app-team1
Step 4 → kubectl create rolebinding deploy-b -n app-team1 --clusterrole=deployment-clusterrole --serviceaccount=app-team1:cicd-token
How To Work It Out
1. Switch to the k8s context so the commands run against the correct cluster.
2. Create the ClusterRole deployment-clusterrole with only the create verb on Deployment, StatefulSet and DaemonSet.
3. Create the ServiceAccount cicd-token in the app-team1 namespace.
4. Bind the ClusterRole with a RoleBinding named deploy-b created in app-team1, so the permissions apply only in that namespace.
A ClusterRole can be granted in two ways: a ClusterRoleBinding applies it in every namespace, while a RoleBinding applies it only in the namespace where the RoleBinding lives. Because the task limits the binding to app-team1, the RoleBinding is created with -n app-team1 and points at the ClusterRole and the app-team1:cicd-token ServiceAccount. The ServiceAccount can then create Deployments, StatefulSets and DaemonSets in app-team1 and nowhere else.
Show answer and explanation
The answer and explanation for this question are in the free sample PDF.
Question 2
SIMULATION
Task
Set the node named ek8s-node-0 as unavailable and reschedule all the pods running on it.
Completed Answer
Set the node named ek8s-node-0 as unavailable and reschedule all the pods running on it.
Step 1 → kubectl config use-context ek8s
Step 2 → kubectl get nodes
Step 3 → kubectl drain ek8s-node-0 --ignore-daemonsets --delete-emptydir-data
Step 4 → kubectl get nodes
How To Work It Out
1. Switch to the ek8s context.
2. List the nodes and find ek8s-node-0.
3. Drain ek8s-node-0 with --ignore-daemonsets and --delete-emptydir-data so it is cordoned and its pods are evicted.
4. Run kubectl get nodes to confirm ek8s-node-0 shows SchedulingDisabled.
kubectl drain first cordons the node, marking it unschedulable, and then evicts its pods so their controllers recreate them on other nodes. The node to drain is ek8s-node-0, the one the task names. --ignore-daemonsets lets the drain proceed past DaemonSet pods, and --delete-emptydir-data allows eviction of pods that use emptyDir storage.
Show answer and explanation
The answer and explanation for this question are in the free sample PDF.
Question 3
Show the case study this question is based on
SIMULATION
Task
The platform team publishes cluster components in an internal Helm chart repository. Use Helm to install the metrics gateway component as follows:
• Repository name: platform
• Repository URL: https://charts.example.internal/stable
• Chart: metrics-gateway
• Release name: gateway
• Namespace: observability (it does not exist yet and must be created by the installation)
• Value override: set the chart value replicaCount to 2 on the command line, without a values file
Verify that the release is deployed in the observability namespace and that the override is recorded for the release.
Completed Answer
Add the internal platform chart repository, install chart metrics-gateway as release gateway into the new namespace observability with replicaCount set to 2, and verify the release and its values.
Add the chart repository → helm repo add platform https://charts.example.internal/stable
Refresh the repository index → helm repo update
Install the release → helm install gateway platform/metrics-gateway --namespace observability --create-namespace --set replicaCount=2
Verify the release → helm list -n observability
Verify the override → helm get values gateway -n observability
Verify the Pods → kubectl get pods -n observability
How To Work It Out
1. Register the internal repository under the name platform with helm repo add, giving the name first and the URL second.
2. Run helm repo update so the local index lists the current version of the metrics-gateway chart.
3. Install release gateway from the chart reference platform/metrics-gateway, adding --namespace observability, --create-namespace because the namespace is missing, and --set replicaCount=2 for the override.
4. Run helm list -n observability and confirm that release gateway shows the status deployed.
5. Run helm get values for the release to confirm the user-supplied value replicaCount: 2, then list the Pods in observability to see the component start.
helm repo add stores the repository name and URL in the local Helm configuration, and helm repo update downloads its current chart index, so the reference platform/metrics-gateway resolves to the latest stable chart in that repository. helm install takes the release name first and the chart second. --namespace places the release and its objects in observability, and --create-namespace creates that namespace because it is not present. --set overrides one chart value on the command line, and Helm stores the override with the release, which is why helm get values shows replicaCount: 2. The same commands and flags work in Helm 3 and Helm 4.
Show answer and explanation
The answer and explanation for this question are in the free sample PDF.
Question 4
Show the case study this question is based on
SIMULATION
Task
In a kubeadm cluster with the control-plane node cp-node-1 and the worker nodes wk-node-1 and wk-node-2, every Pod created since this morning stays Pending and is never assigned to a node. You can reach cp-node-1 with ssh and run root commands there with sudo.
An administrator changed the value of the --kubeconfig flag in the kube-scheduler static Pod manifest on cp-node-1, and since then the kube-scheduler container exits shortly after it starts. Confirm the failure from the scheduler's container output, then restore the flag so that it points to the kubeconfig file that kubeadm generated for the scheduler. Do not change any other setting and do not leave extra files in the manifest directory.
Verify that the scheduler runs again and that the waiting Pods are assigned to nodes.
Completed Answer
Find why kube-scheduler on cp-node-1 keeps exiting, point its --kubeconfig flag back to /etc/kubernetes/scheduler.conf in the static Pod manifest, and confirm that Pending Pods are scheduled.
Check the control-plane Pods → kubectl get pods -n kube-system
Read the failed container output → kubectl logs -n kube-system kube-scheduler-cp-node-1 --previous
Connect to the control-plane node → ssh cp-node-1
Inspect the kubeconfig flags → sudo grep kubeconfig /etc/kubernetes/manifests/kube-scheduler.yaml
Fix the --kubeconfig flag → sudo sed -Ei 's#(--kubeconfig=).*#\1/etc/kubernetes/scheduler.conf#' /etc/kubernetes/manifests/kube-scheduler.yaml
Watch the scheduler container → sudo crictl ps -a
Leave the node → exit
Verify Pods are scheduled → kubectl get pods -A -o wide
How To Work It Out
1. List the Pods in kube-system and note that the mirror Pod kube-scheduler-cp-node-1 is failing and restarting instead of Running.
2. Read the output of the last failed scheduler container with kubectl logs --previous to see that it stops while loading its kubeconfig file.
3. Connect to cp-node-1 over ssh and display the kubeconfig lines of /etc/kubernetes/manifests/kube-scheduler.yaml to find the wrong path on the --kubeconfig line.
4. Rewrite only the --kubeconfig line in place with sed so it points to /etc/kubernetes/scheduler.conf, without creating a backup copy in the manifest directory.
5. Run crictl ps -a on the node until a new kube-scheduler container shows Running, then exit the ssh session.
6. List all Pods with -o wide and confirm that the Pods that were Pending now show a node in the NODE column.
kubeadm runs kube-scheduler as a static Pod: the kubelet on cp-node-1 creates it from /etc/kubernetes/manifests/kube-scheduler.yaml and publishes a mirror Pod in kube-system, so kubectl can show its status and logs, but the fix must be made in the file on the node. With --kubeconfig naming the wrong file, the scheduler cannot reach the API server, no Pod gets a node, and new Pods stay Pending. sed rewrites only that flag to /etc/kubernetes/scheduler.conf, the scheduler kubeconfig kubeadm generates. The kubelet watches the directory for changes and restarts the Pod, and editing in place leaves no second manifest for the kubelet to load.
Show answer and explanation
The answer and explanation for this question are in the free sample PDF.
That was 4 of 40.
The full Linux Foundation CKA pack has all 40 tasks, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.
Not ready yet? Get the first 20 free as one PDF by email. Get the Half Pack →
What people say about the full CKA pack 4.5 from 20
Passed the CKA! This is a practical exam so having seen the question types beforehand really helped with pacing. A lot of familiar content on exam day. Highly recommend.
Cleared the CKA! The dump covers the real exam well. Went through it twice and passed on first attempt.
I passed the CKA exams with over 92% marks today.