Free Linux Foundation CKA practice questions

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.

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 to ensure commands operate against the correct cluster.

2. Create a ClusterRole named deployment-clusterrole that permits only the create verb on Deployment, StatefulSet, and DaemonSet resources.

3. Create a ServiceAccount named cicd-token in the app-team1 namespace to represent the identity for the deployment pipeline.

4. Create a RoleBinding named deploy-b in the app-team1 namespace that binds deployment-clusterrole to the cicd-token ServiceAccount, scoping the permissions to that namespace.

The solution establishes RBAC by first ensuring the correct cluster context is active. It then creates a ClusterRole with granular permissions limited to the create action on only the three specified resource types. A ServiceAccount is created within the app-team1 namespace to represent the CI/CD pipeline identity. Finally, a namespaced RoleBinding connects the ClusterRole to the ServiceAccount, scoping the cluster-level role permissions to only the app-team1 namespace. This prevents the service account from having create permissions beyond app-team1 and limits it to only the resource types needed for deployments.

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 –force

Step 4 → kubectl get nodes

How To Work It Out

1. Switch to the ek8s context to ensure all subsequent kubectl commands target the correct cluster.

2. Verify the current state of all nodes and confirm which one needs to be drained.

3. Drain the node using kubectl drain with both –ignore-daemonsets to skip DaemonSet pods and –delete-emptydir-data to remove pods with local storage, forcing rescheduling.

4. Confirm the node is cordoned and all workload pods have been evicted to other nodes.

The task requires making a node unavailable and rescheduling its pods. First, the correct context (ek8s) must be set. The kubectl drain command cordons the node (marking it unschedulable) and evicts all pods except those managed by DaemonSets. The –ignor
-aemonsets flag allows system pods to remain, while –delete-emptydir-data overrides the default safety check that prevents deletion of pods using local storage, ensuring all workload pods are successfully rescheduled to other available nodes. The final verification confirms the node is in the desired state and pods have migrated.

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

Given an existing Kubernetes cluster running version 1.22.1, upgrade all of the Kubernetes control plane and node components on the master node only to version 1.22.2.

Be sure to drain the master node before upgrading it and uncordon it after the upgrade.

You are also expected to upgrade kubelet and kubectl on the master node.

Completed Answer

Drain the master node, upgrade kubeadm/kubelet/kubectl and the control plane on mk8
-aster-0 to v1.22.2, then uncordon the node.

Step 1 – set context → kubectl config use-context mk8s

Step 2 – list cluster nodes → kubectl get nodes

Step 3 – evacuate the master → kubectl drain mk8s-master-0 –ignor
-aemonsets

Step 4 – verify SchedulingDisabled → kubectl get nodes

Step 5 – connect to master node → ssh mk8s-master-0

Step 6 – elevate privileges → sudo -i

Step 7 – install packages → apt-mark unhold kubeadm kubelet kubectl && apt-get update && apt-get install -y kubeadm=1.22.2-00 kubelet=1.22.2-00 kubectl=1.22.2-00

Step 8 – review upgrade options → kubeadm upgrade plan

Step 9 – upgrade control plane → kubeadm upgrade apply v1.22.2

Step 10 – restart node agent → systemctl restart kubelet

Step 11 – leave root shell → exit

Step 12 – leave ssh session → exit

Step 13 – return node to service → kubectl uncordon mk8s-master-0

Step 14 – confirm new version → kubectl get nodes

How To Work It Out

1. Switch kubectl to the mk8s context and list the nodes so you can confirm both nodes are running v1.22.1 before touching anything.

2. Drain mk8s-master-0 with –ignore-daemonsets so workloads are evicted while DaemonSet pods such as kube-flannel and kube-proxy are tolerated; a second kubectl get nodes confirms the node now shows Ready,SchedulingDisabled.

3. SSH to mk8s-master-0 and run sudo -i because package installation and kubeadm both require root on the master itself.

4. Install the exact pinned packages kubeadm=1.22.2-00 kubelet=1.22.2-00 kubectl=1.22.2-00, since the task explicitly asks for 1.22.2 and for kubelet and kubectl to be upgraded too.

