CKA Troubleshooting Practice Test 9 — 15 Questions

Question 1

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The kube-dns service is not running or is misconfigured. The error 'connection timed out; no servers could be reached' from nslookup indicates that the DNS resolver (typically the kube-dns or CoreDNS service) is unreachable. Since the query targets the standard Kubernetes service name 'kubernetes.default.svc.cluster.local', the most likely cause is that the kube-dns service (or its backend pods) is not running or is misconfigured, preventing the pod from resolving cluster-internal DNS names.

Answer

The pod's /etc/resolv.conf has incorrect nameservers

Answer

The node's network plugin is misconfigured

Answer

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

Question 2

Which command shows CPU and memory usage of nodes in the cluster?

Accepted Answer

kubectl top nodes. `kubectl top nodes` is the command specifically designed to display real-time CPU and memory usage metrics for all nodes in a Kubernetes cluster. It relies on the metrics server, which collects resource usage data from kubelets via the Summary API, and presents it in a concise table format.

Answer

kubectl describe nodes

Answer

kubectl get nodes

Answer

kubectl logs nodes

Question 3

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. What command would you run to see the reason for the crash?

Accepted Answer

kubectl describe pod . B is correct because `kubectl describe pod ` provides detailed information about the pod, including the container state, restart count, and the last termination reason (e.g., 'Error' or 'OOMKilled') along with its exit code. To view the actual stdout/stderr logs of the crashed container, you would use `kubectl logs --previous`.

Answer

kubectl top pod <pod-name>

Answer

kubectl rollout status deployment <deployment-name>

Answer

kubectl get events --field-selector involvedObject.name=<pod-name>

Question 4

You see a pod in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 3 Insufficient cpu'. What should you do?

Accepted Answer

Scale down other deployments to free CPU. The pod is pending due to two issues: taint on one node and insufficient CPU on three nodes. Scaling down other deployments frees CPU resources on nodes, allowing the pod to be scheduled on nodes with sufficient CPU, potentially avoiding the tainted node. Option A only removes the taint but does not solve the CPU shortage. Option C does not affect scheduling. Option D increases CPU requests, worsening the CPU shortage. Therefore, B is the correct action.

Answer

Delete the taint from the node

Answer

Increase the CPU limits only

Answer

Add the required toleration to the pod spec and increase CPU requests

Question 5

Which command would you use to check the status of the kube-apiserver on a control plane node managed by systemd?

Accepted Answer

systemctl status kube-apiserver. The kube-apiserver is a systemd service on control plane nodes managed by systemd. The `systemctl status kube-apiserver` command queries systemd for the current state, including active status, PID, memory usage, and recent log entries, which is the standard method for checking a systemd-managed service.

Answer

kubectl get apiservice

Answer

service kube-apiserver status

Answer

journalctl -u kubelet

Question 6

You deploy a pod with resource limits but no requests. The pod gets OOMKilled. What is the most likely reason?

Accepted Answer

The container tried to use more memory than the limit. When a pod has a memory limit set but no memory request, the Linux kernel enforces the limit via cgroups. If the container's processes attempt to allocate more memory than the limit, the kernel's Out-Of-Memory (OOM) killer terminates the container, resulting in an OOMKilled status. This is the most direct cause of the OOMKilled event.

Answer

The pod's liveness probe is failing

Answer

The container's entrypoint command is invalid

Answer

The node does not have enough memory for the limit

Question 7

Which THREE of the following are common causes for a pod to remain in 'Pending' state?

Accepted Answer

Node taints that the pod does not tolerate. A pod stays in Pending when the Kubernetes scheduler cannot place it on any node, and node taints that the pod does not tolerate (option A) cause the scheduler to filter out those nodes, leaving the pod unscheduled. Insufficient CPU or memory resources on any node (option D) is a classic scheduling failure: the scheduler's resource-fit predicate rejects every node, so the pod remains Pending. A PersistentVolumeClaim that is not bound (option E) also blocks scheduling, because a pod referencing an unbound PVC cannot be assigned to a node until the volume is provisioned and bound. By contrast, Image pull backoff (option B) occurs after scheduling, when the kubelet cannot pull the image, so the pod is in Waiting/ContainerCreating rather than Pending. Container OOMKilled (option C) is a runtime termination state that happens after the container starts, so it does not cause a Pending pod.

Answer

Image pull backoff

Answer

Container OOMKilled

Question 8

Which TWO of the following commands are useful for debugging network connectivity between pods?

Accepted Answer

kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port. Option B is correct because running an ephemeral busybox pod with `kubectl run test-pod --image=busybox --rm -it -- wget -O- http://service:port` lets you test DNS resolution and HTTP connectivity from a separate pod to a target service, which is a standard way to isolate whether a connectivity problem is pod-specific or service-wide. Option E is correct because `kubectl exec -- ping ` executes a network utility inside an existing pod, directly verifying ICMP reachability and basic IP-level connectivity between that pod and the target. Option A is not useful here because `kubectl top pod` only reports CPU and memory usage metrics, not network reachability. Option C is not useful because `kubectl edit deployment` modifies the deployment manifest and does not test connectivity. Option D is not useful because `kubectl logs` only retrieves container stdout/stderr output and does not actively probe network paths.

Answer

kubectl top pod <pod-name>

Answer

kubectl edit deployment <deployment-name>

Answer

kubectl logs <pod-name>

Question 9

A pod is in CrashLoopBackOff. You run 'kubectl logs mypod --previous' and see 'Error: unable to connect to database'. What is the MOST likely cause?

Accepted Answer

The database service endpoint is unreachable. The error 'unable to connect to database' indicates a network connectivity issue between the pod and the database service. Since the error is from the application itself (not a Kubernetes probe), the most likely cause is that the database service endpoint is unreachable, either due to a misconfigured service, incorrect DNS resolution, or network policy blocking traffic. The `--previous` flag shows logs from the previous container instance, confirming the application consistently fails to reach the database.

Answer

The pod's readiness probe is failing

Answer

The pod's liveness probe is misconfigured

Answer

The pod is out of memory

Question 10

Which command retrieves logs from a container that has crashed and restarted?

Accepted Answer

kubectl logs pod-name --previous. B is correct because the `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and restarted. When a container restarts, its logs are preserved for the terminated instance, and this flag allows you to access those logs to debug the crash. Without `--previous`, you would only see logs from the currently running container.

Answer

kubectl describe pod pod-name

Answer

kubectl logs pod-name -c container-name

Answer

kubectl logs pod-name --tail=100

Question 11

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'active (running)'. What should you check NEXT?

Accepted Answer

Check the kubelet logs with 'journalctl -u kubelet' for errors. Since the kubelet is running but the node is NotReady, the issue is likely that the kubelet cannot communicate with the API server or has encountered an error during its operation. Checking the kubelet logs with 'journalctl -u kubelet' is the next logical step to identify specific errors, such as certificate issues, network connectivity problems, or pod lifecycle failures, which would not be visible from the service status alone.

Answer

Check if the kubelet is registered with the API server using 'kubectl get cs'

Answer

Restart the kubelet service

Answer

Check if the node has sufficient disk space

Question 12

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

Accepted Answer

Increase the memory limit of the pod or add more worker nodes. The error '3 Insufficient memory' indicates that three worker nodes lack the required memory to schedule the pod. Increasing the pod's memory limit (if it's set too high) or adding more worker nodes directly addresses the resource shortage. The control-plane node's taint is irrelevant because the pod is not trying to schedule there; the issue is insufficient memory on the available worker nodes.

Answer

Remove the taint from the control-plane node

Answer

Add a toleration for the control-plane taint to the pod spec

Answer

Set nodeSelector to schedule on control-plane nodes

Question 13

A pod is in ImagePullBackOff state. Which command is MOST useful to diagnose the issue?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed pod status, including the exact reason for ImagePullBackOff (e.g., invalid image name, registry authentication failure, or network issues). It surfaces the underlying error message from the kubelet, such as 'Failed to pull image' or 'manifest not found', which directly points to the root cause.

Answer

kubectl logs <pod-name>

Answer

kubectl exec <pod-name> -- ls

Answer

kubectl get events --field-selector type=Warning

Question 14

You want to check the memory usage of nodes in your cluster. Which command should you use?

Accepted Answer

kubectl top nodes. `kubectl top nodes` directly queries the metrics-server (or Heapster) to retrieve real-time CPU and memory usage data for all nodes in the cluster. This command relies on the resource metrics pipeline, which collects metrics from kubelet's cAdvisor endpoint and exposes them via the metrics API, making it the standard way to check node-level memory utilization.

Answer

kubectl describe nodes

Answer

kubectl get nodes -o wide

Answer

kubectl get --raw /api/v1/nodes

Question 15

A pod is unable to resolve DNS names. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command hangs. What is the MOST likely cause?

Accepted Answer

The CoreDNS service is not running or is misconfigured. The CoreDNS service is responsible for DNS resolution within the cluster. If it is not running or misconfigured, DNS queries from pods will hang or fail. The `nslookup` command hanging indicates that the DNS request is not being answered, which is a classic symptom of a non-functional or unreachable DNS service.

Answer

The pod's /etc/resolv.conf is missing

Answer

The kubelet is not running on the node

Answer

The pod's network policy blocks DNS traffic