CKA Troubleshooting Practice Test 13 — 15 Questions

Question 1

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Accepted Answer

Check the kubelet service logs using 'journalctl -u kubelet'. Option B is correct because the kubelet is the node agent responsible for reporting node status to the API server; if it crashes, fails to register, or cannot reach the API server, the node transitions to NotReady, so inspecting its logs with 'journalctl -u kubelet' directly reveals the root cause. Option E is correct because a NotReady condition is frequently caused by the Container Network Interface (CNI) plugin (Calico, Flannel, etc.) not being ready, which prevents pod networking and triggers the 'NetworkPluginNotReady' condition on the node, so verifying those pods are running is a valid diagnostic step. Option A is not a diagnostic method but a remediation action, and restarting containers indiscriminately does not identify the cause. Option C is incorrect for this scenario because kube-apiserver logs on the control plane relate to API server issues, not the node's own readiness reporting. Option D is incorrect because kube-proxy handles Service load balancing via iptables/IPVS rules and its misconfiguration does not typically cause a node to report NotReady.

Answer

Restart all containers on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Check kube-proxy configuration

Question 2

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

Accepted Answer

The container's startup command has invalid arguments. Option A is correct because if the container's startup command (ENTRYPOINT/CMD) contains invalid arguments, the process exits immediately with a non-zero code, causing kubelet to restart it repeatedly and enter CrashLoopBackOff. Option C is correct because if the application attempts to bind to a port already in use inside the container, it fails at startup and exits, triggering the same restart loop. Option E is correct because a missing required environment variable typically causes the application to fail fast during initialization, again producing repeated crashes. Option B is not a CrashLoopBackOff cause: a nonexistent image results in an ImagePullBackOff or ErrImagePull state, since the container never starts. Option D is also not correct: an unbound PVC leaves the pod stuck in Pending (or ContainerCreating) due to an unschedulable volume, not in CrashLoopBackOff.

Answer

The container image does not exist

Answer

The PersistentVolumeClaim is not bound

Question 3

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. Option C is correct because the Kubernetes scheduler cannot bind a pod to any node when no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests, leaving the pod in Pending with a FailedScheduling event. Option E is correct because taints on nodes repel pods that lack a matching toleration, so the scheduler finds no feasible node and the pod remains Pending. Option A is wrong because OOM-killed containers occur after scheduling, producing CrashLoopBackOff or OOMKilled statuses on a running pod, not Pending. Option B is wrong because an image pull authentication failure happens on a node after the pod is already scheduled, resulting in ImagePullBackOff or ErrImagePull. Option D is wrong because rebooting a node affects already-running pods (e.g., eviction/rescheduling), not a pod that has never been scheduled.

Answer

Container is killed due to OOM

Answer

Container image pull fails because of authentication error

Answer

Node is rebooted

Question 4

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 5

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 6

After deploying a new Deployment, you notice that the pods are stuck in ImagePullBackOff. What is the most common cause?

Accepted Answer

The container image name or tag is incorrect. The ImagePullBackOff status indicates that the kubelet 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 an exponential backoff retry loop, leading to the ImagePullBackOff state.

Answer

The liveness probe is misconfigured

Answer

The node has insufficient resources

Answer

The container command fails on startup

Question 7

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

Accepted Answer

Add appropriate tolerations to the Pod's spec. The Pod is stuck in Pending because none of the nodes can schedule it due to taints that the Pod does not tolerate. Option D is correct because adding the appropriate tolerations to the Pod's spec tells the scheduler that the Pod can tolerate those taints, allowing it to be scheduled on the tainted nodes. This directly addresses the mismatch between node taints and Pod tolerations. A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

Answer

Increase the Pod's resource requests

Answer

Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'

Answer

Delete the Pod and recreate it with a different name

Question 8

Which command should you use to view the logs of a container that has previously crashed in a Pod?

Accepted Answer

kubectl logs --previous. `kubectl logs --previous` retrieves the logs from the previous instance of a container in a Pod, which is exactly what you need when a container has crashed and restarted. The `--previous` flag accesses the logs of the terminated (crashed) container, not the current running one, allowing you to see the error that caused the crash.

Answer

kubectl logs <pod-name>

Answer

kubectl describe pod <pod-name>

Answer

kubectl logs -c

Question 9

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

Question 10

You have a Deployment with the following resource limits for containers: memory: 256Mi. The pod is repeatedly killed with OOMKilled. You need to change the limit to 512Mi. Which field should you modify in the Deployment YAML?

Accepted Answer

spec.template.spec.containers[].resources.limits.memory. The OOMKilled error occurs when a container exceeds its memory limit. To resolve this, you must increase the memory limit in the Deployment's pod template. Option A correctly identifies the field `spec.template.spec.containers[].resources.limits.memory`, which directly controls the maximum memory the container can use before being killed by the OOM killer.

