CKA Troubleshooting Practice Test 6 — 15 Questions

Question 1

You have a pod that is stuck in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod anti-affinity rules.' What is the MOST likely solution?

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

Accepted Answer

Remove or modify the pod anti-affinity rules. The pod is unschedulable because two nodes are excluded by pod anti-affinity rules, not because of the master taint (only one node has that taint). The most direct solution is to remove or modify the anti-affinity rules so the pod can be scheduled on those two nodes. Adding a toleration would only address the single master node, leaving the anti-affinity issue unresolved.

Answer

Cordon the master node to remove it from scheduling

Answer

Add a toleration for the master taint to the pod spec

Answer

Delete and recreate the pod

Question 2

Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?

Accepted Answer

Run 'kubectl logs pod-name --previous' to view logs from the previous crash. 'kubectl logs pod-name --previous' retrieves the logs from the last terminated container instance, which is essential when the current container has crashed and restarted, as in a CrashLoopBackOff state. This allows you to see the error that caused the crash before the container was restarted.

Answer

Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container

Answer

Run 'kubectl rollout restart deployment/pod-name'

Answer

Run 'kubectl delete pod pod-name' to force restart

Question 3

Which TWO of the following are possible reasons for a node being in 'NotReady' state?

Accepted Answer

The kubelet service has stopped on the node. The kubelet is the primary node agent that registers the node with the cluster and periodically reports node status, including heartbeats. If the kubelet service stops (e.g., due to a crash, misconfiguration, or manual stop), the node cannot send its status updates to the control plane, causing the node to transition to the 'NotReady' state after the node-monitor-grace-period (default 40 seconds) expires. Also, if the container network plugin (e.g., Calico, Flannel) is not functioning, the kubelet may be unable to configure pod networking, which leads to the node being reported as NotReady, because network readiness is required for pods to run.

Answer

The node is running an outdated kernel version

Answer

The node's disk is full

Answer

The node has insufficient CPU resources

Question 4

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

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. A pod remains in 'Pending' state when it cannot be scheduled or when its containers cannot start. Reasons include: A) a PVC not bound, C) insufficient resources on any node, D) taints not tolerated, and B) image pull failures such as ImagePullBackOff. All these prevent the pod from transitioning to Running. Kubernetes documentation states that Pending includes time spent pulling images.

Answer

The container's startup command is misconfigured

Question 5

You have a Deployment with one replica. The Pod enters CrashLoopBackOff. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

Accepted Answer

The container is exceeding its memory limit and is OOMKilled. Exit code 137 (128 + 9) indicates the container was killed by SIGKILL, which is the signal sent by the Linux OOM killer when a process exceeds its memory limit. In Kubernetes, when a container's memory usage surpasses its `resources.limits.memory`, the kubelet triggers an OOM kill, causing the container to exit with code 137 and enter CrashLoopBackOff.

Answer

The node is being drained and the pod is being terminated

Answer

The container's startup command is invalid

Answer

The liveness probe is failing and Kubernetes is restarting the container

Question 6

You need to check the CPU and memory usage of all pods in the 'production' namespace. Which command should you use?

Accepted Answer

kubectl top pods -n production. The `kubectl top pods` command retrieves real-time CPU and memory metrics for pods from the metrics server, which is required for the CKA exam. The `-n production` flag restricts the output to the 'production' namespace, making option A the correct choice for checking resource usage of all pods in that namespace.

Answer

kubectl get pods -n production --show-labels

Answer

kubectl get resourceusage pods -n production

Answer

kubectl top nodes -n production

Question 7

A pod is in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 PersistentVolumeClaim is not bound'. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim referenced by the pod does not exist or is not bound. The event '0/3 nodes are available: 3 PersistentVolumeClaim is not bound' indicates that the pod's PersistentVolumeClaim (PVC) is not in a 'Bound' state. This means the PVC either does not exist in the namespace or has not been successfully bound to a PersistentVolume (PV). The scheduler cannot schedule the pod because the PVC requirement is unsatisfied, which is a prerequisite for pod startup.

Answer

The storage class used by the PVC does not match any PV

Answer

The scheduler is not configured to handle persistent volumes

Answer

The nodes do not have enough CPU or memory

Question 8

You have a Service named 'my-svc' in namespace 'app'. A Pod in the same namespace cannot resolve the hostname 'my-svc' to an IP address. Which command should you run inside the Pod to test DNS name resolution?

Accepted Answer

nslookup my-svc.app.svc.cluster.local. The fully qualified domain name (FQDN) for a Kubernetes Service is `..svc.cluster.local`. Running `nslookup my-svc.app.svc.cluster.local` inside the Pod queries the cluster's DNS (CoreDNS/kube-dns) directly, which is the standard way to verify DNS resolution for a Service. The short name `my-svc` may not resolve if the Pod's DNS search domains are misconfigured or if the Pod is in a different namespace, but the FQDN always works.

