CKA Troubleshooting Practice Test 10 — 15 Questions

Question 1

A pod runs but you cannot connect to its container port from another pod in the same namespace. 'kubectl exec' into the pod and 'curl localhost:8080' works. What is the MOST likely cause?

Accepted Answer

The pod is bound to localhost only, not 0.0.0.0. When `curl localhost:8080` works inside the pod but connections from other pods fail, the most likely cause is that the application is listening only on the loopback interface (127.0.0.1) instead of 0.0.0.0 (all interfaces). This means the container process binds to localhost, which is only reachable from within the same network namespace (the pod itself), not from external sources like other pods. Kubernetes networking relies on the container listening on 0.0.0.0 so that traffic arriving via the pod's eth0 interface (which has its own IP) can be accepted.

Answer

There is a NetworkPolicy blocking ingress

Answer

The container's port is not exposed in the pod spec

Answer

The Service selector does not match the pod labels

Question 2

Which THREE of the following are valid steps to troubleshoot a Node in NotReady state? (Choose three)

Accepted Answer

Run 'systemctl status kubelet' on the node. Option A is correct because a Node in NotReady state is most often caused by the kubelet service being stopped or failed, and 'systemctl status kubelet' on the node quickly reveals whether the kubelet is active, inactive, or in a failed state. Option C is correct because the kubelet requires a working CRI container runtime such as containerd (or CRI-O) to report node health; if containerd is down, the kubelet cannot manage pods and the node transitions to NotReady, so verifying the runtime is running is a valid troubleshooting step. Option E is correct because 'journalctl -u kubelet' surfaces the kubelet's own error messages (e.g., failed to get node status, CRI connection errors, certificate or cgroup driver problems) that explain why the node is NotReady. Option B is not a valid step because restarting the kube-apiserver on the control plane does not fix a node-local kubelet or runtime failure and would disrupt the whole cluster. Option D is not valid because 'kubectl delete node <node-name>' removes the Node object from the API server rather than re-registering it; the kubelet re-registers only when it restarts and reconnects, so deleting the node is not a troubleshooting step for NotReady.

Answer

Restart the kube-apiserver on the control plane

Answer

Run 'kubectl delete node <node-name>' to re-register

Question 3

Which TWO of the following are common causes of CrashLoopBackOff? (Choose two)

Accepted Answer

Misconfigured startup probe. CrashLoopBackOff occurs when a container repeatedly starts and then exits, and Kubernetes backs off restarting it. Option B is correct because a misconfigured startup probe (wrong path, port, or timing) causes kubelet to kill and restart the container before it can finish initializing, producing repeated crashes. Option D is correct because an application initialization failure (e.g., missing config, bad DB connection, unhandled exception at boot) makes the process exit immediately each time, which is the classic trigger for CrashLoopBackOff. Option A is not the direct cause: node resource pressure typically leads to eviction or Pending/OOMKilled states rather than the restart-backoff loop itself. Option C is not correct because a NetworkPolicy blocking egress usually causes runtime errors or timeouts, not necessarily a container exit loop. Option E is not correct because an unmounted PersistentVolume generally leaves the pod stuck in Pending or ContainerCreating, not in CrashLoopBackOff.

Answer

Node resource pressure (CPU/memory)

Answer

NetworkPolicy blocking egress

Answer

PersistentVolume not mounted

Question 4

A node in the cluster is reporting NotReady. You run 'journalctl -u kubelet' and see repeated errors: 'failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats'. What is the most likely cause?

Accepted Answer

Cgroup driver mismatch between kubelet and container runtime. The error 'failed to get cgroup stats' indicates that the kubelet cannot read container cgroup statistics, which typically occurs when the cgroup driver used by kubelet (e.g., cgroupfs) does not match the driver used by the container runtime (e.g., systemd). This mismatch prevents the kubelet from properly monitoring container resource usage, causing the node to report NotReady.

Answer

Disk pressure on the node

