CKA Cluster Architecture, Installation and Configuration Practice Test 4 — 15 Questions

Question 1

A kubeadm cluster is being upgraded from v1.28 to v1.29. You have upgraded the control plane components on the first master node. What is the NEXT step according to the recommended upgrade procedure?

Accepted Answer

Upgrade the remaining control plane nodes. After upgrading the control plane components on the first master node in a kubeadm cluster, the next step is to upgrade the remaining control plane nodes. The kubeadm upgrade procedure requires upgrading all control plane nodes before any worker nodes, because the control plane must be fully upgraded to v1.29 to ensure API server compatibility and etcd cluster consistency. Skipping to worker nodes or draining the first node prematurely would violate the upgrade order specified in the official Kubernetes upgrade documentation.

Answer

Drain the first node

Answer

Upgrade the worker nodes

Answer

Run kubeadm upgrade plan

Question 2

Which command is used to prevent a node from being scheduled with new pods?

Accepted Answer

kubectl cordon . The `kubectl cordon ` command marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the standard Kubernetes command for this purpose, directly setting the `spec.unschedulable` field to `true` on the node object.

Answer

kubectl taint <node> key=value:NoSchedule

Answer

kubectl patch node <node> -p '{"spec":{"unschedulable":true}}'

Answer

kubectl drain <node>

Question 3

A ClusterRole named 'pod-reader' grants get, list, watch on pods. You want to bind it to a user 'john' cluster-wide. Which resource should you create?

Accepted Answer

ClusterRoleBinding. A ClusterRoleBinding is the correct resource because it grants cluster-wide permissions to a user. While a ClusterRole defines the permissions (get, list, watch on pods), a ClusterRoleBinding binds that ClusterRole to a subject (user 'john') across all namespaces. This is the only way to achieve cluster-scoped authorization in Kubernetes RBAC.

Answer

Role

Answer

RoleBinding in default namespace

Answer

ClusterRole

Question 4

During a cluster upgrade using kubeadm, after upgrading kubeadm on the node, which command upgrades the kubelet configuration?

Accepted Answer

kubeadm upgrade node config --kubelet-version v1.29.0. After upgrading kubeadm on the node, the correct command to upgrade the kubelet configuration is `kubeadm upgrade node config --kubelet-version v1.29.0`. This command updates the kubelet configuration file (typically `/var/lib/kubelet/config.yaml`) to match the target Kubernetes version, ensuring the kubelet can join the upgraded control plane. It is a specific subcommand of `kubeadm upgrade node` that handles only the kubelet configuration, not the kubelet binary itself.

Answer

kubectl upgrade node kubelet

Answer

kubeadm upgrade apply --kubelet-version v1.29.0

Answer

systemctl restart kubelet

Question 5

Which THREE are valid methods to restore an etcd cluster from a snapshot? (Select 3)

Accepted Answer

Restore snapshot on a new node and add it as a member, then remove old. Option A is correct because etcd snapshot restore can be performed on a new node whose restored data directory is configured with a new member name and peer URLs, then the node is added to the cluster and the old failed member is removed with etcdctl member remove. Option C is correct because the etcdctl snapshot restore command with --data-dir creates a new etcd data directory from the snapshot, which is the standard offline restore procedure. Option D is correct because after restoring the snapshot to a data directory, you stop etcd, point its data-dir to the restored directory (or replace the contents of /var/lib/etcd), and start etcd so it serves the restored state. Option B is not a snapshot restore method; kubeadm reset and re-init rebuilds the control plane but does not restore etcd data from a snapshot. Option E is invalid because a snapshot is an etcd database file, not a Kubernetes manifest, so kubectl apply cannot restore it.

Answer

kubeadm reset and re-init

Answer

kubectl apply -f snapshot.yaml

Question 6

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff with an OOMKilled message, which indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being killed by the Out-Of-Memory (OOM) killer.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy all workloads

Question 7

You need to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. Which TWO steps are REQUIRED as part of the upgrade process? (Choose TWO.)

