CCNA Troubleshooting Questions — Page 2 of 2

MCQmedium

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. You want to see the logs of the last crashed instance. Which command should you run?

A.kubectl logs pod-name --previous

B.kubectl logs pod-name --all-containers

C.kubectl logs pod-name --last

D.kubectl logs pod-name

AnswerA

Correct. The --previous flag retrieves logs from the previous instance.

Why this answer

The `--previous` flag (or its shorthand `-p`) tells `kubectl logs` to retrieve logs from the previous instance of a container that has crashed and restarted. Since the pod is in `CrashLoopBackOff`, the current container has already exited, and you need to inspect the logs of the last terminated container to diagnose the crash. To avoid having two correct answers, Option C has been changed to an invalid flag.

Exam trap

The trap here is that candidates often think `kubectl logs pod-name` alone will show crash logs, but it only shows logs from the currently running container (which may be empty or not yet started), and they overlook the `--previous` flag that is specifically designed for accessing logs of a terminated container.

How to eliminate wrong answers

Option B is wrong because `--all-containers` streams logs from all containers in the pod simultaneously, but it does not retrieve logs from a previous (crashed) instance; it only shows current container logs. Option C is wrong because `-p` is the shorthand for `--previous`, so this option is actually correct and identical to A; however, the question expects the explicit `--previous` flag as the answer, and `-p` is not listed as a separate correct choice. Option D is wrong because `kubectl logs pod-name` without any flag only shows logs from the currently running container; in a `CrashLoopBackOff` state, the current container may have just started and has no useful logs, or the command may fail if no container is currently running.

Practice this question →

MCQhard

You are troubleshooting a pod that is in 'CrashLoopBackOff' state. You run 'kubectl logs mypod' and get no output. You then run 'kubectl logs mypod --previous' and see an error: 'Error: failed to start container: context deadline exceeded'. What is the MOST likely cause?

A.The container image is missing the entrypoint

B.The application inside the container is crashing immediately

C.The container command is incorrectly specified

D.The container runtime is unable to start the container due to a timeout

AnswerD

The 'context deadline exceeded' error indicates that the kubelet's or CRI runtime's operation to create or start the container exceeded its deadline before completing successfully. This is typical when the container runtime hangs during image pull, storage setup, runc init, or other pre-start steps, and after repeated failures the kubelet marks the pod as CrashLoopBackOff. It is a runtime-level timeout rather than an application or command issue, so inspecting the container runtime service and underlying node resources is the appropriate debugging path.

Why this answer

The error 'context deadline exceeded' indicates that the container runtime failed to start the container within the allowed time. This can happen if the container image takes too long to pull, the runtime is slow, or there is a network issue. Option A would produce an 'executable file not found' error.

Option B would result in the application crashing, but logs would show output before the crash. Option C would also show a similar error to A. Therefore, D is the most likely cause.

Practice this question →

MCQmedium

You run 'kubectl get nodes' and see that a node is 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. What is the most likely cause?

A.The network plugin is misconfigured

B.The node has been cordoned

C.The kubelet service is stopped

D.The container runtime is not installed

AnswerC

The kubelet is the primary agent responsible for registering the node with the Kubernetes API server and continuously reporting its health, resource utilization, and the status of pods running on it. If the kubelet service is stopped or inactive, it ceases to send heartbeats and status updates to the control plane. This complete lack of communication directly causes the API server to mark the node as `NotReady`, as it can no longer ascertain the node's operational state or manage its workloads.

Why this answer

The kubelet is the primary node agent that runs on every node and is responsible for maintaining pod lifecycles. When 'systemctl status kubelet' shows 'Active: inactive (dead)', it means the kubelet systemd service is not running. Since the kubelet must be active for the node to report its status to the control plane, a stopped kubelet directly causes the node to be 'NotReady'.

Exam trap

The trap here is that candidates often confuse a stopped kubelet with a kubelet that is running but unhealthy (e.g., due to container runtime issues), leading them to select option D, but the 'inactive (dead)' status specifically indicates the service is not running at all, not that it is failing to start.

How to eliminate wrong answers

Option A is wrong because a misconfigured network plugin (e.g., CNI) would cause pods to fail networking but the kubelet would still be running and the node would typically show 'Ready' with pod issues, not 'NotReady' due to a dead kubelet. Option B is wrong because cordoning a node (via 'kubectl cordon') marks it as 'SchedulingDisabled' but does not stop the kubelet; the node remains 'Ready' and the kubelet service stays active. Option D is wrong because if the container runtime (e.g., containerd or CRI-O) were not installed, the kubelet would fail to start or would crash-loop, but the service would show 'active (running)' or 'failed', not 'inactive (dead)'.

Practice this question →

MCQeasy

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

A.journalctl -u kubelet

B.systemctl status kube-apiserver or crictl ps | grep kube-apiserver

C.ps aux | grep kube-apiserver

D.docker ps | grep kube-apiserver

AnswerB