Answer

spec.template.spec.containers[].resources.requests.memory

Answer

spec.template.spec.containers[].resources.requests.cpu

Answer

spec.template.spec.containers[].resources.limits.cpu

Question 11

You are debugging a DNS issue in the cluster. Which of the following tools is commonly used to test DNS resolution from within a Pod?

Accepted Answer

nslookup. `nslookup` is a dedicated DNS lookup utility that queries DNS servers directly, making it the standard tool for testing DNS resolution from within a Pod. It sends DNS queries to the cluster's DNS service (e.g., CoreDNS or kube-dns) and returns the resolved IP addresses, allowing you to verify that DNS records for Services, Pods, or external hosts are correctly configured and reachable.

Answer

ping

Answer

tcpdump

Answer

curl

Question 12

A Pod is running but cannot connect to a Service. You have verified that the Service endpoints are correct. Which of the following is the most likely cause if the Pod is using hostNetwork: true?

Accepted Answer

The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration. When a Pod uses `hostNetwork: true`, it shares the node's network namespace and directly uses the host's network stack. ClusterIP Services are virtual IPs managed by iptables or IPVS rules on the node, but these rules are typically applied only to the host's network namespace. However, the most common issue is that the Pod's DNS resolver (e.g., `/etc/resolv.conf`) is configured to resolve the Service name via the cluster's DNS (CoreDNS/kube-dns), which returns a ClusterIP. Since the Pod is on the host network, it may not have the necessary iptables rules to route traffic to the ClusterIP, or the DNS configuration may point to a DNS server that is not reachable from the host network (e.g., the cluster DNS service IP itself). Option D correctly identifies that the Pod cannot resolve the ClusterIP due to DNS configuration, as the Pod's DNS settings are inherited from the node but may not include the cluster DNS server, or the cluster DNS is not accessible from the host network.

Answer

The kube-proxy is not running on the node

Answer

The Service is not defined correctly

Answer

The container image is missing networking tools

Question 13

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Accepted Answer

kubectl get events. Options A and B are correct. 'kubectl get events' shows events sorted by last timestamp by default, which satisfies the requirement. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation timestamp, also valid. Option C uses -w to watch, not sort. Option D sorts by name, not timestamp. Option E shows events from all namespaces but does not sort by timestamp.

Answer

kubectl get events -w

Answer

kubectl get events --sort-by=.metadata.name

Answer

kubectl get events --all-namespaces

Question 14

Which THREE of the following are common causes for a Pod to remain in Pending state? (Select THREE.)

Accepted Answer

Insufficient CPU or memory resources in the cluster. Option A is correct because when no node has enough allocatable CPU or memory to satisfy the Pod's resource requests, the scheduler cannot place the Pod and it stays in Pending. Option B is correct because taints on nodes that the Pod does not tolerate cause the scheduler to reject those nodes, leaving the Pod unscheduled and Pending. Option C is correct because a PersistentVolumeClaim that is not yet bound to a PersistentVolume blocks scheduling of Pods that reference it, keeping them in Pending. Option D does not belong because OOMKilled is a container termination reason that occurs after the Pod has been scheduled and started, producing a CrashLoopBackOff or Error state rather than Pending. Option E does not belong because an image pull error happens during kubelet container creation after scheduling, resulting in ImagePullBackOff or ErrImagePull, not Pending.

Answer

Container exits with OOMKilled

Answer

Image pull error due to incorrect image name

Question 15

You have a Pod that is in CrashLoopBackOff. Which TWO of the following commands would be most helpful in diagnosing the issue?

Accepted Answer

kubectl logs --previous. Option B, `kubectl logs --previous`, is correct because CrashLoopBackOff means the container has already restarted, so the `--previous` flag retrieves the logs from the last terminated container instance, which typically contains the actual crash/error output that caused the failure. Option C, `kubectl describe pod `, is correct because it shows the Pod's status conditions, container states (Waiting/Terminated with reason and exit code), restart count, and recent events such as image pull errors, OOMKilled, or failed probes, which are essential for pinpointing why the container keeps crashing. Option A, `kubectl get events --all-namespaces`, is not the best choice because it returns a broad cluster-wide event stream that is noisy and not scoped to the specific Pod, making it less efficient than describing the Pod itself. Option D, `kubectl logs `, is not the most helpful here because without `--previous` it targets the current container instance, which may not have produced logs yet or may not exist if the container is stuck restarting. Option E, `kubectl top pod `, is incorrect because it only reports CPU and memory usage metrics and provides no diagnostic information about the crash cause.

Answer

kubectl get events --all-namespaces

Answer

kubectl logs <pod-name>

Answer

kubectl top pod <pod-name>