CKA Troubleshooting Practice Test 8 — 15 Questions

Question 1

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 2

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 3

A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?

Accepted Answer

A NetworkPolicy is blocking the traffic. A NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Answer

The kube-proxy is not running on the node

Answer

The service's targetPort is incorrect

Answer

The pod is running on a different node without proper routing

Question 4

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 5

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 6

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 7

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 8

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 9

A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select two.)

Accepted Answer

kube-proxy is not running on the node.. Option A is correct because kube-proxy is the component that programs the iptables/IPVS rules on each node to implement ClusterIP Service virtual IP load balancing; if kube-proxy is not running on a node, pods on that node cannot reach the Service's ClusterIP even though endpoints exist. Option B is correct because the Service's targetPort must match the port the container actually listens on; if the container listens on a different port, traffic forwarded to the endpoint will be refused or dropped, making the Service unreachable despite having endpoints. Option C is not correct because a failing readiness probe would remove the pod from the Service's endpoints, but the scenario explicitly states that endpoints exist, so this cannot be the cause. Option D is not correct because Kubernetes Service names are limited to 63 characters by DNS label rules, but an overly long name would be rejected at creation time rather than causing a running Service with endpoints to be unreachable.

Answer

The pod's readiness probe is failing.

Answer

The Service name is too long.

Question 10

Drag and drop the steps to back up and restore etcd data for a Kubernetes cluster into the correct order.

Accepted Answer

Take etcd snapshot, then verify the snapshot, then stop etcd, then restore etcd from snapshot, then start etcd, then verify cluster health.. The correct order ensures that you capture a consistent snapshot, verify its integrity, stop etcd to avoid conflicts, restore the data, start etcd, and then confirm the cluster is healthy. Skipping steps or doing them out of order can lead to data loss or cluster instability.

Answer

Stop etcd, then take etcd snapshot, then verify snapshot, then restore, then start etcd, then check cluster health.

Answer

Take snapshot, verify snapshot, restore from snapshot, stop etcd, start etcd, check cluster health.

Answer

Take snapshot, verify snapshot, stop etcd, restore, check cluster health, start etcd.

Question 11

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. What is the most likely cause?

Accepted Answer

The container image name is misspelled. The 'ImagePullBackOff' state indicates that the kubelet on the node is unable to pull the container image from the registry. The most common cause is an incorrect image name or tag, which results in a manifest not found error. This triggers exponential backoff retries by the kubelet, leading to the 'ImagePullBackOff' status.

Answer

The node is out of disk space

Answer

The pod exceeded its memory limit

Answer

The container command is invalid

Question 12

A pod is stuck in 'Pending' state. Which command would you run FIRST to diagnose the issue?

Accepted Answer

kubectl describe pod <pod-name>. A pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>

Answer

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

Question 13

After deploying a new Deployment, you run 'kubectl get events' and see 'FailedScheduling' events. What is a possible cause?

Accepted Answer

The pod has a node selector that matches no nodes. A FailedScheduling event indicates that the Kubernetes scheduler could not find a suitable node to place the pod. Option B is correct because if a pod has a node selector that does not match any node's labels, the scheduler will fail to schedule it, resulting in a FailedScheduling event. The scheduler evaluates node selectors against node labels, and if no node satisfies the selector, the pod remains unscheduled.

Answer

The container port is already in use on the node

Answer

The node has a taint that tolerates the pod

Answer

The pod's image pull secret is missing

Question 14

You have a multi-node cluster. One node shows 'NotReady'. You run 'journalctl -u kubelet' on that node and see 'network plugin is not ready'. What is the most likely cause?

Accepted Answer

The CNI plugin pod (e.g., Calico) is not running on that node. The 'network plugin is not ready' error from kubelet indicates that the kubelet is waiting for a CNI (Container Network Interface) plugin to configure the pod network. If the CNI plugin pod (e.g., Calico, Flannel, Weave) is not running on that specific node, the kubelet cannot set up the network for pods, causing the node to remain in 'NotReady' state. This is the most direct cause because the kubelet relies on the CNI plugin to report readiness before marking the node as Ready.

Answer

The container runtime (e.g., containerd) is down

Answer

The kubelet service is not running

Answer

The node's IP address has changed

Question 15

You want to check the logs of a container that previously crashed. Which command should you use?

Accepted Answer

kubectl logs --previous <pod-name>. The `kubectl logs --previous` command retrieves logs from the previous instance of a container in a Pod that has crashed or been restarted. This is essential for debugging transient failures because the current container's logs may not contain the crash information. The `--previous` flag specifically accesses the terminated container's log stream, which is stored by the kubelet until the pod is deleted.

Answer

kubectl logs <pod-name>

Answer

kubectl exec <pod-name> -- cat /var/log/app.log

Answer

kubectl describe pod <pod-name>