Correct. systemctl status kube-apiserver checks the systemd service, and kubectl get pods -n kube-system can list the apiserver pod if it's a static pod.

Why this answer

On a control plane node, the kube-apiserver runs either as a systemd service or as a static pod managed by the kubelet. If it runs as a systemd service, you check its status using 'systemctl status kube-apiserver'. If it runs as a static pod (as in kubeadm-based clusters), you must inspect the container runtime directly using 'crictl ps | grep kube-apiserver' (or 'docker ps' on older clusters) because 'kubectl' commands will fail if the API server is unresponsive.

Exam trap

Do not rely on 'kubectl' commands to troubleshoot a failing control plane, as kubectl requires a functioning kube-apiserver to return any results. Instead, use host-level tools like 'systemctl' or container-level tools like 'crictl'.

Practice this question →

MCQmedium

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?

A.ssh to the node and run 'docker ps'

B.kubectl describe node <node-name>

C.kubectl logs kubelet -n kube-system

D.systemctl status kubelet

AnswerD

The 'kubelet' runs as a 'systemd' service on each Kubernetes node, responsible for registering the node with the cluster and managing pods. To diagnose issues where a node is not ready, checking the 'kubelet' service status directly on the node using 'systemctl status kubelet' is the most effective first step. This command provides real-time information about whether the service is active, stopped, or failed, along with recent log entries that often pinpoint the root cause of any operational problems.

Why this answer

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.

Exam trap

The trap here is that candidates assume `kubectl describe node` is the first troubleshooting step for a NotReady node, but it only shows the symptom from the control plane's view, not the root cause on the node, which requires direct node access to check the kubelet service.

How to eliminate wrong answers

Option A is wrong because `docker ps` only lists running containers managed by Docker, not the kubelet service itself, and the kubelet may be running as a systemd unit or binary, not a container. Option B is wrong because `kubectl describe node` shows the node's status and conditions from the control plane's perspective, but if the kubelet is down, the API server may have stale data and cannot reveal the actual kubelet process state on the node. Option C is wrong because `kubectl logs kubelet -n kube-system` assumes the kubelet runs as a pod in the cluster, which is not the case—kubelet is a system-level daemon managed by systemd, not a Kubernetes workload, so its logs are accessed via `journalctl` or `systemctl`, not `kubectl logs`.

Practice this question →

MCQmedium

A pod has been restarted multiple times. You want to see the logs from the previous (terminated) container instance. Which command should you use?

A.kubectl logs my-pod -c --previous

B.kubectl logs my-pod --tail=100

C.kubectl logs my-pod -p

D.kubectl logs my-pod --past

AnswerC

Correct: The `-p` flag is a valid shorthand for `--previous` in `kubectl logs`, so this command retrieves logs from the previous terminated container instance.

Why this answer

The `kubectl logs` command retrieves logs for a container in a pod. To view the logs of a previously terminated container instance, you must use either the `--previous` or `-p` flag. To ensure there is only one correct option, we will change Option D to use an invalid flag (`--past`), leaving Option C (`-p`) as the sole correct answer.

Exam trap

Candidates often confuse the shorthand `-p` (for `--previous`) with other flags like `-c` (which specifies a container name) or assume that a longer, incorrect flag like `--past` or `--prev` is the correct syntax.

How to eliminate wrong answers

Option A is wrong because `-c` requires a container name argument (e.g., `-c my-container`), and `--previous` is misspelled as `--previous` (should be `--previous`); the syntax `-c --previous` is invalid and would cause an error. Option B is wrong because `--tail=100` only limits the log output to the last 100 lines of the current container instance, not the terminated one. Option C is wrong because `-p` is not a valid shorthand for `--previous`; the correct shorthand is `-p` does not exist—`kubectl logs` uses `--previous` (long flag) only, and `-p` is not recognized.

Practice this question →

MCQhard

You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?

A.A NetworkPolicy is blocking traffic from the test pod to the service IP.

B.The service type should be NodePort to allow in-cluster access.

C.The readiness probe is failing on all pods, causing them to be removed from service endpoints.

D.The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.

AnswerD

A Service's spec.selector uses exact key-value matching to choose backing pods. If the selector is app: payment and the pods are labeled app: payment-service, the values are different, so the Endpoints controller does not add any pod IP to the Service's backend. Label matching is exact, not substring-based, so the Service will have no endpoints and in-cluster clients cannot connect to it.

Why this answer

The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP.

The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.

Exam trap

The trap here is that candidates often assume a NetworkPolicy or readiness probe issue when they see 'Connection refused', but the empty endpoints list directly points to a selector mismatch, which is a fundamental Kubernetes networking concept tested in the CKA.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy can block traffic to pods or from specific sources, but it does not affect the Service's endpoint list; the endpoints would still be populated if the selector matched. Option B is wrong because ClusterIP is the correct type for in-cluster access; NodePort is used for external access and does not change internal connectivity. Option C is wrong because the readiness probe passes on all pods, as stated in the scenario, so pods would not be removed from endpoints; if the probe were failing, the pods would be removed, but the scenario explicitly says the readiness probe passes.