Accepted Answer

Upgrade the control plane nodes first. Option B is correct because kubeadm upgrades must always start with the control plane nodes: you upgrade the first control plane node, then the remaining control plane nodes, and only then the worker nodes, since the newer kubelet on workers must not be ahead of the API server. Option C is correct because each node must be drained (e.g., 'kubectl drain <node> --ignore-daemonsets') before its kubelet/kubeadm packages are upgraded, so workloads are evicted and rescheduled elsewhere, avoiding disruption during the node's upgrade and reboot. Option A is not required — 'kubeadm upgrade plan' is a recommended informational check, not a mandatory step. Option D is wrong because kubeadm and kubelet are upgraded in separate steps (kubeadm first, then kubelet/kubectl), not simultaneously. Option E is wrong because upgrading all nodes at once would cause cluster-wide downtime and is explicitly contrary to the node-by-node rolling upgrade procedure.

Answer

Run 'kubeadm upgrade plan' before upgrading

Answer

Upgrade kubelet and kubeadm on the node at the same time

Answer

Upgrade all nodes simultaneously to minimize downtime

Question 8

Which TWO commands are used to set the current context in kubeconfig? (Choose TWO.)

Accepted Answer

kubectl config use-context . Option B, `kubectl config use-context `, is correct because it is the dedicated kubectl subcommand that writes the named context into the `current-context` field of the kubeconfig file, immediately switching the active context for subsequent commands. Option C, editing the `current-context` field in the kubeconfig file manually, is also correct because the current context is simply the value of that YAML field; changing it directly (and saving the file) sets the current context just as effectively, which is why tools and scripts sometimes do this. Option A, `kubectl config current-context`, is not correct because it only reads and prints the currently active context name rather than setting it. Option D, `kubectl set-context `, is not correct because `set-context` creates or modifies a context's properties (cluster, user, namespace) and does not change which context is current. Option E, `kubectl config get-contexts`, is not correct because it merely lists the available contexts and indicates the current one with an asterisk, without changing the current context.

Answer

kubectl config current-context

Answer

kubectl set-context <context-name>

Answer

kubectl config get-contexts

Question 9

A CKA candidate is troubleshooting a control plane node that was upgraded using kubeadm from v1.28 to v1.29. After the upgrade, the kube-apiserver pod fails to start. Which TWO actions should the candidate take to diagnose and resolve the issue? (Select TWO.)

Accepted Answer

Run 'kubeadm upgrade apply v1.29.0' again after resetting the node with 'kubeadm reset'. Option A is correct because if the kubeadm upgrade apply v1.29.0 failed partway through, the control plane components may be in an inconsistent state; running kubeadm reset cleans up the node's Kubernetes state, and re-running kubeadm upgrade apply v1.29.0 ensures the control plane manifests and static pod definitions are correctly regenerated for v1.29.0, which can resolve a kube-apiserver that fails to start due to a botched upgrade. Option D is correct because the kube-apiserver runs as a static pod managed by the kubelet, so journalctl -u kubelet on the control plane node reveals kubelet errors such as failed container starts, image pull issues, or manifest parsing problems that explain why the kube-apiserver pod is not coming up. Option B is wrong because etcd should be upgraded alongside Kubernetes, not downgraded to a 1.28-compatible version, and a downgrade would not fix an apiserver startup failure. Option C is wrong because upgrading worker nodes is unrelated to diagnosing a control plane apiserver failure and would not resolve it. Option E is wrong because kubeadm upgrade plan only checks available versions and upgrade feasibility; it does not diagnose or fix an already-failed apiserver pod.

Answer

Downgrade etcd to a version compatible with Kubernetes 1.28

Answer

Immediately upgrade the worker nodes to match the control plane version

Answer

Run 'kubeadm upgrade plan' to verify the target version

Question 10

You are using kubeadm to upgrade a control-plane node from Kubernetes v1.28.0 to v1.29.0. After running `kubeadm upgrade plan`, you need to apply the upgrade. Which sequence of commands correctly upgrades the control-plane node?

