CKA Cluster Architecture, Installation & Configuration Practice Test 2 — 15 Questions

Question 1

You are a cluster administrator managing a multi-node Kubernetes cluster version 1.22. The cluster runs critical applications in the 'production' namespace. You have been asked to upgrade the control plane node to version 1.23 while minimizing downtime. The cluster uses a single control plane node (not HA). You have already backed up etcd and verified the backup is valid. You have also reviewed the upgrade notes and there are no breaking changes that affect your workloads.

You have drained the control plane node and ensured all pods are evicted. The node is now in 'Ready,SchedulingDisabled' state. You then run 'kubeadm upgrade plan' and see that upgrade to v1.23.0 is available. Next, you run 'kubeadm upgrade apply v1.23.0'. The command completes successfully. However, when you try to uncordon the node with 'kubectl uncordon <node>', you get an error: 'error: unable to update node: the object has been modified; please apply your changes to the latest version and try again'. What is the most likely cause and the correct next step?

Accepted Answer

Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.. The error 'the object has been modified' indicates a resource conflict due to concurrent updates to the node object, typically from the kubelet or controller manager updating the node status simultaneously. This is a transient optimistic locking conflict in Kubernetes, and simply retrying the 'kubectl uncordon' command will resolve it because the conflict is temporary and the node is already upgraded and ready to be scheduled.

Answer

Re-drain the node to reset its state, then uncordon again.

Answer

Restart the kubelet on the control plane node to refresh the node object.

Answer

Generate a new bootstrap token and rejoin the node to the cluster.

Question 2

A Kubernetes cluster has three control plane nodes and five worker nodes. The kube-apiserver is failing to start on one control plane node with the error 'etcdserver: request timed out'. The etcd cluster is healthy with three members. Which of the following is the most likely cause?

Accepted Answer

A firewall is blocking traffic on port 2379 between the control plane and etcd. The error 'etcdserver: request timed out' indicates that the kube-apiserver cannot establish a TCP connection to the etcd cluster within the timeout period. Since the etcd cluster is healthy with three members and leader election is functioning, the most likely cause is a firewall blocking port 2379 (the etcd client port) between the control plane node and the etcd members. This prevents the kube-apiserver from communicating with etcd, even though the etcd cluster itself is operational.

Answer

The etcd cluster has a leader election issue

Answer

The kube-apiserver is using the wrong etcd client port (2380 instead of 2379)

Answer

The etcd client certificate is expired

Question 3

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

Accepted Answer

kubeadm init --pod-network-cidr=10.244.0.0/16. Option A is correct because `kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Answer

kubeadm init --cidr=10.244.0.0/16

Answer

kubeadm init --network-cidr=10.244.0.0/16

Answer

kubeadm init --service-cidr=10.244.0.0/16

Question 4

Which TWO of the following are valid methods to add a worker node to an existing Kubernetes cluster that was initialized with kubeadm?

Accepted Answer

Use kubeadm token create and then kubeadm join with the token. Option A is correct because `kubeadm token create` generates a bootstrap token that is used by `kubeadm join` to authenticate the new node with the control plane. This is the standard, documented method for adding worker nodes to a cluster initialized with kubeadm, leveraging TLS bootstrap and the Bootstrap Token Authentication protocol.

Answer

Use kubectl create node command from the control plane

Answer

Install kubelet on the worker node and it will automatically join the cluster

Answer

Run kubeadm init on the worker node and then join

Question 5

Based on the exhibit, what is the most likely cause of the worker2 node being NotReady?

Accepted Answer

The kubelet on worker2 has stopped reporting to the control plane. The kubelet on worker2 has stopped reporting to the control plane, which is the most likely cause of the node being NotReady. The kubelet is responsible for periodically posting node status updates (including heartbeats) to the API server via the NodeStatus update mechanism. If the kubelet process is down, unresponsive, or cannot communicate with the control plane (e.g., due to network partition or certificate expiry), the node controller marks the node as NotReady after the `node-monitor-grace-period` (default 40 seconds) elapses.

Answer

The node has insufficient memory

Answer

The node is experiencing disk pressure

Answer

The network plugin (Calico) is not running on worker2

Question 6

You are tasked with upgrading a Kubernetes cluster from version 1.24 to 1.25. The cluster has one control plane node and three worker nodes, all running Ubuntu 20.04 with kubeadm. You have already upgraded the control plane node to v1.25.0 and it is healthy. You now need to upgrade the first worker node. On the worker node, you run 'kubeadm upgrade node' and it completes successfully. However, when you run 'kubectl drain worker1 --ignore-daemonsets', the node drain hangs indefinitely. You check the node and find that a DaemonSet pod named 'fluentd-*' is stuck in Terminating state. The DaemonSet is from the logging system and must remain running during the upgrade. You cannot delete the DaemonSet. What is the best course of action to complete the upgrade of this worker node?

Accepted Answer

Cordon the node and then run kubectl drain with --force. Option D is correct because the drain is hanging due to a DaemonSet pod stuck in Terminating state. Since DaemonSets are managed by the node controller and cannot be evicted by a normal drain, using `--force` bypasses the preflight checks that prevent drain when pods are not evictable. Cordoning the node first ensures no new workloads are scheduled, and `--force` allows the drain to proceed despite the stuck pod, which will be replaced by the DaemonSet controller on the upgraded node.

Answer

Reinstall kubelet on the worker node and restart it

Answer

Skip draining the node and proceed with the kubelet upgrade

Answer

Add --delete-emptydir-data to the drain command

Question 7

A system administrator needs to install a Kubernetes cluster using kubeadm. The control plane node must be initialized with a specific Pod network CIDR of 10.244.0.0/16 for Flannel. Which command should be used?

Accepted Answer

kubeadm init --pod-network-cidr 10.244.0.0/16. Option B is correct because `kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for Pod IP addresses, which is required by Flannel and other CNI plugins to allocate subnets to nodes. The 10.244.0.0/16 range is the default Pod network CIDR for Flannel, ensuring proper network configuration without conflicts.