Practice this question →

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the CPU request for the container

C.Increase the memory limit in the pod's container resource specification

D.Delete and recreate the pod to clear the crash loop

AnswerC

Raising the memory limit in the pod's container resource specification directly addresses the cause of the CrashLoopBackOff: the kernel's OOM killer terminates the container when its memory usage exceeds the cgroup limit defined by spec.containers[].resources.limits.memory. Increasing this limit provides additional headroom for the application's legitimate memory footprint, allowing the container to remain within its constraint and avoiding repeated OOMKilled terminations. Be sure to verify that the node has enough allocatable memory and that limits are aligned with actual usage patterns.

Why this answer

OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification. Option A would delete the namespace and all workloads, which is too drastic and would affect other pods.

Option B increases CPU request, which does not address the memory issue. Option D deletes and recreates the pod without fixing the resource limits, so the crash loop would continue.

Practice this question →

MCQmedium

You have a Deployment with 3 replicas. One of the pods is in 'Pending' state. 'kubectl describe pod' shows: 'Warning FailedScheduling 0/4 nodes are available: 1 node(s) had taint {key1: value1}, that the pod didn't tolerate, 3 node(s) didn't match pod anti-affinity rules.' Which two issues are preventing the pod from being scheduled?

A.Taint toleration mismatch and pod anti-affinity conflicts

B.Pod anti-affinity and node selector issues

C.Node selector and taint toleration mismatch

D.Resource constraints and taint toleration mismatch

AnswerA

The event log explicitly reports a taint toleration mismatch, meaning the node carries taints the pod does not tolerate, and simultaneously reports a pod anti-affinity conflict, meaning the pod's scheduling constraints prevent it from co-locating with pods that match its anti-affinity selector. Both of these conditions together are present in the pod's unschedulable event. This answer correctly identifies the two distinct scheduling constraints that block the pod, so it is the right choice.

Why this answer

The error message explicitly states two distinct scheduling failures: '1 node(s) had taint {key1: value1}, that the pod didn't tolerate' and '3 node(s) didn't match pod anti-affinity rules.' These correspond directly to a taint toleration mismatch and pod anti-affinity conflicts. No other issues (node selector, resource constraints) are mentioned in the describe output.

Exam trap

The CKA exam often tests the ability to read the exact error message from `kubectl describe pod` and map each clause to a specific scheduling issue, rather than assuming generic problems like resource limits or node selectors.

How to eliminate wrong answers

Option B is wrong because the error message does not mention 'node selector' — it only references taint toleration and anti-affinity rules, so a node selector issue is not present. Option C is wrong because it includes 'node selector' which is not indicated in the error, and while taint toleration mismatch is correct, the second issue is anti-affinity, not node selector. Option D is wrong because 'resource constraints' (e.g., CPU/memory insufficient) would appear as 'Insufficient cpu' or 'Insufficient memory' in the describe output, not as a taint or anti-affinity message.

Practice this question →

Multi-Selecteasy

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Select 2 answers

A.kubectl get nodes

B.journalctl -u docker

C.journalctl -u kubelet

D.systemctl status kubelet

E.kubectl describe pod

AnswersC, D

journalctl -u kubelet is the correct first place to look because the kubelet is the component that actually reports NodeReady status to the API server and runs the node's static pods and system components. Kubelet logs will show concrete errors such as failed to GET /healthz, admission rejections, CNI plugin failures, or inability to connect to the API server, making this the most direct source of truth for diagnosing a NotReady node.

Why this answer

journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Practice this question →

MCQmedium

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

A.kubectl top pod <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl rollout status deployment <deployment-name>

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

AnswerB

Describe shows the last container state and exit code, plus events.

Why this answer

B is correct because `kubectl describe pod <pod-name>` 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 <pod-name> --previous`.

Exam trap

The CKA exam often tests your ability to troubleshoot failing pods. Candidates sometimes confuse `kubectl describe pod` (which shows metadata, events, and container exit codes/termination reasons) with `kubectl logs <pod-name> --previous` (which retrieves the actual application logs from the failed container). Both are critical troubleshooting steps, but `describe` is the primary tool for checking the high-level termination reason and exit code.

How to eliminate wrong answers

Option A is wrong because `kubectl top pod` shows real-time CPU and memory usage metrics, not crash reasons or container exit statuses. Option C is wrong because `kubectl rollout status deployment` checks the rollout progress of a deployment (e.g., whether new ReplicaSets are available), not the crash details of an individual pod. Option D is wrong because while `kubectl get events` can show pod-related events, the field selector `involvedObject.name=<pod-name>` filters events by the pod's name but may miss the container-level termination reason (which is stored in the pod's status, not always in events), and it does not provide the structured exit code and reason as `kubectl describe` does.

Practice this question →