CKA Timed Hard Questions — 25 Difficult Questions

Question 1

A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?

15 minute time limit — choose an answer to begin.

Accepted Answer

All nodes in the cluster are NotReady. The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Answer

The pod needs a toleration for node.kubernetes.io/not-ready

Answer

The pod has a resource request that cannot be met

Answer

The scheduler is not running

Question 2

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. Kubelet is active but 'journalctl -u kubelet -n 50' shows 'network plugin is not ready: cni config uninitialized'. What is the most likely cause?

Accepted Answer

The CNI configuration file is missing or incorrect. The CNI plugin configuration is missing, causing the network plugin to be unready.

Answer

The container runtime is not installed

Answer

Kubelet is not running

Answer

The node's IP address has changed

Question 3

You have a pod that is CrashLoopBackOff. The logs show 'error: dial tcp: lookup service.default.svc.cluster.local: no such host'. What is the most likely cause?

Accepted Answer

The service 'service' does not exist in the 'default' namespace. The error message 'no such host' indicates that the DNS lookup for 'service.default.svc.cluster.local' failed because the hostname does not exist. In Kubernetes, this FQDN resolves only if a Service named 'service' exists in the 'default' namespace. Since the lookup fails with 'no such host', the most likely cause is that the Service does not exist, not a DNS infrastructure issue.

Answer

The CoreDNS pod is down

Answer

The pod's DNS policy is set to 'None'

Answer

A network policy is blocking UDP port 53

Question 4

Which THREE of the following are valid commands to troubleshoot network connectivity between pods? (Select 3)

Accepted Answer

kubectl exec pod-a -- nslookup service-name. kubectl exec can run networking tools inside a pod. curl is a common tool. nslookup tests DNS. ping tests basic connectivity.

Answer

kubectl describe node | grep Network

Answer

kubectl logs pod-a | grep network

Question 5

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 6

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 7

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

Accepted Answer

kube-proxy not running or misconfigured. When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Answer

DNS resolution failure

Answer

Ingress controller not set up

Answer

Service type should be NodePort

Question 8

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

Accepted Answer

Free up disk space and reduce memory usage on the affected nodes. The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints. The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Answer

Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints

Answer

Add tolerations for both taints to the pod spec

Answer

Delete the pod and recreate it with higher resource requests

Question 9

A pod is in CrashLoopBackOff. The YAML for the initContainer is:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:
  - name: init
    image: busybox
    command: ['sh', '-c', 'sleep 5 && exit 1']
  containers:
  - name: app
    image: nginx

What is the most likely reason for the CrashLoopBackOff?

Accepted Answer

The init container exits with non-zero exit code. Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Answer

The main container image nginx is not pulled successfully

Answer

The init container command is misspelled

Answer

The pod has insufficient memory

Question 10

A pod is in CrashLoopBackOff. 'kubectl logs my-pod --previous' shows: 'Error: failed to start: exec: "/app/start.sh": stat /app/start.sh: no such file or directory'. What is the most likely cause?

Accepted Answer

The container image is missing the startup script.. The error indicates the specified entrypoint script is missing. This is often due to the container image not containing the script at the expected path, or the command/args in the pod spec referencing a non-existent file.

Answer

The pod's service account lacks permissions.

Answer

The pod's liveness probe is misconfigured.

Answer

The pod has run out of memory.

Question 11

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

Accepted Answer

Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod. The event message explicitly states that 1 node has a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate, and 3 nodes have insufficient CPU. This means the pod's CPU request cannot be satisfied on three nodes, and the remaining node is tainted, leaving no schedulable node. Option A correctly identifies this combination of issues.

Answer

The pod has a resource request that exceeds available CPU on all nodes

Answer

The pod does not tolerate any taints, and all nodes have taints

Answer

The cluster has only one node with sufficient CPU, but it is cordoned

Question 12

A node is NotReady. Which THREE conditions could cause this?

Accepted Answer

Network plugin (e.g., Calico) is not functioning. Kubelet stopped, network plugin issues, and disk pressure can all cause a node to become NotReady.

Answer

A pod is in CrashLoopBackOff