Answer

The node is out of memory

Answer

The kubelet service is not running

Question 5

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules'. What is the most likely cause?

Accepted Answer

The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive. The event '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules' directly indicates that the pod's scheduling is being blocked by anti-affinity constraints. Option B is correct because a `requiredDuringSchedulingIgnoredDuringExecution` anti-affinity rule is a hard constraint that must be satisfied at scheduling time; if no node meets the rule (e.g., the rule prevents co-location with other pods that are present on all nodes), the pod remains Pending.

Answer

The nodes have insufficient resources

Answer

The pod has a taint tolerance issue

Answer

The nodes are all cordoned

Question 6

A pod is in ImagePullBackOff state. Which command can you run to get more details about the underlying error?

Accepted Answer

kubectl describe pod. The `kubectl describe pod` command provides detailed information about the pod, including its status, conditions, events, and container states. For an `ImagePullBackOff` error, the output will include the exact error message from the container runtime (e.g., 'Failed to pull image', 'manifest not found', or 'unauthorized'), which is essential for diagnosing the root cause.

Answer

kubectl logs pod

Answer

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

Answer

kubectl top pod

Question 7

You want to view the resource usage of all pods in the cluster. What command should you run?

Accepted Answer

kubectl top pods --all-namespaces. The `kubectl top pods --all-namespaces` command retrieves real-time CPU and memory usage metrics for all pods across every namespace in the cluster. This is the correct way to view resource usage of all pods, as it relies on the metrics server to collect and expose pod-level resource consumption data.

Answer

kubectl describe nodes

Answer

kubectl get pods -o wide

Answer

kubectl top nodes

Question 8

A pod named 'web-app' is crashing repeatedly. You run 'kubectl describe pod web-app' and see that the container exited with code 137. What does this indicate?

Accepted Answer

The container was killed because it exceeded its memory limit. Exit code 137 (128 + 9) means the container was killed by SIGKILL (signal 9). In Kubernetes, this typically occurs when the container exceeds its memory limit (specified in `resources.limits.memory`), causing the OOM (Out-Of-Memory) killer to terminate the process. The `kubectl describe pod` output will also show `OOMKilled` in the `State` field under container status.

Answer

The container's entrypoint command failed

Answer

The container's readiness probe failed

Answer

The container image was not found

Question 9

You are troubleshooting a connectivity issue between two pods in the same cluster. Pod A cannot reach Pod B's IP. Which command would you run from Pod A to test connectivity?

Accepted Answer

kubectl exec pod-a -- curl . `kubectl exec pod-a -- curl ` runs the `curl` command inside Pod A, directly testing Layer 3 connectivity to Pod B's IP address. This bypasses any service or DNS abstraction and verifies whether the pod network (e.g., CNI plugin like Calico or Flannel) is functioning correctly between the two pods.

Answer

kubectl top pod pod-b

Answer

kubectl logs pod-b

Answer

kubectl describe pod-b

Question 10

A pod has been in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate, 2 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

Accepted Answer

The kubelet on each node is not running. The taints `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` are automatically added by the node controller when a node's kubelet stops reporting its status (the `node-monitor-grace-period`, default 40s, is exceeded). Since all three nodes exhibit these taints, the kubelet is not running on any of them, preventing the node from being marked `Ready` and causing the scheduler to find no suitable node for the pod.

Answer

The pod's image is incorrect

Answer

The pod has resource requests that exceed node capacity

Answer

The nodes are all cordoned

Question 11

You need to see the startup logs of the kubelet service. Which command should you use?

Accepted Answer

journalctl -u kubelet. `journalctl -u kubelet` retrieves the systemd journal logs for the kubelet service unit. Since kubelet runs as a systemd service on the node, its startup logs (including failures, configuration errors, or TLS bootstrap issues) are captured by journald and can be viewed with this command. This is the standard way to inspect kubelet's early boot-time behavior, which is not accessible via kubectl or systemctl status alone.