Answer

ping my-svc

Answer

nslookup my-svc

Answer

curl http://my-svc

Question 9

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod> --previous' and see an error about a missing environment variable. The Pod spec defines the environment variable in a ConfigMap. What is the best next step to diagnose the issue?

Accepted Answer

Run 'kubectl get configmap <configmap-name>' to verify the ConfigMap exists and contains the expected key. The first step in diagnosing a missing environment variable that should come from a ConfigMap is to verify that the ConfigMap itself exists and contains the expected key. If the ConfigMap is missing or the key is absent, the Pod will fail to start or crash, leading to CrashLoopBackOff. Running 'kubectl get configmap' directly confirms whether the resource is present and correctly populated, which is the most efficient next step before deeper investigation.

Answer

Use 'kubectl exec -it <pod> -- env' to list environment variables

Answer

Increase the pod's memory limit to prevent OOM

Answer

Check the node's kubelet logs for errors

Question 10

A Pod that was running fine is now showing 'OOMKilled' in its status. Which kubectl command would show you the memory limit and usage for the container?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` displays detailed information about the pod, including the resource requests and limits for each container. When a pod is OOMKilled, the container's memory limit (from the `limits.memory` field) and the reason for termination (OOMKilled) are shown in the container status section, allowing you to compare the limit with the actual usage reported in the `Last State` or `State` fields.

Answer

kubectl top pod <pod>

Answer

kubectl top node

Answer

kubectl logs <pod>

Question 11

A pod is in 'CrashLoopBackOff' state. Which THREE of the following are possible causes?

Accepted Answer

The container's startup command has invalid arguments. If the container's startup command contains invalid arguments, the container will fail to start and enter a crash loop. Kubernetes will repeatedly restart the container, leading to the CrashLoopBackOff state as the kubelet detects the failure and backs off on restart attempts.

Answer

The container image does not exist

Answer

The PersistentVolumeClaim is not bound

Question 12

Which TWO of the following are valid reasons a pod might be stuck in 'Pending' state?

Accepted Answer

Not enough CPU or memory available on any node. A pod remains in the 'Pending' state if the Kubernetes scheduler cannot assign it to a node. This typically occurs due to scheduling constraints, such as:
1. Insufficient CPU or memory resources on any available node to satisfy the pod's resource requests (Option C).
2. All available nodes have taints that the pod does not tolerate, preventing the scheduler from placing the pod on them (Option E).

In contrast, container runtime issues like OOM kills (Option A) or image pull failures (Option B) occur after a pod has already been scheduled to a node, resulting in states like CrashLoopBackOff or ImagePullBackOff, not Pending.

Answer

Container is killed due to OOM

Answer

Container image pull fails because of authentication error

Answer

Node is rebooted

Question 13

You have a Pod that is stuck in Pending state. Which command should you use to get detailed information about why the Pod is not running?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed event logs, status conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending, node selector mismatches) that explain why the Pod is stuck in Pending state. The Pending state indicates the Pod has been accepted by the API server but not yet scheduled or started, and `describe` surfaces the exact scheduler or admission controller failures.

Answer

kubectl logs <pod-name>

Answer

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

Answer

kubectl get pod <pod-name>

Question 14

A node in the cluster is showing NotReady status. Which steps should you take to diagnose the issue? (Select the BEST initial step.)

Accepted Answer

Run 'journalctl -u kubelet' on the node to check kubelet logs. When a node is NotReady, the kubelet is the primary agent responsible for reporting node status. The kubelet communicates node conditions to the control plane via periodic heartbeats. Checking the kubelet logs with 'journalctl -u kubelet' on the node itself is the most direct initial step to identify why the kubelet is failing to report readiness, such as network issues, resource exhaustion, or certificate problems.

Answer

Test DNS resolution from a pod on the node

Answer

Run 'kubectl describe pod' for pods on that node

Answer

Check the kube-apiserver logs on the master node

Question 15

A Pod is in CrashLoopBackOff. You run 'kubectl describe pod' and see that the container fails with 'Error: container command not found'. What is the most likely cause?

Accepted Answer

The container image does not contain the specified command. The error indicating a command is not found (typically presented as 'executable file not found in $PATH' in the container runtime events) most commonly occurs because the specified command or binary does not exist inside the container image at all (for example, trying to run 'bash' or 'curl' in a minimal distroless or scratch-based image, or due to a typo in the command name).

Answer

The container is running out of memory

Answer

The image pull is failing

Answer

The container command is not in the PATH