Answer

The API server is overloaded

Question 13

A CSI driver is installed in the cluster, but a PersistentVolumeClaim using a StorageClass that references this driver remains Pending. The administrator checks the logs of the CSI controller pod and sees no errors. What is a possible cause?

Accepted Answer

The StorageClass volumeBindingMode is set to WaitForFirstConsumer.. If the volumeBindingMode is set to WaitForFirstConsumer, the PV will not be provisioned until a pod using the PVC is scheduled. This is a common pitfall. The CSI driver may be working fine, but the binding mode delays provisioning.

Answer

The CSI driver is not registered correctly.

Answer

The StorageClass volumeBindingMode is set to Immediate.

Answer

The PVC requests a size that is not available.

Question 14

You have a cluster with multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0 using kubeadm. What is the correct sequence of steps?

Accepted Answer

Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.. The official kubeadm upgrade workflow requires upgrading kubeadm first on the control plane node, then using `kubeadm upgrade apply` to upgrade control plane components, and finally draining and upgrading each worker node by updating kubelet and kubectl. This sequence ensures the cluster's management plane is updated before worker nodes, maintaining control plane stability and API compatibility during the rolling upgrade.

Answer

Upgrade kubeadm on the control plane node, then upgrade kubelet and kubectl on worker nodes, then upgrade kubelet and kubectl on control plane node.

Answer

Drain all nodes, upgrade kubelet and kubectl on all nodes, then upgrade kubeadm on the control plane node.

Answer

Upgrade kubelet and kubectl on all nodes first, then upgrade kubeadm on the control plane node.

Question 15

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 16

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. Which of the following is the MOST likely cause?

Accepted Answer

The Metrics Server is not deployed in the cluster. The 'error: Metrics API not available' error indicates that the Metrics API service (v1beta1.metrics.k8s.io) is not registered with the API server, which most commonly happens when the Metrics Server is not deployed in the cluster. Option C is correct. Option A would result in a connection refused error. Option B and D would not prevent the Metrics API itself from being available, though they might lead to missing metrics for specific nodes.

Answer

The Kubernetes API server is down

Answer

The kubelet is not running on all nodes

Answer

One or more nodes are in NotReady state

Question 17

Which TWO of the following could cause a Node to be in NotReady state?

Accepted Answer

The kubelet process has stopped. A Node is NotReady if the kubelet is not reporting healthy. Common causes include kubelet failure and network plugin issues.

Answer

The node has a taint that prevents scheduling

Answer

The node has insufficient disk space

Answer

The node's IP address has changed

Question 18

You have a Deployment with livenessProbe configured. The pod restarts every few minutes. 'kubectl describe pod' shows the liveness probe is failing with 'HTTP probe failed with statuscode: 503'. The application's /healthz endpoint returns 200 from within the pod using 'kubectl exec'. What could be the issue?

Accepted Answer

The livenessProbe is configured with the wrong port. The liveness probe is failing externally but the endpoint works internally. This suggests the probe is hitting the wrong port or the network path is different. The most likely cause is that the livenessProbe is configured with a wrong port number.

Answer

The readinessProbe is interfering with the livenessProbe

Answer

The application has a memory leak

Answer

The kubelet on the node is misconfigured

Question 19

You have a StatefulSet with 5 pods, each requiring a unique stable network identity. The StatefulSet is scaled down from 5 to 3. Which pods will be terminated?

Accepted Answer

Pods with the highest ordinals (4 and 3). When a StatefulSet is scaled down, Kubernetes terminates pods in reverse order of their ordinal indices, starting from the highest. For a StatefulSet with 5 pods (ordinals 0-4) scaled to 3, pods with ordinals 4 and 3 are terminated first, ensuring that the remaining pods (0, 1, 2) maintain their stable network identities and storage.

Answer

Random pods

Answer

Pods with the lowest ordinals (0 and 1)

Answer

Pods with the highest resource usage

Question 20

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

Accepted Answer

systemctl start kubelet. Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

Answer

journalctl -u kubelet

Answer

kubectl delete node <node-name>

Answer

systemctl restart docker