Answer

kubectl get events --all-namespaces

Answer

systemctl status kubelet

Answer

kubectl logs kubelet -n kube-system

Question 12

A pod is failing to start with the error 'CrashLoopBackOff'. You check the logs with 'kubectl logs pod' and see nothing. What is the most likely reason?

Accepted Answer

The container crashed before generating any log output. The 'CrashLoopBackOff' error indicates the container in the pod starts, crashes, and is repeatedly restarted by the kubelet. If 'kubectl logs pod' returns nothing, it means the container exited before writing any output to stdout/stderr, which is the default logging target for Kubernetes. Option B is correct because the container likely failed during initialization or startup, before any application code produced log entries.

Answer

The pod's log path is misconfigured

Answer

The kubelet has logging disabled

Answer

The pod is using a sidecar container for logging

Question 13

Which THREE of the following are valid steps to troubleshoot a DNS issue within a Kubernetes cluster?

Accepted Answer

Verify that the kube-dns service has endpoints using 'kubectl get endpoints -n kube-system kube-dns'. Option A is correct because verifying that the kube-dns service has endpoints with 'kubectl get endpoints -n kube-system kube-dns' confirms that the DNS service is properly backed by CoreDNS pods; if the endpoint list is empty, DNS resolution will fail cluster-wide. Option B is correct because inspecting CoreDNS pod logs via 'kubectl logs -n kube-system -l k8s-app=kube-dns' reveals errors such as plugin failures, upstream timeouts, or configuration problems that directly explain DNS resolution issues. Option E is correct because running 'kubectl exec -it busybox -- nslookup kubernetes.default' from inside a pod tests actual in-cluster DNS resolution against the kubernetes.default service, isolating whether the problem is DNS-specific or broader networking. Option C is not a valid cluster DNS troubleshooting step because /etc/resolv.conf on the node governs the node's own resolver, not the DNS configuration injected into pods (which comes from the pod's dnsPolicy and kubelet settings). Option D is not valid because restarting all nodes is a disruptive, non-targeted action that does not address DNS misconfiguration and is not an accepted troubleshooting procedure.

Answer

Check the /etc/resolv.conf on the node

Answer

Restart all nodes to reset DNS settings

Question 14

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Accepted Answer

Run 'kubectl get pods -n kube-system -l component=kube-apiserver'. Option C is correct because kube-apiserver typically runs as a static pod in the kube-system namespace, so 'kubectl get pods -n kube-system -l component=kube-apiserver' lets you verify the pod's status, readiness, and restart count. Option E is correct because the kube-apiserver exposes a /healthz endpoint on its secure port (6443 by default), and 'curl -k https://localhost:6443/healthz' returns 'ok' when the API server is healthy. Option A is wrong because 'kubectl top nodes' reports CPU and memory usage from metrics-server, not API server health. Option B is wrong because kube-apiserver is usually a static pod managed by the kubelet, not a systemd unit, so 'systemctl status kube-apiserver' would typically fail. Option D is wrong because 'journalctl -u kubelet' shows kubelet logs, which may reveal pod issues but does not directly check the kube-apiserver's health.

Answer

Run 'kubectl top nodes'

Answer

Run 'systemctl status kube-apiserver'

Answer

Run 'journalctl -u kubelet'

Question 15

You run 'kubectl get nodes' and see that one node is in the 'NotReady' state. Which command would you use FIRST to investigate the kubelet status on that node?

Accepted Answer

systemctl status kubelet. The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the first step is to check if the kubelet service is running on that node using `systemctl status kubelet` (or `journalctl -u kubelet`), because a stopped or unhealthy kubelet will directly cause the node to lose connectivity with the control plane. This command is the most direct way to verify the kubelet's process state and recent logs on the node itself.

Answer

ssh to the node and run 'docker ps'

Answer

kubectl describe node <node-name>

Answer

kubectl logs kubelet -n kube-system