CKA Troubleshooting Practice Test 2 — 15 Questions

Question 1

A worker node is marked NotReady. Which two checks are most relevant to diagnose the node's kubelet health? (Choose two.)

Accepted Answer

systemctl status kubelet. A is correct because `systemctl status kubelet` directly queries the systemd service manager to report whether the kubelet process is running, its current state (active/inactive/failed), and recent log entries. Since the kubelet is the primary node agent responsible for registering the node and reporting status to the control plane, checking its service status is the most immediate step when a node is NotReady.

Answer

kubectl get nodes

Answer

Check API server logs

Question 2

A Deployment's pods are failing with 'CrashLoopBackOff'. The container exits with code 1. Which two approaches will help identify the issue? (Choose two.)

Accepted Answer

kubectl logs . A is correct because `kubectl logs ` retrieves the container's stdout/stderr output, which often contains the error message or stack trace that caused exit code 1. This is the first step in debugging a CrashLoopBackOff, as it reveals what the application printed before terminating.

Answer

kubectl get pods -o wide

Answer

kubectl edit deployment <deploy>

Question 3

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 4

A Node is reporting DiskPressure condition. Which action is most appropriate to resolve this without losing data?

Accepted Answer

Add additional disk space to the node or clean up unused images and logs. DiskPressure indicates that the node's disk usage has exceeded the eviction threshold (default 85% for imagefs.available and nodefs.available). Adding disk space or cleaning up unused container images (via `crictl rmi` or `docker image prune`) and logs (via log rotation or `journalctl --vacuum`) directly frees up space without affecting running workloads or causing data loss, addressing the root cause.

Answer

kubectl delete node <node-name>

Answer

kubectl drain <node-name> --ignore-daemonsets

Answer

Restart the kubelet service

Question 5

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 6

You run 'kubectl get pods' and see some pods in 'ImagePullBackOff' state. Which command would best help identify the root cause?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed information about the pod, including the status of its containers, events, and error messages from the kubelet. For an `ImagePullBackOff` state, the `describe` output will show the exact reason for the image pull failure (e.g., invalid image name, registry authentication failure, or network issues) in the `Status` and `Events` sections, making it the most direct troubleshooting command.

Answer

kubectl logs <pod-name>

Answer

kubectl get events --field-selector involvedObject.kind=Pod

Answer

kubectl exec <pod-name> -- cat /var/log/containers

Question 7

Which of the following are valid methods to troubleshoot a Node that is 'NotReady'? (Select all that apply)

Accepted Answer

Check the kubelet logs on the node via journalctl. The kubelet is the primary node agent that communicates with the control plane. When a node is 'NotReady', checking the kubelet logs via `journalctl -u kubelet` can reveal errors such as network connectivity issues, certificate problems, or resource exhaustion. Option B is correct because an expired or invalid kubelet certificate will cause TLS authentication failures with the API server, leading to the node being marked 'NotReady'. Option C is correct because the container runtime (e.g., containerd) is responsible for managing containers; if it is down or misconfigured, the kubelet cannot start pods, and restarting it can resolve transient failures.

Answer

Delete the node object and re-create it

Answer

Reinstall the entire Kubernetes cluster

Question 8

You have a Deployment that is not scaling up beyond 1 replica despite setting replicas: 3. Which of the following could be the cause? (Select all that apply)

Accepted Answer

A ResourceQuota in the namespace limits the number of pods. A ResourceQuota in the namespace can limit the total number of Pods that can be created. If the quota is set to a value that allows only one Pod (or the current count already meets the quota), the Deployment cannot scale beyond 1 replica because the API server rejects Pod creation. B: If the cluster has insufficient CPU/memory to schedule additional Pods, the new Pods will remain Pending and the Deployment will not show additional ready replicas. D: The ReplicaSet controller is responsible for creating Pods to match the desired replica count; if it is malfunctioning, it may fail to create additional Pods, keeping the number below the desired 3. C is incorrect because a PodDisruptionBudget only restricts voluntary disruptions (e.g., evictions), not the number of replicas a Deployment can create.

Answer

A PodDisruptionBudget is set with minAvailable: 1

Question 9

A node in your cluster is reporting a DiskPressure condition. Which kubectl command would you use to get details about the node's condition?

Accepted Answer

