CKA Cluster Architecture, Installation & Configuration — 20 Questions

Question 1

A company wants to install Kubernetes on a set of bare-metal servers with no existing orchestration tools. They need a solution that supports high availability for the control plane and uses etcd operators for cluster management. Which tool should they use?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

kubeadm. kubeadm is the official Kubernetes tool for bootstrapping production-grade clusters. It is designed to be a lightweight and extensible way to bootstrap a secure Kubernetes cluster on bare-metal or virtual servers, supporting high availability (HA) for the control plane (using stacked or external etcd topologies). While Kubespray is an Ansible-based deployment tool that uses kubeadm under the hood, kubeadm itself is the core bootstrapping tool. kops is primarily designed for cloud providers, and minikube is for local development.

Answer

kube-spray

Answer

minikube

Answer

kops

Question 2

An administrator needs to upgrade the kube-apiserver on a control plane node from version 1.22.0 to 1.23.0. Which of the following is the correct order of steps?

Accepted Answer

Drain node, upgrade kubeadm, upgrade kubelet, uncordon node.. When upgrading the kube-apiserver, the standard workflow is to first drain the node to evict pods, then upgrade kubeadm (which manages the control plane components), then upgrade kubelet (which runs on the node), and finally uncordon the node to make it schedulable again. This sequence ensures that the node is safely taken out of service before any changes are made, and that the upgrade tools are updated before the components they manage.

Answer

Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.

Answer

Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.

Answer

Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.

Question 3

A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?

Accepted Answer

There is a network connectivity issue between the new node and the control plane.. The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.

Answer

The kubelet is not configured with the correct node IP.

Answer

The new node does not have enough disk space for container images.

Answer

The API server is overloaded and cannot handle the node update request.

Question 4

A cluster administrator has configured a PodSecurityPolicy (PSP) that requires all pods to run with read-only root filesystem. However, a newly deployed pod is failing to start with the error 'container has runAsNonRoot and image will run as root'. The PSP is designed to prevent running as root. What is the most likely cause?

Accepted Answer

The container image is configured to run as root user.. The error message 'container has runAsNonRoot and image will run as root' indicates that the PodSecurityPolicy (PSP) is configured with `runAsNonRoot: true`, but the container image itself is built to run as the root user (UID 0). The PSP enforces that the container must not run as root, but the image's default user is root, causing the admission controller to reject the pod. Option C correctly identifies this mismatch as the most likely cause.

Answer

The PodSecurityPolicy admission controller is not enabled.

Answer

The PSP is not set to enforce read-only root filesystem.

Answer

The PSP is not being applied to the pod's service account.

Question 5

A cluster is running on a cloud provider that supports load balancers. An administrator needs to expose a service externally using a cloud load balancer. However, the service remains in 'Pending' state. The cloud provider requires the cluster to be configured with the correct cloud provider flag. Which kube-controller-manager flag is required for this integration?

Accepted Answer

--cloud-provider. The `--cloud-provider` flag on the kube-controller-manager tells Kubernetes which cloud provider integration to use (e.g., `aws`, `gce`, `azure`). Without this flag set to the correct provider, the cloud controller manager cannot provision a load balancer for a Service of type LoadBalancer, leaving it in 'Pending' state because the external IP allocation never completes.

Answer

--cloud-controller-manager

Answer

--configure-cloud-routes

Answer

--cloud-config

Question 6

During a 'kubeadm init', the administrator sees the message 'Your Kubernetes control-plane has been initialized successfully!' but the 'kubectl get nodes' shows the control plane node as 'NotReady'. What is the most likely missing step?

Accepted Answer

Install a CNI plugin such as Calico or Flannel.. The 'NotReady' status indicates that the kubelet on the control plane node is running but cannot report readiness because the node's network is not configured. A CNI plugin (e.g., Calico, Flannel, Weave) must be installed to set up the pod network, which is required for the kubelet to register the node as 'Ready'. Without a CNI plugin, the node's network conditions remain unmet, and the control plane cannot function properly.

Answer

Generate a join token for worker nodes.

Answer

Copy the kubeconfig to the user's home directory.

Answer

Check that the kubelet is running on the control plane node.

Question 7

Which TWO of the following are valid commands to upgrade a kubeadm cluster from version 1.22.x to 1.23.x on the control plane node? Assume the node is already drained.

Accepted Answer

kubeadm upgrade apply v1.23.0. The correct commands to upgrade a control plane node are `kubeadm upgrade apply v1.23.0` for the first control plane node and `kubeadm upgrade node` for additional control plane nodes. `kubeadm upgrade plan` only lists available upgrades and does not perform the upgrade. The node is already drained, so the upgrade can proceed with either `apply` (if this is the first control plane) or `node` (if this is an additional control plane). Both are valid kubeadm upgrade commands for control plane nodes.

Answer

kubeadm upgrade plan v1.23.0

Answer

kubeadm upgrade plan

Answer

kubeadm upgrade diff

Question 8

A cluster uses etcd with TLS encryption. Which THREE of the following are valid etcd client certificate authentication flags?

Accepted Answer

--trusted-ca-file. `--trusted-ca-file` specifies the CA certificate used to validate client certificates when client certificate authentication is enabled. This flag is required for etcd to trust incoming client connections that present a certificate signed by the specified CA, forming the basis of mutual TLS (mTLS) authentication.

Answer

--client-cert-auth

Answer

--peer-cert-file

Question 9

Which TWO of the following are valid methods to configure the kubelet's node IP address?

Accepted Answer

Setting the --node-ip flag in kubelet command line.. The `--node-ip` flag explicitly sets the IP address that the kubelet uses to identify itself to the API server and other components. This flag directly configures the node's primary IP for kubelet-to-apiserver communication and is a standard method in both standalone kubelet and kubeadm-deployed clusters.

Answer

Using the --hostname-override flag.

Answer

Setting the --address flag in kubelet command line.

Answer

Setting the node-ip in the kubeadm-config ConfigMap.

Question 10

Which THREE of the following are valid steps to enable audit logging in a Kubernetes cluster?

Accepted Answer

Create an audit policy file defining what events to log.. Audit logging in Kubernetes requires an audit policy file that defines which events (e.g., RequestResponse, Metadata) should be logged. This policy file must be created and then passed to the kube-apiserver via the --audit-policy-file flag. Without a policy file, the apiserver will not know what to log, even if other flags are set.

Answer

Store the audit policy in a ConfigMap and reference it via --audit-policy-configmap.

Answer

Restart the kubelet on the control plane node.

Question 11

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

Accepted Answer

The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.. The ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Answer

The pod is requesting 2 CPUs as a request, but the quota limits requests.

Answer

The pod is being created in the wrong namespace.

Answer

The pod is trying to use more CPU than the node capacity.

Question 12

An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?

Accepted Answer

Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.. When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Answer

Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

Answer

Use a different port for the API server by specifying --apiserver-bind-port.

Answer

Run kubeadm init with --force flag to override the errors.

Question 13

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 14

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 15

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. `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 16

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. `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 17

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 18

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

Reinstall kubelet on the worker node and restart it. When draining a node, if there are pods using `emptyDir` volumes (local storage), `kubectl drain` will fail by default to prevent data loss. To proceed, you must explicitly permit the deletion of these pods by passing the `--delete-emptydir-data` flag. Note that `--delete-local-data` was deprecated in v1.20 and removed in v1.22, so it is no longer valid in v1.25.

Answer

Skip draining the node and proceed with the kubelet upgrade

Answer

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

Answer

Cordon the node and then run kubectl drain with --force

Question 19

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. `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 20

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.