Answer

kubeadm init --service-cidr 10.244.0.0/16

Answer

kubeadm init --network-cidr 10.244.0.0/16

Answer

kubeadm init --apiserver-advertise-address 10.244.0.0

Question 8

A Kubernetes cluster is running with a single control plane node. The administrator wants to add a second control plane node for high availability. What is the first step after the new node has been provisioned with the required software?

Accepted Answer

Run kubeadm join with the --control-plane flag on the new node.. Option B is correct because the first step to add a second control plane node to an existing cluster is to run `kubeadm join` with the `--control-plane` flag on the new node. This command uses the existing control plane's API server to join the new node as a control plane member, automatically distributing certificates and configuring the etcd cluster. The `--control-plane` flag signals kubeadm to set up the additional control plane components (e.g., kube-apiserver, kube-controller-manager, kube-scheduler) and join the etcd cluster as a learner or voting member, depending on the etcd configuration.

Answer

Create a bootstrap token on the existing control plane node.

Answer

Run kubeadm init on the new node.

Answer

Take a snapshot of etcd using etcdctl.

Question 9

A cluster administrator notices that nodes are not joining the cluster after a kubeadm init. The kubelet logs show: 'failed to run Kubelet: could not init service: open /var/lib/kubelet/config.yaml: permission denied'. What is the most likely cause?

Accepted Answer

The kubelet configuration file has incorrect ownership or permissions.. The error message 'open /var/lib/kubelet/config.yaml: permission denied' indicates that the kubelet process does not have the necessary read permissions to access its configuration file. This is typically caused by incorrect file ownership (e.g., owned by root instead of the kubelet user) or restrictive file permissions (e.g., 600 instead of 644). Since kubelet runs as a systemd service, it requires appropriate access to this file to initialize properly.

Answer

The kubelet is running out of disk space.

Answer

The kubelet is not able to reach the API server.

Answer

The kubelet binary is missing.

Question 10

A DevOps engineer is designing a Kubernetes cluster for a production environment. Which of the following is a best practice for etcd deployment?

Accepted Answer

Deploy etcd on dedicated nodes with SSD storage.. Option C is correct because etcd is the Kubernetes cluster's primary data store, and its performance directly impacts the entire cluster's stability and responsiveness. Dedicated nodes prevent resource contention from other workloads, while SSD storage provides the low-latency, high-IOPS performance required for etcd's frequent write operations (especially with the default 1 MB write-ahead log). This isolation is a recommended best practice in the official Kubernetes documentation for production clusters.

Answer

Deploy etcd on exactly 2 nodes for simplicity.

Answer

Deploy etcd on all worker nodes to maximize redundancy.

Answer

Deploy etcd on the same nodes as GPU-accelerated workloads.

Question 11

Drag and drop the steps to create a Kubernetes cluster using kubeadm into the correct order.

Question 12

Drag and drop the steps to deploy an application using a Deployment and expose it with a Service into the correct order.

Question 13

Match each Kubernetes resource to its primary function.

Question 14

Match each security context setting to its effect.

Question 15

Refer to the exhibit. A Kubernetes cluster was initialized using kubeadm with the command shown. After initialization, the cluster nodes are in NotReady state. Which is the most likely missing step?

Accepted Answer

Install a pod network add-on such as Flannel.. The kubeadm init command only initializes the control plane. To make the nodes ready, a pod network must be installed. The exhibit shows no pod network add-on being applied, and the --pod-network-cidr flag indicates a specific CIDR for the pod network (10.244.0.0/16) which is typically used with Flannel. Without installing a CNI plugin, nodes remain NotReady.

Answer

Increase the apiserver-advertise-address to match the node's external IP.

Answer

Run kubeadm join on the control plane node.

Answer

Restart the kubelet service on all nodes.