kubectl describe node . The `kubectl describe node ` command provides detailed information about a node, including its status, capacity, allocatable resources, and a list of conditions (e.g., DiskPressure, MemoryPressure, PIDPressure, Ready). This is the standard way to inspect the exact reason and timestamps for a DiskPressure condition, as well as related metrics like disk usage and inode consumption.

Answer

kubectl get nodes

Answer

kubectl logs <node-name>

Answer

kubectl get events --field-selector involvedObject.kind=Node

Question 10

A Pod is stuck in CrashLoopBackOff. You run `kubectl logs <pod-name>` but see no output. What is the most likely cause?

Accepted Answer

The container crashes before writing to stdout/stderr.. When a container crashes before it can write any output to stdout or stderr, `kubectl logs` returns no output because there is no log data to retrieve. This is a common symptom of a container that fails during initialization or immediately upon entry point execution, before any logging occurs.

Answer

The pod has no container defined.

Answer

The kubelet is not forwarding logs.

Answer

The pod is in a different namespace.

Question 11

A Service of type LoadBalancer is created but the EXTERNAL-IP remains <pending>. The cluster is running on-premises without a cloud load balancer integration. Which of the following is the most likely reason?

Accepted Answer

No load balancer controller (e.g., MetalLB) is installed.. A Service of type LoadBalancer in Kubernetes requires an external load balancer controller to provision an external IP address. In on-premises clusters without cloud integration, no such controller exists by default, so the EXTERNAL-IP remains <pending> until a bare-metal load balancer like MetalLB is installed and configured. Option C is correct because without a load balancer controller, Kubernetes cannot assign an external IP.

Answer

The cluster has no default storage class.

Answer

The nodes are not reachable from the internet.

Answer

The Service selector does not match any pods.

Question 12

A Pod is in ImagePullBackOff state. Which of the following are valid troubleshooting steps? (Select two.)

Accepted Answer

Run `kubectl describe pod ` to view events.. A is correct because `kubectl describe pod ` shows recent events, including the exact error message from the kubelet when it failed to pull the image (e.g., 'ImagePullBackOff', 'ErrImagePull', or 'Back-off pulling image'). This provides the first diagnostic clue, such as a typo in the image name or a registry authentication failure.

Answer

Run `kubeadm reset` on the node.

Answer

Increase the pod's resource limits.

Question 13

Drag and drop the steps to set up a PersistentVolumeClaim for a pod into the correct order.

Accepted Answer

Step 1: Ensure a PersistentVolume exists, Step 2: Create the PersistentVolumeClaim, Step 3: Apply the PVC configuration, Step 4: Define the pod with a volume mount referencing the PVC, Step 5: Verify the pod is running and the PVC is bound.. First ensure PV exists, then create PVC, apply, define pod with volume mount, and verify.

Answer

Step 1: Create the PersistentVolumeClaim, Step 2: Ensure a PersistentVolume exists, Step 3: Apply the PVC configuration, Step 4: Define the pod with a volume mount referencing the PVC, Step 5: Verify.

Answer

Step 1: Ensure a PersistentVolume exists, Step 2: Define the pod with a volume mount referencing the PVC, Step 3: Create the PersistentVolumeClaim, Step 4: Apply the PVC configuration, Step 5: Verify.

Answer

Step 1: Ensure a PersistentVolume exists, Step 2: Create the PersistentVolumeClaim, Step 3: Define the pod with a volume mount referencing the PVC, Step 4: Apply the PVC configuration, Step 5: Verify.

Question 14

Match each scheduling concept to its description.

Accepted Answer

NodeSelector: Pod scheduling is constrained by matching node labels with a simple key-value pair.. Scheduling controls where Pods run; these mechanisms enforce placement policies.

Answer

NodeSelector: Pod scheduling is constrained by required and preferred rules using node labels.

Answer

NodeAffinity: Pod scheduling is constrained by matching node labels with a simple key-value pair.

Question 15

Match each logging/monitoring component to its role.

Accepted Answer

Fluentd: Collects logs from sources and forwards them to storage.. The correct matches are: Fluentd collects logs, Elasticsearch stores/indexes logs, Prometheus collects metrics, Grafana visualizes. Common confusions include swapping these roles.

Answer

Fluentd: Stores and indexes log data.

Answer

Elasticsearch: Collects metrics from targets.