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?

Accepted Answer

kubeadm. kubeadm is the correct choice because it is the official Kubernetes tool for bootstrapping production-grade clusters on bare-metal servers, supporting high availability (HA) for the control plane via stacked or external etcd topologies. It integrates with etcd operators (e.g., etcdadm or the etcd-operator project) for cluster management, allowing automated etcd cluster lifecycle operations. Other tools either lack HA control plane support, are not designed for bare-metal, or do not use etcd operators.

Answer

kube-spray

Answer

minikube

Answer

kops

Question 2

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

Accepted Answer

The bootstrap token used for TLS bootstrapping has expired.. The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.

Answer

The kubelet configuration file has incorrect node IP.

Answer

The node's RBAC permissions are misconfigured.

Answer

The API server is not running.

Question 3

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.. Option B is correct because 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 4

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 5

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 6

An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?

Accepted Answer

Ensure that containerd is installed and running on the worker node.. The error 'container runtime is not running' on the worker node indicates that the CRI (Container Runtime Interface) implementation, typically containerd, is not active. Since kubelet relies on a running container runtime to manage pods, the administrator must first check that containerd is installed and running on the worker node using commands like 'systemctl status containerd' or 'systemctl start containerd'.

Answer

Verify that the control plane node is healthy.

Answer

Check if the join token has expired.

Answer

Install a network plugin like Calico on the control plane.

Question 7

A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?

Accepted Answer

Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.. Option B is correct because Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

Answer

Use LUKS to encrypt the disk partition where etcd data is stored.

Answer

Use TLS certificates to encrypt communication between etcd and the API server.

Answer

Configure etcd to use encryption at rest by setting --experimental-encryption-provider.

Question 8

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 9

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 10

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. Option A is correct because `kubeadm upgrade apply v1.23.0` is the explicit command to upgrade the control plane to a specific version (v1.23.0) in a kubeadm cluster. It validates the upgrade path, uploads the new configuration, and applies the upgrade to the control plane components. The node is already drained, so this command proceeds directly with the upgrade.

Answer

kubeadm upgrade node

Answer

kubeadm upgrade plan v1.23.0

Answer

kubeadm upgrade diff

Question 11

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

Accepted Answer

--trusted-ca-file. Option B is correct because `--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 12

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.. Option B is correct because 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 13

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.. Option B is correct because 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 14

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.. Option D is correct because 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 15

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 16

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 17

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 18

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 19

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 20

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