CKA Practice Test 2 — 25 Questions

Question 1

Which TWO actions can help troubleshoot a service that is not reachable from within a pod?

Accepted Answer

Use kubectl exec to curl the service IP from a pod. Checking endpoints and using curl from a pod are direct troubleshooting steps.

Answer

Use kubectl delete svc and recreate

Answer

Use kubectl logs on the service pod to see application logs

Answer

Use kubectl top nodes to check resource usage

Question 2

A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim's storage class does not exist or cannot provision a volume. A PersistentVolumeClaim (PVC) remains in 'Pending' state when it cannot find a suitable PersistentVolume (PV) to bind to or when its storage class cannot dynamically provision one. The most common cause is that the referenced storage class does not exist, is misspelled, or lacks a provisioner that can create the volume, leaving the PVC unbound and the pod unable to start.

Answer

The pod's YAML has a syntax error

Answer

The pod is using a hostPath volume

Answer

The node has insufficient CPU resources

Question 3

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event '0/1 nodes are available: 1 Insufficient cpu'. What is the most likely cause?

Accepted Answer

The pod's CPU request exceeds available node CPU. The event indicates that no node has enough free CPU to satisfy the pod's CPU request.

Answer

The pod's memory limit is too low

Answer

The pod is trying to use a GPU that is not available

Answer

The kubelet on the node is not running

Question 4

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Answer

kubectl logs <pod>

Answer

kubectl get events

Answer

kubectl exec -it <pod> -- sh

Question 5

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 6

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 7

A Deployment named 'web' is failing to schedule pods. You run 'kubectl describe pod web-xyz' and see the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

Accepted Answer

The CPU request in the pod spec is too high. The error indicates that CPU requests are too high for the available node resources. Reducing CPU requests or adding more nodes can fix it.

Answer

The network plugin is misconfigured

Answer

The nodes have insufficient memory

Answer

The kubelet is not running on the nodes

Question 8

Refer to the exhibit. The master node shows NotReady status. The kubelet is reporting 'container runtime is down'. Which command should be used to investigate and fix this issue?

Accepted Answer

systemctl status containerd && systemctl restart containerd. The kubelet is unable to communicate with the container runtime. Since the master uses containerd (common in kubeadm), checking the containerd service status and restarting it is the first step.

Answer

kubectl delete node master && kubeadm reset

Answer

systemctl status kubelet && systemctl restart kubelet

Answer

systemctl status docker && systemctl restart docker

Question 9

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 10

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 11

A company runs a batch job that processes a queue. The job should run to completion exactly once. Which resource should be used?

Accepted Answer

Job. A Kubernetes Job is designed to run a specified number of pods to successful completion. When the pod exits with a zero exit code, the Job is marked as complete and will not be restarted, making it the correct choice for a batch job that must run exactly once.

Answer

DaemonSet

Answer

CronJob

Answer

Deployment

Question 12

You run 'kubectl logs my-pod -c my-container' and get no output, but you know the container produces logs. What should you do next to see previous container logs?

Accepted Answer

kubectl logs my-pod -c my-container --previous. The --previous flag retrieves logs from the previous instance of a crashed container.

Answer

kubectl logs my-pod -c my-container -f

Answer

kubectl logs my-pod -c my-container --tail=50

Answer

kubectl logs my-pod -c my-container --all-containers

Question 13

Which TWO commands show cluster events that can help in troubleshooting?

Accepted Answer

kubectl describe pod . Option E, `kubectl get events`, is correct because it directly lists the cluster's event stream (backed by the Events API), showing scheduling failures, image pull errors, probe failures, and other warnings tied to specific resources. Option D, `kubectl describe pod `, is correct because its output includes an Events section at the bottom that surfaces the same per-pod events with timestamps, reasons, and messages, which is essential for troubleshooting a specific pod. Option A, `kubectl cluster-info`, only prints the addresses of the control plane and core add-ons, providing no event data. Option B, `kubectl logs `, shows application/container stdout and stderr, not Kubernetes cluster events. Option C, `kubectl top pods`, reports CPU and memory usage metrics from the metrics server, which is resource data rather than events.

Answer

kubectl cluster-info

Answer

kubectl logs <pod-name>

Answer

kubectl top pods

Question 14

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 15

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 16

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 17

A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?

Accepted Answer

kubectl describe pod <pod-name>. The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.

Answer

kubectl logs <pod-name>

Answer

kubectl get events --watch

Answer

kubectl exec -it <pod-name> -- /bin/sh

Question 18

An administrator runs 'kubectl cordon node1' and then 'kubectl drain node1 --ignore-daemonsets'. What is the effect on node1?

Accepted Answer

Node1 is marked as unschedulable and all pods except DaemonSets are evicted. The `kubectl cordon node1` command marks node1 as unschedulable, preventing new pods from being scheduled onto it. The subsequent `kubectl drain node1 --ignore-daemonsets` command evicts all pods from node1 except DaemonSets (which are ignored because they are managed by the DaemonSet controller and typically need to run on every node). This combination makes node1 unschedulable and removes all non-DaemonSet pods, preparing the node for maintenance.

Answer

Node1 is marked as unschedulable but no pods are evicted

Answer

New pods are scheduled onto node1 and existing pods are evicted

Answer

Node1 is marked as schedulable and all pods are evicted

Question 19

The controller-manager logs show repeated errors: 'Failed to list *v1.Pod: connection refused'. What is the most likely cause?

Accepted Answer

The API server is down or not reachable. The controller-manager communicates with the API server. 'connection refused' indicates the API server is not reachable or not running.

Answer

The kube-controller-manager is not running

Answer

The kubelet on the controller node is down

Answer

The scheduler is overloading the API server

Question 20

You run 'kubectl get events --sort-by='.lastTimestamp'' and see repeated events: 'Failed to pull image "myimage:v2": rpc error: code = Unknown desc = Error response from daemon: manifest for myimage:v2 not found'. What is the issue?

Accepted Answer

The image tag 'myimage:v2' does not exist in the registry.. The error 'manifest not found' means the image tag does not exist in the registry. The pod is in ImagePullBackOff because the image is missing.

Answer

The pod has insufficient privileges to pull the image.

Answer

The image registry is down.

Answer

The container runtime is not running.