5. Run kubeadm upgrade plan to validate the cluster, then kubeadm upgrade apply v1.22.2 to upgrade the static control-plane pods, and restart kubelet so the new binary is picked up; note the target must be v1.22.2, not the newest v1.22.9 offered.

6. Exit back to node-1, uncordon mk8s-master-0 to make it schedulable again, and r
-un kubectl get nodes, which now shows mk8s-master-0 at v1.22.2 while mk8s-node-0 stays at v1.22.1 as required.

The upgrade follows the standard kubeadm procedure applied to a single control-plane node. Work starts from node-1 with the mk8s context selected, where the master is drained so no workloads run on it during the upgrade; –ignore-daemonsets is required because DaemonSet pods cannot be evicted. Then you connect to the master over SSH and become root, because the kubeadm, kubelet and kubectl packages live on that host and must be replaced with the pinned 1.22.2-00 versions. kubeadm upgrade plan checks cluster health and lists targets, but the task requires v1.22.2 specifically, so kubeadm upgrade apply v1.22.2 is used rather than the newest 1.22.9 shown in the plan output. Restarting kubelet loads the newly installed binary, and after leaving the master the node is uncordoned so scheduling resumes. The closing kubectl get nodes proves the goal: mk8s-master-0 reports v1.22.2 while the worker node remains at v1.22.1, since worker nodes, etcd, CNI and addons must not be touched.

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

First, create a snapshot of the existing etcd instance running at https://127.0.0.1:2379, saving the snapshot to /var/lib/backup/etcd-snapshot.db.

Next, restore an existing, previous snapshot located at /var/lib/backup/etcd-snapsho
-revious.db.

Completed Answer

Use etcdctl with the supplied TLS certificates to save a snapshot of the running etcd instance and then restore the previously supplied snapshot file.

Command 1 (snapshot save) → ETCDCTL_API=3 etcdctl –endpoints=https://127.0.0.1:2379 –cacert=/opt/KUIN00601/ca.crt

–cert=/opt/KUIN00601/etcd-client.crt –key=/opt/KUIN00601/etcd-client.key snapshot save /var/lib/backup/etcd-snapshot.db

Command 2 (verify snapshot) → ETCDCTL_API=3 etcdctl –endpoints=https://127.0.0.1:2379 –cacert=/opt/KUIN00601/ca.crt –cert=/opt/KUIN00601/etcd-client.crt –key=/opt/KUIN00601/etcd-client.key snapshot status /var/lib/backup/etcd-snapshot.db

Command 3 (stop service) → sudo systemctl stop etcd.service

Command 4 (restore snapshot) → sudo mv /var/lib/etcd /var/lib/etcd.old && sudo ETCDCTL_API=3 etcdctl snapshot restore –data-dir=/var/lib/etcd /var/lib/backup/etcd-snapshot-previous.db

Command 5 (restart service) → sudo systemctl restart etcd.service

How To Work It Out

1. Exit any node shell so the commands run on the base node, as the task notes no context change is needed.

2. Export ETCDCTL_API=3 and point etcdctl at the endpoint https://127.0.0.1:2379 while supplying the CA certificate, client certificate and client key from /opt/KUIN00601 so the TLS-protected etcd API accepts the connection.

3. Run snapshot save with the backup file path to write the point-in-time database copy, which should finish in seconds.

4. Confirm the backup is readable by running snapshot status against the same file, which prints the hash, revision, keys and size.

5. Stop etcd, move the old /var/lib/etcd aside, restore the previous snapshot into –data-dir=/var/lib/etcd, then restart etcd on the restored data.

etcd is served over TLS, so every etcdctl call against the live cluster must set ETCDCTL_API=3 and pass the CA certificate, client certificate and client key given in the task, together with the endpoint https://127.0.0.1:2379. With those flags the snapshot save subcommand streams a consistent copy of the key-value store into the backup file, and the operation completes almost immediately; if it hangs, a flag or path is wrong. Running snapshot status on the resulting file is a quick sanity check that the backup is complete and readable, showing its hash, revision count, key count and size. Restoring is a different operation: it rebuilds a data directory from a snapshot file offline, so etcd must be stopped first, the restore run with sudo against the previous snapshot, and the service restarted afterwards so the API server talks to the recovered database.

Show answer and explanation

The answer and explanation for this question are in the free sample PDF.