Accepted Answer

`kubectl drain --ignore-daemonsets` then upgrade kubeadm package to v1.29.0 then `kubeadm upgrade apply v1.29.0` then upgrade kubelet and kubectl packages then `systemctl restart kubelet` then `kubectl uncordon `.. The correct order is to drain the node first, then upgrade the kubeadm binary, apply the control-plane upgrade, upgrade kubelet and kubectl, restart kubelet, and uncordon. This ensures workloads are safely evicted and version skew is avoided.

Answer

Upgrade kubelet and kubectl packages first, then `kubeadm upgrade apply v1.29.0`, then `kubectl drain --ignore-daemonsets`, then `systemctl restart kubelet`, then `kubectl uncordon `.

Answer

`kubeadm upgrade apply v1.29.0` then upgrade kubelet and kubectl packages then `systemctl restart kubelet` then `kubectl drain --ignore-daemonsets` then `kubectl uncordon `.

Answer

`kubeadm upgrade apply v1.29.0` then `kubectl drain --ignore-daemonsets` then upgrade kubelet and kubectl packages then `systemctl restart kubelet` then `kubectl uncordon `.

Question 11

You are configuring a new Kubernetes cluster with kubeadm and want to use a specific container runtime. You have installed containerd and configured the systemd cgroup driver. Which TWO steps are required to ensure kubelet uses containerd as the container runtime? (Choose two.)

Accepted Answer

Set the `--container-runtime-endpoint` flag in the kubelet configuration to `unix:///run/containerd/containerd.sock`.. To use containerd as the container runtime, kubelet must be configured with the correct CRI endpoint and the systemd cgroup driver to match containerd's configuration. These two settings ensure proper communication and resource management.

Answer

Run `kubeadm init --cri-socket unix:///run/containerd/containerd.sock` to specify the container runtime socket.

Answer

Set the environment variable `KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=unix:///run/containerd/containerd.sock` in /etc/default/kubelet.

Answer

Install the `cri-tools` package and run `crictl config --set runtime-endpoint=unix:///run/containerd/containerd.sock`.

Question 12

Which control plane component is responsible for storing the cluster state and configuration?

Accepted Answer

etcd. etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

Answer

kube-controller-manager

Answer

kube-apiserver

Answer

kube-scheduler

Question 13

An administrator creates a ServiceAccount named 'monitor' in the 'default' namespace. They want any pod using this ServiceAccount to be able to list pods cluster-wide. Which RBAC resource should be created and bound to this ServiceAccount?

Accepted Answer

ClusterRole and ClusterRoleBinding. A ClusterRole is required because listing pods cluster-wide is a cluster-scoped operation, not limited to a single namespace. A ClusterRoleBinding is needed to bind the ClusterRole to the ServiceAccount 'monitor' at the cluster level, granting permissions across all namespaces. RoleBindings can only grant permissions within a single namespace, so they cannot achieve cluster-wide access.

Answer

ClusterRole and RoleBinding in the default namespace

Answer

ClusterRole and RoleBinding in kube-system

Answer

Role and RoleBinding in the default namespace

Question 14

You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?

Accepted Answer

kubeadm upgrade plan. After upgrading kubeadm on the control plane node, the first command to run is `kubeadm upgrade plan`. This command checks the current cluster version, validates that the upgrade path is supported (e.g., from v1.28.0 to v1.29.0), and displays the available versions to upgrade to, along with any manual steps required. It is a prerequisite to ensure the upgrade is safe before proceeding with `kubeadm upgrade apply`.

Answer

kubeadm upgrade apply v1.29.0

Answer

kubeadm upgrade node

Answer

kubeadm upgrade diff

Question 15

Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in PodSpecs are running and healthy by communicating with the container runtime via the CRI (Container Runtime Interface). Without the kubelet, no pod or container lifecycle management can occur on that node.

Answer

kube-scheduler

Answer

container runtime

Answer

kube-proxy