Knowledge + Practice

CCNA Troubleshooting Questions

75 of 86 questions · Page 1/2 · Troubleshooting · Answers revealed

Practice these questions Domain overview All questions

1

MCQeasy

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

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl logs <pod-name> -c <container-name>

D.kubectl logs <pod-name> --previous

AnswerD

The --previous flag retrieves logs from the terminated container instance.

Why this answer

`kubectl logs <pod-name> --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.

Exam trap

The trap here is that candidates often assume `kubectl logs <pod-name>` alone will show crash logs, but it only shows the current container's logs, so they miss the `--previous` flag required for accessing logs from a terminated container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` only shows logs from the currently running container; if the container has crashed and restarted, the logs from the crash are lost from the current instance. Option B is wrong because `kubectl describe pod <pod-name>` shows the Pod's metadata, status, and events (including crash loop backoff details), but it does not display the container's log output. Option C is wrong because `kubectl logs <pod-name> -c <container-name>` is used to specify a container name when a Pod has multiple containers, but it still only shows logs from the current (running) container, not the previous crashed one.

Practice this question →

2

Multi-Selectmedium

A pod is stuck in 'Pending' state. Which TWO of the following are common causes?

Select 2 answers

A.The service account does not exist

B.A taint on the node that the pod does not tolerate

C.The pod's liveness probe is failing

D.Insufficient CPU or memory resources on any node

E.The pod's container image does not exist

AnswersB, D

Taints that are not tolerated prevent scheduling, causing Pending.

Why this answer

A pod enters 'Pending' state when it cannot be scheduled onto a node. Taints on a node with `NoSchedule` or `NoExecute` effects prevent pods that do not have matching tolerations from being scheduled there. This is a common cause because the scheduler skips tainted nodes unless the pod explicitly tolerates the taint, leaving the pod unscheduled and stuck in Pending.

Exam trap

The CKA exam often tests the distinction between pre-scheduling failures (Pending) and post-scheduling failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly select image or probe issues that occur after the pod is running.

Practice this question →

3

MCQhard

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?

A.The kube-proxy is not running on the node

B.The Service is not defined correctly

C.The container image is missing networking tools

D.The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration

AnswerD

When a Pod is configured with `hostNetwork: true`, it directly uses the node's network namespace, bypassing the Kubernetes CNI network. Consequently, such a pod inherits the node's `/etc/resolv.conf` for DNS resolution instead of the cluster's internal DNS (CoreDNS/kube-dns). The node's DNS resolver typically cannot resolve Kubernetes Service ClusterIPs, which are internal to the cluster's DNS domain, leading to name resolution failures for services. This specific DNS misconfiguration prevents the `hostNetwork` pod from finding the Service's IP address.

Why this answer

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.

Exam trap

The trap here is that candidates assume `hostNetwork: true` gives the Pod full access to all cluster services, but they overlook that DNS resolution for ClusterIP Services depends on the cluster DNS being reachable and properly configured in the Pod's resolv.conf, which is not automatically set when using hostNetwork.

How to eliminate wrong answers

Option A is wrong because kube-proxy runs on every node and is responsible for implementing Service rules (e.g., iptables/IPVS); if it were not running, no Pod (hostNetwork or not) would reach any Service, but the question states endpoints are correct, implying kube-proxy is functional. Option B is wrong because the question explicitly states that the Service endpoints are correct, meaning the Service definition itself is valid and has healthy endpoints. Option C is wrong because missing networking tools (e.g., curl, ping) would prevent the user from testing connectivity, but the Pod's inability to connect is a network-layer issue, not a tool availability issue; the Pod could still connect via raw sockets or other means if the network path worked.

Practice this question →

4

Multi-Selectmedium

A pod is stuck in 'Pending' state. Which THREE are common causes for this?

Select 3 answers

A.Node not registered with the cluster

B.Container image name is incorrect

C.Insufficient CPU or memory resources on any node

D.Node taints that the pod does not tolerate

E.PersistentVolumeClaim not bound to a volume

AnswersC, D, E

If no node has enough resources, the pod stays Pending.

Why this answer

A pod stuck in 'Pending' state means it has not been scheduled to a node yet, or it cannot start due to missing dependencies. The three most common causes are: insufficient CPU/memory resources on any node (C) because the scheduler cannot find a node that satisfies the pod's resource requests; node taints that the pod does not tolerate (D) which prevent scheduling; and an unbound PersistentVolumeClaim (E) that the pod requires before it can start. Option A is incorrect because a node not registered would not normally lead to a pod being pending—it would simply not be considered for scheduling.

Option B is incorrect because an incorrect container image name results in an ImagePullBackOff error, not a pending state.

Practice this question →

5

MCQeasy

You are troubleshooting a node that is in 'NotReady' state. Which command should you use to check the kubelet logs for errors?

A.journalctl -u kubelet

B.journalctl -u docker

C.journalctl -u kube-apiserver

D.journalctl -u kube-controller-manager

AnswerA

When a node is in a `NotReady` state, it signifies that the Kubelet, the agent running on the node, is unable to register itself with the API server or report its health status. The Kubelet is responsible for managing pods, reporting node status, and executing container operations. Therefore, examining the Kubelet's logs via `journalctl -u kubelet` provides direct insight into why it might be failing to communicate, experiencing resource issues, or encountering problems with the container runtime, making it the most critical first step for diagnosis.

Why this answer

The kubelet is the primary node agent that communicates with the control plane and manages pods. When a node is in 'NotReady' state, checking the kubelet logs is the first step to diagnose issues such as certificate errors, resource pressure, or network problems. The command `journalctl -u kubelet` retrieves logs from the systemd unit for the kubelet service, which is the correct way to view its output on systems using systemd.

Exam trap

The trap here is that candidates may confuse control plane components (kube-apiserver, kube-controller-manager) with node-level components, or mistakenly think the container runtime (Docker) is the primary source of node readiness logs, when in fact the kubelet is the authoritative agent for node status.

How to eliminate wrong answers

Option B is wrong because `journalctl -u docker` shows logs for the Docker daemon, not the kubelet; while container runtime issues can affect node readiness, the primary component to check for node status is the kubelet. Option C is wrong because `journalctl -u kube-apiserver` retrieves logs from the API server, which runs on the control plane, not on the worker node; this would not help diagnose a node-level issue. Option D is wrong because `journalctl -u kube-controller-manager` shows logs from the controller manager, another control plane component; it does not run on worker nodes and is irrelevant for troubleshooting a node's kubelet.

Practice this question →

6

Multi-Selectmedium

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

Select 2 answers

A.Restart all containers on the node

B.Check the kubelet service logs using 'journalctl -u kubelet'

C.Check the kube-apiserver logs on the control plane

D.Check kube-proxy configuration

E.Verify the network plugin (e.g., Calico, Flannel) pods are running

AnswersB, E

The kubelet is the component that reports Node status and manages pod lifecycle on each node; its logs often contain explicit error messages such as CNI failures, timeouts contacting the API server, or runtime issues. 'journalctl -u kubelet' allows you to view the kubelet's systemd journal, which is the authoritative source for why the kubelet has marked the node as NotReady. This is a direct, non-invasive diagnostic step that should be performed first when investigating node readiness problems.

Why this answer

Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (checking kube-proxy) is for service connectivity, not node readiness.

Option A (restarting all containers) is not relevant.

Practice this question →

7

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.Increase the CPU request for the container

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

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

D.Delete the namespace and redeploy all workloads

AnswerB

When a pod's container enters `CrashLoopBackOff` due to an `OOMKilled` event, it means the container tried to consume memory beyond its defined `limits.memory` in the pod specification. By increasing this memory limit, you provide the container with more available RAM, preventing the operating system's OOM killer from terminating the process. This allows the application to run stably without memory exhaustion, resolving the crash loop.

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. The correct fix is to increase the memory limit in the container's resource specification, allowing the container to use more memory without being killed. Simply deleting and recreating the pod would not resolve the underlying memory constraint, and adjusting CPU or deleting the namespace are irrelevant actions.

Exam trap

The trap here is that candidates may confuse OOMKilled with a CPU-related issue or think that simply restarting the pod will fix the problem, but the OOMKilled status explicitly indicates memory exhaustion, requiring a resource limit adjustment.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request does not affect memory usage; the OOM killer is triggered by memory exhaustion, not CPU. Option C is wrong because deleting and recreating the pod would only restart the same container with the same resource limits, leading to the same OOMKilled crash loop. Option D is wrong because deleting the entire namespace and all workloads is an extreme, unnecessary action that would cause data loss and service disruption, and does not address the specific memory limit issue.

Practice this question →

8

Multi-Selectmedium

Which two commands can be used to view the logs of a container that has crashed? (Choose two.)

Select 2 answers

A.journalctl -u kubelet

B.kubectl logs pod-name --previous

C.kubectl describe pod pod-name

D.systemctl status kubelet

E.kubectl logs pod-name

AnswersB, E

Shows logs of the terminated container.

Why this answer

To view the logs of a container that has crashed, you can use `kubectl logs pod-name` (Option E) to view the logs of the current container instance (even if it is currently in a terminated or waiting state), or `kubectl logs pod-name --previous` (Option B) to view the logs of the previous instance if the container has restarted.

`journalctl -u kubelet` (Option A) and `systemctl status kubelet` (Option D) show the logs and status of the kubelet system service itself, not the stdout/stderr of individual containers. `kubectl describe pod` (Option C) shows pod events and metadata but does not display the container's stdout/stderr logs.

Exam trap

Candidates often think that systemd services like the kubelet store container logs directly. In Kubernetes, container stdout/stderr logs are managed by the container runtime (like containerd) and written to `/var/log/pods`, which `kubectl logs` reads. The kubelet logs themselves only contain cluster-level lifecycle events, not container application logs.

Practice this question →

9

MCQeasy

Which kubectl command is used to view the logs of a container that has previously crashed in a pod?

A.kubectl logs pod-name -c container-name --tail=100

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

C.kubectl logs pod-name --previous

D.kubectl logs pod-name

AnswerC

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

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and been restarted. This is essential for debugging crash loops, as the current container may have no logs or only startup logs, while the crashed container's logs contain the error.

Exam trap

The trap here is that candidates assume `kubectl logs` without flags or with `--tail` will show crash logs, but they only see the current container's logs, missing the critical error from the previous crashed instance.

How to eliminate wrong answers

Option A is wrong because `--tail=100` limits the log output to the last 100 lines of the current container's logs, but does not access logs from a previously crashed instance; it is useful for reducing output, not for crash debugging. Option B is wrong because `--all-containers` streams logs from all containers in the pod simultaneously, but it still only shows current container logs, not the logs of a container that has crashed and restarted. Option D is wrong because `kubectl logs pod-name` without flags shows only the current container's logs; if the container has crashed and been replaced, the current container's logs may be empty or irrelevant, missing the crash context.

Practice this question →

10

Multi-Selectmedium

A pod is in 'Pending' state. 'kubectl describe pod' shows: '0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' Which THREE actions would resolve the issue? (Choose three)

Select 3 answers

A.Remove the taint from the control-plane nodes.

B.Decrease the memory request of the pod.

C.Increase the CPU request of the pod.

D.Add a toleration to the pod for the control-plane taint.

E.Add a node selector to the pod that matches the control-plane nodes.

AnswersA, B, D

Removing the taint from control-plane nodes makes those nodes schedulable for the pod, provided they have sufficient memory. This is a valid solution.

Why this answer

The pod cannot be scheduled because one node lacks memory and two nodes have a control-plane taint. Any single action that resolves either the memory issue (decreasing memory request) or the taint issue (removing taint or adding toleration) will make a node available. Since the question asks for three actions, A, B, and D are the correct choices as each independently resolves the scheduling block.

Options C and E do not address the reported problems.

Exam trap

Be careful with scheduling issues. A pod only needs one suitable node to schedule. You do not need to resolve the issues on all 3 nodes; resolving the issue on either the memory-constrained node (Option B) OR the tainted nodes (Options A or D) is sufficient to transition the pod out of the 'Pending' state.

Practice this question →

11

MCQeasy

Which command shows all events in the cluster sorted by timestamp?

A.kubectl describe events

B.kubectl get events

C.kubectl logs --all-namespaces

D.kubectl get events --sort-by=.metadata.creationTimestamp

AnswerD

D is incorrect because although `--sort-by=.metadata.creationTimestamp` sorts events, it sorts by a different timestamp field (creationTimestamp) than the default (lastTimestamp), and the question expects the default sorting behavior without additional flags. Moreover, the event ordering might not match the intended 'sorted by timestamp' meaning when events have multiple timestamps.

Why this answer

According to the official Kubernetes Cheat Sheet, the standard and documented command to list events sorted by timestamp is `kubectl get events --sort-by='.metadata.creationTimestamp'`. While modern versions of kubectl apply some default sorting, using the explicit `--sort-by` flag is the precise, guaranteed, and exam-expected method.

Exam trap

The CKA exam is open-book (using official documentation). If you search the official docs for sorting events, it explicitly directs you to use `kubectl get events --sort-by='.metadata.creationTimestamp'`. Relying on default behavior without the flag can lead to incorrect assumptions or missed points on the exam.

How to eliminate wrong answers

Option A is wrong because `kubectl describe events` does not exist as a valid command; `kubectl describe` is used for resources like pods or nodes, not for events, and would produce an error or unintended output. Option C is wrong because `kubectl logs --all-namespaces` retrieves container logs, not cluster events, and logs are not sorted by timestamp in the same way; this command addresses a different troubleshooting domain. Option D is wrong because while `kubectl get events --sort-by=.metadata.creationTimestamp` would work, it is unnecessarily verbose since `kubectl get events` already sorts by timestamp by default; the question asks for the command that shows events sorted by timestamp, and the extra flag is redundant and not the simplest correct answer.

Practice this question →

12

MCQhard

You have a multi-node cluster. One node shows 'NotReady'. You run 'journalctl -u kubelet' on that node and see 'network plugin is not ready'. What is the most likely cause?

A.The CNI plugin pod (e.g., Calico) is not running on that node

B.The container runtime (e.g., containerd) is down

C.The kubelet service is not running

D.The node's IP address has changed

AnswerA

The kubelet agent on each node continuously monitors the health and operational status of the CNI plugin. If the CNI plugin's pod (e.g., Calico, Flannel) crashes, fails its readiness probes, or is not running on a specific node, the kubelet cannot properly configure network interfaces for pods or establish essential network routes. Consequently, the kubelet reports the node's status as `NotReady` with the specific `NetworkPluginNotReady` condition, indicating a fundamental failure in the node's networking capabilities.

Why this answer

The 'network plugin is not ready' error from kubelet indicates that the kubelet is waiting for a CNI (Container Network Interface) plugin to configure the pod network. If the CNI plugin pod (e.g., Calico, Flannel, Weave) is not running on that specific node, the kubelet cannot set up the network for pods, causing the node to remain in 'NotReady' state. This is the most direct cause because the kubelet relies on the CNI plugin to report readiness before marking the node as Ready.

Exam trap

The trap here is that candidates often confuse 'network plugin is not ready' with a general network connectivity issue or a kubelet failure, but the error specifically points to the CNI plugin not being operational on that node, not the kubelet itself or the container runtime.

How to eliminate wrong answers

Option B is wrong because if the container runtime (e.g., containerd) were down, the kubelet would report a different error, such as 'container runtime is down' or 'failed to connect to containerd', not a network plugin error. Option C is wrong because if the kubelet service were not running, you would not be able to run 'journalctl -u kubelet' successfully, and the node would not show 'NotReady' but would be unreachable entirely. Option D is wrong because a changed node IP address would cause kubelet to fail to register with the control plane, typically resulting in 'Node not found' or authentication errors, not a 'network plugin is not ready' message.

Practice this question →

13

Multi-Selectmedium

A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)

Select 2 answers

A.A pod on the node is in ImagePullBackOff

B.The node has insufficient memory

C.The kubelet service has stopped on the node

D.The Kubernetes API server is down

E.The network plugin (e.g., Calico, Flannel) is not functioning

AnswersC, E

When the kubelet service stops on a node, it can no longer send periodic StatusUpdates (heartbeats) to the API server. After the node-monitor-grace-period expires without a heartbeat, the kube-controller-manager marks the node as NotReady, and even if the node is restarted, the status remains until a healthy kubelet reports again.

Why this answer

Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status.

Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.

Practice this question →

14

MCQhard

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?

A.spec.template.spec.containers[].resources.limits.memory

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

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

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

AnswerA

The container's memory limit is implemented as a cgroup v2 (or v1) limit on the memory cgroup to which that container belongs. When the container's resident set size plus page cache exceeds this limit, the kernel's out-of-memory (OOM) killer selects a process in that cgroup — usually the container's main PID — and kills it, resulting in OOMKilled. Increasing spec.template.spec.containers[].resources.limits.memory raises this cgroup ceiling, giving the container more usable memory headroom before the kernel decides to kill its process, which is exactly why this field addresses the reported OOMKilled status.

Why this answer

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.

Exam trap

The trap here is that candidates confuse `requests` (which only affects scheduling and QoS class) with `limits` (which enforces hard resource caps), leading them to mistakenly modify `requests.memory` instead of `limits.memory` to fix an OOMKilled issue.

How to eliminate wrong answers

Option B is wrong because `resources.requests.memory` is the minimum memory guaranteed to the container, not the limit that triggers OOMKilled; changing requests does not prevent the OOM killer from terminating the container if it exceeds the limit. Option C is wrong because `resources.requests.cpu` sets the minimum CPU allocation, which has no effect on memory-related OOM kills. Option D is wrong because `resources.limits.cpu` caps CPU usage, not memory; exceeding the CPU limit causes throttling, not OOMKilled.

Practice this question →

15

MCQmedium

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

A.kubectl describe pod <pod-name>

B.kubectl top pod <pod-name>

C.kubectl logs <pod-name>

D.kubectl get events

AnswerA

"kubectl describe pod <pod-name>" provides a comprehensive summary of a pod's current state, including its status, events, and container specifications. When a pod is in `ImagePullBackOff`, this command will display the specific events related to the image pull attempt, such as `Failed` or `ErrImagePull`, along with the exact error message from the container runtime. This detailed output is crucial for diagnosing the root cause, such as an incorrect image name, a private registry authentication failure, or network issues, making it the most direct and effective diagnostic tool.

Why this answer

A is correct because 'kubectl describe pod <pod-name>' provides detailed information about the pod, including the container status, events, and the exact error message from the image pull attempt. This output includes the reason for the ImagePullBackOff, such as a missing image, incorrect tag, authentication failure, or network issue, which is essential for troubleshooting.

Exam trap

The trap here is that candidates often choose 'kubectl logs' thinking it will show the error, but logs only exist if the container started; for ImagePullBackOff, the container never runs, so logs are empty and the describe command is the correct tool.

How to eliminate wrong answers

Option B is wrong because 'kubectl top pod' shows resource usage (CPU/memory) and does not provide any information about image pull failures. Option C is wrong because 'kubectl logs' retrieves container logs, but if the container never started due to ImagePullBackOff, there are no logs to fetch; the error is in the pod status, not in stdout/stderr. Option D is wrong because 'kubectl get events' shows cluster-wide events, but it may not include the specific image pull error for the pod, and it is less detailed than the pod description; the describe command is the standard tool for this scenario.

Practice this question →

16

MCQhard

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?

A.Increase the Pod's resource requests

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

C.Delete the Pod and recreate it with a different name

D.Add appropriate tolerations to the Pod's spec

AnswerD

Adding matching tolerations to the Pod's specification directly instructs the kube-scheduler that this Pod is allowed to run on nodes with corresponding taints. This is the standard, least-privilege method to resolve scheduling issues on tainted nodes without compromising the cluster's overall node isolation strategy. Once the toleration is applied, the scheduler can successfully bind the Pod to the tainted node.

Why this answer

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.

Exam trap

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.

How to eliminate wrong answers

Option A is wrong because increasing resource requests would only worsen scheduling constraints, not resolve taint/toleration mismatches. Option B is wrong because removing taints from all nodes is an overly broad and potentially disruptive action; the correct approach is to add tolerations to the Pod, not modify cluster-wide node settings. Option C is wrong because simply deleting and recreating the Pod with a different name does not change its toleration configuration, so it would still be stuck in Pending.

Practice this question →

17

MCQhard

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?

A.There is a NetworkPolicy blocking ingress

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

C.The Service selector does not match the pod labels

D.The pod is bound to localhost only, not 0.0.0.0

AnswerD

Binding to localhost (127.0.0.1) restricts connections to only the same network namespace, which is isolated to the container itself. Kubernetes networking relies on the pod's IP address and virtual Ethernet interfaces, so a loopback bind cannot receive traffic from outside the pod. Listening on 0.0.0.0 makes the port available on all interfaces, including the pod's external-facing one.

Why this answer

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.

Exam trap

The trap here is that candidates often assume a Service issue (Option C) is the cause, but the question specifies direct pod-to-pod connectivity (not via a Service), so the real problem is the application binding to localhost, which is a classic application-layer misconfiguration rather than a Kubernetes networking misconfiguration.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy blocking ingress would prevent connections from other pods even if the application is correctly listening on 0.0.0.0, but the fact that `curl localhost:8080` works inside the pod does not rule out a NetworkPolicy; however, the symptom of localhost working while external connections fail points directly to a binding issue, not a policy. Option B is wrong because the container's port not being exposed in the pod spec (i.e., missing `containerPort`) does not affect whether the application listens on the correct interface; it only affects service discovery and documentation, not actual network connectivity. Option C is wrong because the Service selector not matching pod labels would prevent traffic from reaching the pod via the Service, but the question states the connection attempt is 'from another pod in the same namespace' — this could be direct pod-to-pod via IP, which bypasses the Service entirely, so a mismatched selector would not explain the failure.

Practice this question →

18

MCQeasy

Which command shows all events in the cluster, sorted by timestamp?

A.kubectl logs --all-namespaces [wrong]

B.kubectl top events [wrong]

C.kubectl describe events [wrong]

D.kubectl get events -A --sort-by='.metadata.creationTimestamp'

Why this answer

To retrieve all events across the entire cluster, the `-A` or `--all-namespaces` flag must be used. The correct command is `kubectl get events -A --sort-by='.metadata.creationTimestamp'`. The `--sort-by` flag uses a JSONPath expression to order the output based on the creation timestamp of the events.

Exam trap

Candidates often forget that `kubectl get events` is namespace-scoped by default and will only return events for the active namespace unless `-A` or `--all-namespaces` is explicitly provided.

How to eliminate wrong answers

Option A is wrong because `kubectl logs --all-namespaces` retrieves container logs, not cluster events; logs are output from containers, while events are Kubernetes API objects recording state changes. Option B is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (nodes/pods), not events. Option C is wrong because `kubectl describe events` shows detailed information about events but does not sort them by timestamp; it displays events in a default order (often by last timestamp) and is not designed for sorted output.

Practice this question →

19

MCQhard

You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?

A.Check if the kube-proxy is running on the node hosting pod-b

B.Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'

C.Check if the container runtime is Docker

D.Check if the DNS resolution for pod-b's service is correct

AnswerB

A NetworkPolicy is a namespaced Kubernetes resource that acts as a pod-level firewall, and if cluster networking is configured with a CNI that enforces it, any ingress rule can explicitly deny traffic from pods in other namespaces. The default behavior is allow-all only when no NetworkPolicy selects the pod; once one exists, the default becomes deny for anything not matched by its rules. If a policy selects pod-b and its ingress list does not include namespace 'foo' or a matching podSelector, it will silently drop the TCP SYN packets from pod-a, making the port 5432 connection time out or refuse while the service IP ping still succeeds.

Why this answer

Since pod-a can reach the Kubernetes service IP, the issue is likely a NetworkPolicy that denies ingress traffic from namespace 'foo' to pod-b on port 5432. NetworkPolicies can restrict cross-namespace traffic. Options A, C, and D are less likely because kube-proxy, container runtime, and DNS are not the primary suspects when connectivity to the service IP works.

Practice this question →

20

Multi-Selecthard

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Select 3 answers

A.The kubelet cannot contact the API server

B.The kubelet service is stopped

C.The node has disk pressure

D.A pod on the node is consuming excessive memory

E.The network plugin (e.g., Calico, Flannel) is not running

AnswersA, B, E

The kubelet is responsible for registering the node with the API server and continuously reporting its health and status. If the kubelet loses its ability to communicate with the API server, it cannot send its periodic heartbeats or update the node's conditions. After a default timeout period, the control plane will mark the node as NotReady because it has stopped receiving updates, indicating a potential issue with the node's availability or connectivity.

Why this answer

The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Exam trap

The trap here is that candidates confuse node conditions like 'DiskPressure' or 'MemoryPressure' with the 'NotReady' status, but these conditions do not change the 'Ready' status unless the kubelet itself fails to report.

Practice this question →

21

MCQhard

You are troubleshooting a pod that cannot start. Running 'kubectl describe pod' shows the event: 'Failed to pull image "myregistry.io/myapp:1.0": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry.io/myapp:1.0 not found'. What is the MOST likely cause?

A.The registry is unreachable due to network issues

B.The image tag '1.0' does not exist in the registry

C.The image registry requires authentication and the imagePullSecret is missing

D.The image has been deleted from the registry

AnswerB

The 'manifest not found' error explicitly indicates that the container runtime successfully contacted the image registry but could not locate the specific image manifest associated with the requested tag '1.0'. This means the registry confirmed its existence but reported that no image with that precise tag is available. This is the most direct and accurate interpretation of the given error message, signifying the tag itself is absent.

Why this answer

The error message 'manifest for myregistry.io/myapp:1.0 not found' indicates that the registry successfully received the pull request but could not locate the specific image tag '1.0'. This is a manifest lookup failure, not a connectivity or authentication issue. The most likely cause is that the tag '1.0' does not exist in the repository, either because it was never pushed or was removed.

Exam trap

The trap here is that candidates confuse 'manifest not found' with network or authentication errors, but the specific wording of the error message directly points to a missing tag in the registry, not connectivity or credentials.

How to eliminate wrong answers

Option A is wrong because network issues would produce a different error, such as 'dial tcp: lookup myregistry.io: no such host' or 'connection refused', not a manifest-not-found error. Option C is wrong because missing authentication would result in a 'denied: requested access to the resource is denied' or 'unauthorized: authentication required' error, not a manifest-not-found error. Option D is wrong because if the image had been deleted from the registry, the registry would typically still have the manifest metadata and would return a 'not found' for the blob, but the error specifically says 'manifest not found', which means the tag itself is missing—this is functionally the same as the tag never existing, but the phrasing 'deleted' implies the tag existed before, which is less likely given the exact error message; however, the most precise cause is that the tag does not exist in the registry's index.

Practice this question →

22

MCQeasy

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

A.systemctl start --enable kubelet

B.systemctl enable kubelet

C.systemctl enable --now kubelet

D.systemctl start kubelet

AnswerC

This is the correct command to resolve the `NotReady` status and ensure future stability. The `systemctl enable --now kubelet` command not only configures the `kubelet` service to start automatically during subsequent system boots but also immediately starts the service in the current session. This dual action ensures the `kubelet` is running right away, allowing the node to quickly transition to a `Ready` state without requiring a manual reboot.

Why this answer

`systemctl enable --now kubelet` both starts the kubelet service immediately and creates the necessary symlinks to enable it to start automatically on boot. This is the most efficient way to handle a stopped service that needs to be persistent across reboots, which is critical for a Kubernetes node to rejoin the cluster after a reboot.

Exam trap

The trap here is that candidates often confuse `systemctl start` with `systemctl enable`, or assume that `systemctl start` alone is sufficient, overlooking the requirement to persist the service across reboots, which is a common cause of nodes failing to rejoin after a reboot in production.

How to eliminate wrong answers

Option A is wrong because `systemctl start --enable` is not a valid systemctl syntax; the correct flag for simultaneous start and enable is `--now`. Option B is wrong because `systemctl enable kubelet` only creates the boot-time symlinks but does not start the service immediately, leaving the node in a NotReady state until a manual start or reboot. Option D is wrong because `systemctl start kubelet` starts the service only for the current session; after a reboot, the kubelet will not start automatically, and the node will again report NotReady.

Practice this question →

23

MCQhard

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

A.Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod

B.The pod has a resource request that exceeds available CPU on all nodes

C.The pod does not tolerate any taints, and all nodes have taints

D.The cluster has only one node with sufficient CPU, but it is cordoned

AnswerA

The kubectl describe pod output lists Events from the scheduler. In this case, the events directly report two distinct issues: three nodes have insufficient CPU to satisfy the pod's resource request, and one node has a taint for which the pod has no matching toleration. Since these are the exact messages shown, this option correctly captures the full diagnosis.

Why this answer

The event message explicitly states that 1 node has a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate, and 3 nodes have insufficient CPU. This means the pod's CPU request cannot be satisfied on three nodes, and the remaining node is tainted, leaving no schedulable node. Option A correctly identifies this combination of issues.

Exam trap

The trap here is that candidates may misinterpret '0/4 nodes are available' as all nodes having the same issue, but the event message lists distinct reasons per node, requiring careful reading to identify the combination of taint and resource insufficiency.

How to eliminate wrong answers

Option B is wrong because the event shows only 3 nodes have insufficient CPU, not all 4; one node has a taint issue, not a CPU shortage. Option C is wrong because the event indicates only 1 node has a taint, not all nodes; the other 3 nodes have insufficient CPU, not taints. Option D is wrong because the event does not mention any node being cordoned; it specifically cites taint and insufficient CPU as the reasons.

Practice this question →

24

MCQmedium

You need to check the resource usage of nodes in your cluster. Which command should you run?

A.kubectl top nodes

B.kubectl get nodes -o wide

C.kubectl logs --all-containers

D.kubectl describe nodes

AnswerA

The "kubectl top nodes" command queries the Metrics Server API to retrieve and display the current, real-time CPU and memory utilization of all nodes in the cluster. This is the standard, built-in command used by administrators to quickly identify resource-constrained nodes. It requires the Metrics Server to be properly installed and running in the cluster to function.

Why this answer

`kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster. This command relies on the metrics server being deployed and functioning, which aggregates resource usage data from kubelet’s cAdvisor endpoint. It is the standard Kubernetes command for checking node-level resource consumption.

Exam trap

The trap here is that candidates often confuse `kubectl describe nodes` (which shows static capacity and allocatable resources) with `kubectl top nodes` (which shows dynamic, real-time usage), leading them to choose option D when they need actual consumption data.

How to eliminate wrong answers

Option B is wrong because `kubectl get nodes -o wide` shows additional node information such as internal IP, external IP, and OS image, but does not display resource usage metrics. Option C is wrong because `kubectl logs --all-containers` retrieves container logs from a pod, not node-level resource usage. Option D is wrong because `kubectl describe nodes` provides detailed node status, conditions, and capacity/allocatable resources, but does not show current real-time resource consumption like `kubectl top nodes` does.

Practice this question →

25

MCQmedium

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

A.An init container in the pod is failing and restarting

B.The pod's init container ran successfully but the main container has not started yet

C.The pod is still initializing but will eventually run

D.The main container is crashing and the pod is restarting

AnswerA

When a pod's status displays Init:CrashLoopBackOff, it indicates that one of its defined init containers has exited with a non-zero status code and is repeatedly failing during startup. Kubernetes will continuously attempt to restart this failing init container before it can proceed to the main application containers, blocking the pod from reaching the Running state.

Why this answer

The status 'Init:CrashLoopBackOff' indicates that an init container within the pod is failing and being repeatedly restarted by Kubernetes. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, Kubernetes retries it with an exponential backoff delay, leading to the CrashLoopBackOff state. This is distinct from a main container crash, which would show 'CrashLoopBackOff' without the 'Init:' prefix.

Exam trap

The CKA exam often tests the distinction between init container failures and main container failures by using the 'Init:' prefix in the status, so candidates who overlook this prefix may mistakenly choose the main container crash option.

How to eliminate wrong answers

Option B is wrong because if an init container ran successfully, the pod would proceed to start the main container, not remain in an 'Init:' status; the 'Init:' prefix specifically indicates an init container is still running or failing. Option C is wrong because 'Init:CrashLoopBackOff' is not a transient initialization state—it signals a persistent failure with restarts, not eventual success without intervention. Option D is wrong because a crashing main container would show 'CrashLoopBackOff' (without 'Init:'), not 'Init:CrashLoopBackOff', which explicitly points to an init container issue.

Practice this question →

26

MCQmedium

A developer reports that a Pod named 'web-pod' in namespace 'frontend' is crashing repeatedly. You run 'kubectl logs web-pod -n frontend' but see no output. Which command should you run next to see the logs from the previous, crashed container instance?

A.kubectl get events -n frontend --sort-by=.metadata.creationTimestamp

B.kubectl logs web-pod -n frontend --previous

C.kubectl logs web-pod -n frontend -c web-pod

D.kubectl exec -it web-pod -n frontend -- sh

AnswerB

This command is the correct approach because the --previous (or -p) flag instructs the kubelet to retrieve the stdout and stderr logs from the most recently terminated instance of the container. This is essential for diagnosing CrashLoopBackOff states where the current container has restarted and its active log buffer is empty or irrelevant.

Why this answer

The `kubectl logs --previous` flag retrieves logs from the previous instance of a container in a Pod, which is exactly what you need when the current container has crashed and restarted, leaving no logs from the current instance. Since `kubectl logs web-pod -n frontend` returned no output, the current container likely started fresh after a crash, and the logs from the crashed container are stored in the terminated container's log file. This flag accesses those logs without needing to specify a container name explicitly when there is only one container in the Pod.

Exam trap

The trap here is that candidates may think `kubectl logs` without flags is sufficient, or they may confuse `--previous` with `-c` (container name), not realizing that `--previous` is specifically designed to access logs from a terminated container instance, while `-c` only selects a container within a multi-container Pod.

How to eliminate wrong answers

Option A is wrong because `kubectl get events` shows cluster events (e.g., scheduling, pulling images) but does not provide container logs, which are needed to debug the crash. Option C is wrong because `-c web-pod` specifies a container name, but if the Pod has only one container (named 'web-pod'), this command is redundant and still fetches logs from the current (possibly empty) container, not the previous crashed instance. Option D is wrong because `kubectl exec` opens an interactive shell into the running container, but if the container is crashing repeatedly, it may not be running, and even if it were, this would not retrieve logs from the previous terminated instance.

Practice this question →

27

MCQeasy

You need to check the current resource usage of nodes in your cluster. Which command should you use?

A.kubectl top pods

B.kubectl get events

C.kubectl get nodes -o wide

D.kubectl top nodes

AnswerD

kubectl top nodes is the correct command because it queries the metrics.k8s.io API provided by metrics-server to return each node’s current total CPU and memory usage, along with the percentage relative to allocatable capacity. It aggregates pod usage plus node-level system reservations from cAdvisor and presents a concise per-node snapshot, making it the standard built-in way to assess current node resource consumption.

Why this answer

`kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster, directly answering the question about current resource usage. This command relies on the metrics server being deployed in the cluster to collect resource utilization data from kubelets via the Summary API.

Exam trap

The trap here is that candidates confuse `kubectl top nodes` with `kubectl get nodes -o wide`, mistakenly thinking the latter shows resource usage when it only shows network and OS details, not utilization metrics.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods` shows resource usage for pods, not nodes, so it does not meet the requirement to check node-level resource usage. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, pod lifecycle changes) and does not provide any resource utilization metrics. Option C is wrong because `kubectl get nodes -o wide` displays node metadata such as internal IP, external IP, and OS image, but not real-time CPU or memory usage.

Practice this question →

28

MCQeasy

Which command can you run to see the events related to a specific pod?

A.kubectl logs pod-name

B.kubectl get pod pod-name

C.kubectl get events

D.kubectl describe pod pod-name

AnswerD

kubectl describe pod pod-name retrieves the Pod's full configuration along with a dedicated 'Events' section that records timestamped, sequential notifications from the kubelet and controller-manager about that Pod. These events describe actions like scheduling decisions, container creation, image pulling, probe failures, and restarts, which are exactly what you need when debugging why a Pod is stuck or repeatedly crashing. The describe command aggregates just the events for that specific Pod, making it the direct answer to the question.

Why this answer

`kubectl describe pod pod-name` includes a dedicated 'Events' section that lists all lifecycle events for that specific pod, such as scheduling, container pulls, and restarts. This command filters events to only those relevant to the pod, making it the most direct way to view pod-specific events without needing to parse all cluster events.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (application output) with `kubectl describe` (cluster events), or assume `kubectl get events` is the only way to view events, missing that `kubectl describe` automatically filters events for the specified resource.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod-name` retrieves the container's stdout/stderr logs, not Kubernetes events; logs show application output, not cluster-level scheduling or lifecycle events. Option B is wrong because `kubectl get pod pod-name` only displays the pod's current status and metadata in a summary table, omitting the detailed event history. Option C is wrong because `kubectl get events` lists all events across the entire namespace or cluster, requiring manual filtering to find those related to a specific pod, which is less efficient and not targeted.

Practice this question →

29

Multi-Selectmedium

You need to check the status of control plane components. Which TWO commands are appropriate?

Select 2 answers

A.kubectl get pods -n kube-system

B.systemctl status kube-apiserver

C.kubectl get componentstatuses

D.top -u kube

E.systemctl list-units --type=service

AnswersA, C

Shows pods for control plane components if running as static pods.

Why this answer

To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.

Exam trap

The CKA exam environment is built using kubeadm. Do not look for systemd services for the apiserver, controller-manager, or scheduler, as they run as static pods. Only the kubelet and the container runtime (e.g., containerd) run as systemd services on the nodes.

Practice this question →

30

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.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

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

D.Delete the namespace and redeploy all workloads

AnswerA

A CrashLoopBackOff status frequently indicates that a container is repeatedly crashing and being restarted by Kubernetes. When the underlying cause is an OOMKilled event, it means the container attempted to consume more memory than specified by its configured `resources.limits.memory`. Increasing this memory limit directly addresses the root cause by providing the container with sufficient memory resources, thereby preventing the operating system from terminating the process due to out-of-memory conditions and allowing the pod to stabilize.

Why this answer

The OOMKilled status indicates the container was terminated by the Linux Out-of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Exam trap

The trap here is that candidates may confuse OOMKilled with a general crash loop and choose to delete/recreate the pod, not realizing that the pod will simply crash again with the same memory limit.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory constraints; CPU throttling or limits are unrelated to OOM kills. Option C is wrong because deleting and recreating the pod only restarts the same container with the same memory limit, so it will likely be OOMKilled again immediately. Option D is wrong because deleting the entire namespace and all workloads is an extreme, unnecessary action that disrupts all services and does not fix the underlying memory limit issue.

Practice this question →

31

MCQmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

A.The pod's liveness probe is misconfigured

B.The pod's container image is missing

C.The database service is not running or is unreachable

D.The pod has a memory limit that is too low

AnswerC

A connection refused error—specifically ECONNREFUSED—indicates that the application's TCP handshake reached the target host but nothing was listening on that port, or the service endpoints are empty because the backing database pods are not ready. This commonly occurs when the database Deployment has zero ready replicas, the Service selector does not match any pods, or the pod is using an incorrect service name or port. The container's main process exits after failing to initialize its database connection, and the kubelet restarts it, cycling into CrashLoopBackOff.

Why this answer

The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.

Exam trap

The CKA exam often tests the distinction between application-level errors (like 'connection refused') and infrastructure-level errors (like OOM or image pull failures), so candidates must read the exact error message in the logs rather than assuming a generic pod failure cause.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted after it had started, not produce a 'connection refused' error in the application logs; liveness probes check container health after startup, not database connectivity. Option B is wrong because a missing container image would result in an 'ImagePullBackOff' or 'ErrImagePull' status, not a 'CrashLoopBackOff' with a database connection error in the logs. Option D is wrong because a memory limit that is too low would cause an 'OOMKilled' status or 'OutOfMemory' error in the logs, not a TCP connection refused error.

Practice this question →

32

MCQmedium

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

A.The liveness probe is misconfigured

B.The node has insufficient resources

C.The container image name or tag is incorrect

D.The container command fails on startup

AnswerC

Providing an invalid image name or an unavailable tag causes the container registry to return a 404 error to the kubelet. Consequently, the pod transitions into `ErrImagePull` and then `ImagePullBackOff` because the container runtime cannot locate or download the specified image layers.

Why this answer

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.

Exam trap

The trap here is that candidates confuse ImagePullBackOff with CrashLoopBackOff, but ImagePullBackOff specifically relates to image retrieval failures, not container runtime errors.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe causes the container to be restarted or killed (CrashLoopBackOff), not an image pull failure. Option B is wrong because insufficient node resources result in a PodPending state with events like 'FailedScheduling' or 'OutOfMemory', not ImagePullBackOff. Option D is wrong because a container command that fails on startup leads to a CrashLoopBackOff state, as the container exits immediately after starting, not an image pull issue.

Practice this question →

33

MCQmedium

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

A.Increase the pod's resource requests

B.Remove the taint from the control-plane node

C.Use a different namespace

D.Add a toleration to the pod spec matching the taint

AnswerD

Adding a toleration to the pod spec that matches the node's taint is the correct solution because tolerations explicitly opt a pod into scheduling on tainted nodes. The taint on the node uses key, value, and effect (e.g., node-role.kubernetes.io/control-plane:NoSchedule), and the toleration must mirror that key, value, and effect before the scheduler will place the pod there. This is the standard, least-privilege way to run a specific workload on a dedicated or control-plane node without weakening cluster-wide policies.

Why this answer

The pod is in Pending state because the control-plane nodes have a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate. By default, pods are not scheduled on control-plane nodes unless they explicitly tolerate that taint. Adding a toleration to the pod spec that matches the taint's key, effect, and optionally value allows the scheduler to place the pod on a control-plane node.

Exam trap

The trap here is that candidates may think removing the taint (Option B) is the correct fix, but the CKA exam expects you to use tolerations to selectively schedule pods on tainted nodes without altering node configuration.

How to eliminate wrong answers

Option A is wrong because increasing resource requests does not address taints or tolerations; it may even make scheduling harder by requiring more resources. Option B is wrong because removing the taint from the control-plane node would allow all pods to schedule there, which is not the intended solution for a specific pod and could compromise node isolation. Option C is wrong because namespaces are a logical isolation boundary and have no effect on taint/toleration mechanics or scheduling decisions.

Practice this question →

34

MCQmedium

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

A.kubectl logs pod

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

C.kubectl describe pod

D.kubectl top pod

AnswerC

Events in the pod description include the reason for ImagePullBackOff.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which shows application output) with `kubectl describe` (which shows pod lifecycle events and container runtime errors), leading them to choose A when the container never started to produce logs.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` retrieves container logs, which are generated by the application inside the container; if the container never started due to ImagePullBackOff, there are no logs to fetch. Option B is wrong because `kubectl get events` with a field selector filters events by the pod's name, but the output may not include the detailed pull error from the kubelet or container runtime; `kubectl describe pod` consolidates those events alongside other critical status fields. Option D is wrong because `kubectl top pod` shows resource usage (CPU/memory) of running pods, which is irrelevant when the pod is in a non-running state like ImagePullBackOff.

Practice this question →

35

Multi-Selectmedium

A pod is in 'Pending' state. Which TWO of the following are possible causes? (Select 2)

Select 2 answers

A.Node has insufficient CPU or memory resources

B.Container exited with non-zero exit code

C.PersistentVolumeClaim is not bound

D.Container was killed due to OOM

E.Image name is misspelled

AnswersA, C

A Pod can only stay Pending when the scheduler is unable to place it on a node. If every node lacks sufficient allocatable CPU and/or memory to satisfy the Pod's `resources.requests`, kube-scheduler marks the Pod unschedulable and leaves it in Pending while continuously retrying scheduling. This is purely a pre-scheduling condition, so it remains until a node is scaled up or the requests are reduced.

Why this answer

Options A and C are correct. A pod remains in 'Pending' state when it cannot be scheduled or when required resources are not available. Insufficient CPU or memory resources (A) prevent the scheduler from placing the pod.

An unbound PersistentVolumeClaim (C) causes the pod to wait until the claim is bound. Option B: container exited with non-zero exit code would result in a CrashLoopBackOff or error state, not Pending. Option D: container killed due to OOM would cause the container to restart and enter CrashLoopBackOff.

Option E: misspelled image name leads to ImagePullBackOff, not Pending.

Practice this question →

36

MCQmedium

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?

A.The pod's image is incorrect

B.The kubelet on each node is not running

C.The pod has resource requests that exceed node capacity

D.The nodes are all cordoned

AnswerB

When kubelet is not running on a node, the node's heartbeat to the control plane is absent; after the node-monitor-grace-period, the Node controller marks the node NotReady and applies the node.kubernetes.io/not-ready:NoSchedule taint. Since no nodes are schedulable, the kube-scheduler cannot find a match for the pod, leaving it in Pending indefinitely. This is often the systemic cause when all nodes are unreachable or their kubelets have crashed.

Why this answer

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.

Exam trap

A common trap is confusing taints added automatically by the node controller (like `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`) with taints added manually by an administrator (like `node.kubernetes.io/unschedulable` from `kubectl cordon`). In this scenario, the presence of these automatic taints on all nodes indicates that the kubelet is not running, not that nodes are cordoned.

How to eliminate wrong answers

Option A is wrong because an incorrect image would cause a `ErrImagePull` or `ImagePullBackOff` event, not a `Pending` state with taint-based scheduling failures. Option C is wrong because resource requests exceeding node capacity would produce events like `Insufficient cpu` or `Insufficient memory`, not taints related to node readiness or reachability. Option D is wrong because cordoned nodes have the `node.kubernetes.io/unschedulable:NoSchedule` taint (added by `kubectl cordon`), not the `not-ready` or `unreachable` taints; additionally, cordoning does not affect all nodes simultaneously unless explicitly done.

Practice this question →

37

MCQmedium

You suspect a DNS issue inside a pod. Which command can you run to test DNS resolution from within a pod?

A.kubectl logs coredns -n kube-system

B.kubectl describe svc kubernetes

C.kubectl run test --image=busybox -- nslookup kubernetes.default

D.kubectl exec <pod-name> -- nslookup kubernetes.default

AnswerD

`kubectl exec <pod-name> -- nslookup kubernetes.default` runs the `nslookup` binary directly inside the target pod's network namespace. This uses the pod's own `/etc/resolv.conf`, including its `nameserver` (typically the kube-dns ClusterIP) and search domains (such as `default.svc.cluster.local`), to perform a real DNS query. It is the most direct way to verify that the pod can resolve a service name, because it replicates exactly what an application in that pod would experience.

Why this answer

The correct command to test DNS resolution from within a pod is `kubectl exec <pod-name> -- nslookup kubernetes.default`. This runs the nslookup command inside an existing pod, directly testing DNS resolution from that pod's perspective. Option A (kubectl logs coredns) shows CoreDNS logs, not a DNS test.

Option B (kubectl describe svc kubernetes) shows service details, not DNS resolution. Option C (kubectl run test --image=busybox -- nslookup kubernetes.default) creates a new pod to run the command, but the question asks for testing from within an existing pod, so exec is appropriate.

Practice this question →

38

MCQhard

A pod is running but cannot be accessed via its ClusterIP service from another pod in the same namespace. The service endpoints list shows the pod's IP. What is the most likely cause?

A.The kube-proxy is not running on the node

B.A NetworkPolicy is blocking the traffic

C.The service's targetPort is incorrect

D.The pod is running on a different node without proper routing

AnswerB

NetworkPolicy is a namespace-scoped firewall that can restrict egress traffic from a specific pod (via podSelector) to a destination service's backing pod IP or CIDR. Even if the Service object and endpoints are intact, a NetworkPolicy denying egress from the source pod to the backend pod's IP or port will silently drop the packets, making the Service unreachable only for the affected pod(s).

Why this answer

A NetworkPolicy can explicitly deny ingress traffic to a pod even when the service endpoints are correctly populated. Since the endpoints list shows the pod's IP, the service and pod are communicating at the network layer, but a NetworkPolicy with an ingress rule that does not allow traffic from the source pod's labels or CIDR will cause the packet to be dropped by the node's iptables or eBPF rules, resulting in a connection timeout or reset from the client pod.

Exam trap

The trap here is that candidates assume a populated endpoints list guarantees connectivity, but they overlook that NetworkPolicies operate at a lower layer (L3/L4) and can block traffic even when the service and pod are correctly configured.

Why the other options are wrong

A

kube-proxy issues would affect all services cluster-wide, not just one service with correct endpoints.

C

If targetPort were wrong, endpoints might still show but traffic would not reach the container; but endpoints are based on the container port, so if endpoints exist, targetPort matches.

D

ClusterIP services work across nodes; no extra routing needed.

Practice this question →

39

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.Delete and recreate the pod to clear the crash loop

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

AnswerD

An `OOMKilled` event signifies that the container exceeded its configured memory limit, prompting the Linux kernel's Out-Of-Memory killer to terminate the process. By increasing the `memory.limits` within the pod's container resource specification, we provide the application with a larger memory ceiling. This directly addresses the root cause, allowing the container to consume the necessary RAM without being terminated, thereby resolving the `CrashLoopBackOff`.

Why this answer

The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being killed by the Out-of-Memory (OOM) killer. This directly addresses the root cause of the CrashLoopBackOff state.

Exam trap

The trap here is that candidates may confuse CPU and memory resource management, incorrectly assuming that increasing CPU requests (option B) will resolve memory exhaustion, or they may opt for a superficial fix like recreating the pod (option C) without addressing the underlying resource limit.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not address the underlying memory constraint; it would only restart the pod with the same insufficient memory limit. Option B is wrong because increasing the CPU request does not affect memory usage or prevent OOM kills; CPU and memory are separate resources managed independently by the kubelet. Option C is wrong because deleting and recreating the pod would only restart it with the same memory limit, leading to the same OOMKilled crash loop; it does not resolve the resource exhaustion.

Practice this question →

40

MCQhard

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?

A.The nodes have insufficient resources

B.The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive

C.The pod has a taint tolerance issue

D.The nodes are all cordoned

AnswerB

A requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule is a hard constraint: the scheduler will only place the pod on a node that satisfies every term of the rule. If the rule's label selector and topologyKey match labels on pods running on every available node, no node passes the check. The resulting event is '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules,' and the pod stays Pending until a node no longer runs a conflicting pod or the rule is updated. This is the only option where the pod's own scheduling constraints, not cluster conditions, make all nodes ineligible.

Why this answer

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.

Exam trap

CNCF often tests the distinction between hard and soft scheduling constraints; the trap here is that candidates may confuse anti-affinity errors with resource insufficiency or taint issues, but the specific event message directly points to anti-affinity rules.

How to eliminate wrong answers

Option A is wrong because insufficient resources would produce events like 'Insufficient cpu' or 'Insufficient memory', not a message about anti-affinity rules. Option C is wrong because taint/toleration issues generate events such as 'node(s) had taints that the pod didn't tolerate', not anti-affinity mismatches. Option D is wrong because cordoned nodes produce events like 'node(s) were cordoned' or 'node(s) were unschedulable', not a message about pod anti-affinity rules.

Practice this question →

41

MCQmedium

A pod is stuck in 'Pending' state. Which command would you run FIRST to diagnose the issue?

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl top pod <pod-name>

D.kubectl exec -it <pod-name> -- sh

AnswerB

kubectl describe pod <pod-name> is the correct diagnostic command because it aggregates the pod's object metadata, current status, conditions, and most importantly, recent Events from the API server, scheduler, and kubelet. For a Pending pod, the Events section reveals whether the scheduler failed due to insufficient resources, taints/tolerations, node selector mismatches, or whether a PersistentVolume claim is awaiting binding — the precise reason for the stuck state.

Why this answer

A pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

Exam trap

The trap here is that candidates often jump to `kubectl logs` or `kubectl exec` out of habit, forgetting that these commands only work for running pods, while 'Pending' indicates a pre-scheduling failure that requires inspecting events and conditions via `kubectl describe`.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` retrieves container logs, but a pod in 'Pending' has no running containers yet, so there are no logs to fetch. Option C is wrong because `kubectl top pod` shows real-time resource usage metrics, which require the pod to be running on a node; a pending pod has no metrics. Option D is wrong because `kubectl exec` requires a running container to execute commands, which is impossible when the pod is still pending.

Practice this question →

42

MCQmedium

You are trying to debug a network connectivity issue between two pods. Pod A can reach the internet but cannot reach Pod B's IP address. Which command should you use to test connectivity from within Pod A to Pod B's service?

A.kubectl exec pod-a -- nslookup service-b

B.curl http://<node-ip>:<nodeport>

C.ssh node-ip 'curl http://<pod-b-ip>:80'

D.kubectl exec pod-a -- curl http://service-b:80

AnswerD

This is the most effective command because `kubectl exec` runs `curl` directly within the network namespace of `pod-a`, simulating the exact origin of the communication. By targeting `http://service-b:80`, it simultaneously tests DNS resolution of the service name, the ability to establish a TCP connection to the service's ClusterIP on port 80, and the application's responsiveness. This provides a comprehensive end-to-end test from the perspective of the source pod.

Why this answer

It uses `kubectl exec` to run a command inside Pod A, then uses `curl` to reach Pod B's service by its DNS name (`service-b`) and port 80. This tests connectivity from Pod A's network namespace to the ClusterIP service, which is the correct way to verify pod-to-service communication within the cluster. Using the service name leverages Kubernetes internal DNS (CoreDNS) to resolve to the service's virtual IP, and `curl` sends an HTTP request to confirm reachability.

Exam trap

The trap here is that candidates confuse testing pod-to-service connectivity (which requires using the service DNS name from within the pod) with testing node-to-pod or DNS-only checks, leading them to pick options that bypass the pod's network namespace or only test DNS resolution.

How to eliminate wrong answers

Option A is wrong because `nslookup` only tests DNS resolution of the service name, not actual network connectivity to the service IP or pod. Option B is wrong because it tests connectivity from the node to the NodePort, not from within Pod A to the service; this bypasses Pod A's network namespace and does not verify pod-to-service communication. Option C is wrong because it runs `curl` from the node (via SSH) to Pod B's IP, which tests node-to-pod connectivity, not pod-to-service connectivity from within Pod A.

Practice this question →

43

MCQmedium

You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?

A.kubectl describe svc kubernetes -n default

B.kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local

C.kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local

D.kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local

AnswerD

Executing `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` is the most direct and effective method for debugging DNS resolution issues from within a specific pod. This command leverages `kubectl exec` to run `nslookup` directly inside `my-pod`, utilizing that pod's `/etc/resolv.conf` and its configured DNS server. It precisely tests whether the pod itself can successfully resolve the fully qualified domain name (FQDN) of the `kubernetes` service, providing immediate insight into its DNS capabilities.

Why this answer

`kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` runs the `nslookup` command directly inside the running pod, which uses the pod's configured DNS resolver (typically CoreDNS) to resolve the Kubernetes service FQDN. This is the standard method to test DNS resolution from within a pod, as it bypasses any external DNS and validates the cluster's internal DNS chain.

Exam trap

The trap here is that candidates often choose Option B (curl) thinking it tests DNS, but curl tests HTTP connectivity, not resolution; or they choose Option C (kubectl run) which creates a new pod with default DNS settings, missing the specific pod's DNS configuration that may be the root cause of the issue.

How to eliminate wrong answers

Option A is wrong because `kubectl describe svc kubernetes -n default` only shows the service's metadata and endpoints, not DNS resolution; it does not test the pod's ability to resolve the name. Option B is wrong because `curl` tests HTTP connectivity, not DNS resolution; a successful curl could still hide a DNS failure if the IP is cached or resolved via other means, and busybox may not include curl by default. Option C is wrong because `kubectl run test --image=busybox -- nslookup ...` creates a new ephemeral pod, which is unnecessary and slower; it also does not test DNS from the existing pod that is experiencing the issue, missing the specific pod's DNS configuration (e.g., dnsPolicy, resolv.conf).

Practice this question →

44

MCQmedium

Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?

A.kubectl describe node node-1

B.kubectl top pod api-6f4d7b9d4c-abcde -n production

C.kubectl get deployment api -n production -o yaml

D.kubectl logs api-6f4d7b9d4c-abcde -n production --previous

AnswerD

kubectl logs api-6f4d7b9d4c-abcde -n production --previous is the correct command because it fetches the stdout/stderr from the previous, now-terminated container instance in the pod. In a CrashLoopBackOff, the currently restarted container usually has no useful logs — it may not have started, or it immediately restarted before writing anything — while the last crashed instance carries the actual error that triggered the restart. This gives you the application-level failure message (e.g., uncaught exception, missing config, listen EADDRINUSE) needed to fix the root cause; pair it with kubectl describe pod to see the last exit code and restart count.

Why this answer

The pod is in CrashLoopBackOff, which means the container starts, crashes, and restarts repeatedly. The `kubectl logs --previous` command retrieves the logs from the previous (crashed) container instance, which is the fastest way to see the error that caused the crash. This directly reveals the root cause, such as a missing dependency, configuration error, or application panic.

Exam trap

The trap here is that candidates may think `kubectl describe pod` or `kubectl get deployment` is needed to check the pod's status or configuration, but the fastest way to see the crash reason is the previous container's logs, not the current (restarted) container's logs which may be empty.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node` shows node-level conditions and resource usage, not the application error causing the container to crash. Option B is wrong because `kubectl top pod` shows current CPU/memory metrics, which are irrelevant to a crash loop caused by an application error. Option C is wrong because `kubectl get deployment -o yaml` shows the desired state and pod template, but not the runtime logs or crash reason from the container.

Practice this question →

45

Multi-Selecthard

You are troubleshooting a pod that is in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. Which TWO actions can resolve the issue?

Select 2 answers

A.Reduce the memory request in the container spec to fit available memory

B.Add a node selector to the pod spec to target a specific node

C.Increase the memory request to prioritize scheduling

D.Add resource limits without changing requests

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

AnswersA, E

Reducing memory request may allow the pod to fit on a node.

Why this answer

The pod is pending because the single node in the cluster (0/1 nodes available) has two blocking issues: 1) Insufficient memory to satisfy the pod's request, and 2) a control-plane taint that the pod does not tolerate. To resolve this and allow the pod to schedule on this node, both issues must be addressed: you must reduce the memory request in the container spec to fit the available memory (Option A) AND add a toleration for the control-plane taint to the pod spec (Option E).

Exam trap

In a single-node cluster (indicated by '0/1 nodes are available'), any scheduling failure message lists all reasons why that single node failed. You must resolve all listed constraints (both the taint and the resource insufficiency) for the pod to schedule.

Practice this question →

46

MCQmedium

A pod is in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

A.The image registry requires authentication and no imagePullSecrets are configured

B.The image tag does not exist

C.The image name is misspelled

D.The container requires more memory than the limit allows

AnswerD

If a container demands more memory than its limit allows, the image has already been successfully pulled and the container has started, so the failure mode is OOMKilled or an overloaded kubelet eviction, not ImagePullBackOff. ImagePullBackOff is exclusively a pre-start image acquisition failure, making this the one option that could never produce that state.

Why this answer

Insufficient memory would cause OOMKilled, not ImagePullBackOff. ImagePullBackOff is caused by issues pulling the container image: wrong image name (C), nonexistent tag (B), authentication failure (A), or registry unreachable. Options A, B, and C are all common causes of ImagePullBackOff.

Practice this question →

47

MCQeasy

A pod is in ImagePullBackOff state. Which command would give you the most information about why the image pull failed?

A.kubectl get pod

B.kubectl logs <pod-name>

C.kubectl edit pod <pod-name>

D.kubectl describe pod <pod-name>

AnswerD

The `kubectl describe pod` command is the correct diagnostic because it aggregates the pod's status conditions, container states, and, crucially, the recent Events list from the kubelet and the image puller. For an `ImagePullBackOff`, the events will contain a specific reason such as `ErrImagePull`, `ImagePullBackOff`, `Failed to pull image`, or a registry authentication/not found error with the exact HTTP status. This detailed output is exactly what you need to pinpoint whether the problem is a typo in the image tag, missing credentials, or network connectivity to the registry.

Why this answer

`kubectl describe pod <pod-name>` provides detailed event logs, including the exact error message from the kubelet when it failed to pull the container image. This output includes the reason for the ImagePullBackOff state, such as authentication failures, image not found, or network issues, which is the most comprehensive information for troubleshooting.

Exam trap

The trap here is that candidates often think `kubectl logs` will show the error, but since the container never started, there are no logs; the real diagnostic data is in the pod's events and status conditions, which only `kubectl describe` reveals.

How to eliminate wrong answers

Option A is wrong because `kubectl get pod` only shows the current status (e.g., ImagePullBackOff) without any details about why the pull failed. Option B is wrong because `kubectl logs <pod-name>` retrieves container logs, but if the container never started due to an image pull failure, there are no logs to display. Option C is wrong because `kubectl edit pod <pod-name>` opens the pod specification for editing, which does not show the pull failure reason; it only allows you to modify the pod definition, which is not diagnostic.

Practice this question →

48

MCQhard

Based on the exhibit, what is the most likely cause of the pod not running?

A.The volume driver is not installed on node-1.

B.The pod has exceeded its resource limits.

C.The node 'node-1' is experiencing disk pressure.

D.The Secret 'my-secret' does not exist in the namespace.

AnswerD

The exhibit's event message contains the exact Kubernetes error string: the secret `my-secret` could not be found in the pod's namespace, so the kubelet is unable to inject the environment variable or volume content required by the container spec. Every Secret reference is namespaced, and the kubelet queries the API server for the secret exactly as it appears in the pod manifest; any typo, wrong namespace, or omitted resource will immediately produce this failure. Because the error is explicit and points to a missing API object, the most likely cause is that `my-secret` simply does not exist in the namespace where the Pod is running.

Why this answer

The pod's status indicates it is waiting for a secret to be mounted, and the error message 'secret "my-secret" not found' directly points to the missing Secret resource. Without the Secret existing in the same namespace as the pod, the volume mount fails, preventing the pod from starting.

Exam trap

The trap here is that candidates may assume the issue is node-level (disk pressure or driver) or resource-related, overlooking the specific error message about the missing Secret, which is a common misdirection in CKA troubleshooting questions.

How to eliminate wrong answers

Option A is wrong because a missing volume driver would typically result in a different error, such as 'failed to mount volume' or 'driver not supported', not a secret not found error. Option B is wrong because exceeding resource limits would cause the pod to be in a CrashLoopBackOff or OOMKilled state, not a waiting state for a secret. Option C is wrong because disk pressure on node-1 would manifest as pod eviction or scheduling failures, not a secret mount error.

Practice this question →

49

Multi-Selectmedium

You run 'kubectl logs pod-name' and get no output. Which TWO steps should you take to troubleshoot further?

Select 2 answers

A.Run 'kubectl get events --all-namespaces'

B.Run 'kubectl top pod pod-name' to check resource usage

C.Run 'kubectl describe pod pod-name' to check container state and events

D.Run 'kubectl logs --previous pod-name'

E.Run 'kubectl exec pod-name -- cat /var/log/container.log'

AnswersC, D

`kubectl describe pod pod-name` is a correct first step because it shows container states (Waiting, Running, Terminated) with detailed reason and message fields—for example, `CrashLoopBackOff`, `ImagePullBackOff`, or `OOMKilled`. It also lists recent events specific to that pod, such as failed volume mounts or failed liveness probes, which directly explain why a container may have never produced logs or why its log stream was cut short. When `kubectl logs` returns nothing, this command reveals whether the container even started, and if it did, what caused it to terminate or restart, making it an essential troubleshooting action.

Why this answer

Run 'kubectl describe pod pod-name' (option C) to check container state and events, and 'kubectl logs --previous pod-name' (option D) to retrieve logs from the previous container instance if the pod restarted. These are the two most direct steps to troubleshoot missing logs.

Practice this question →

50

Multi-Selecthard

You are troubleshooting a scenario where a pod cannot communicate with another pod in the same namespace via service name. Which THREE steps would you take to diagnose the issue? (Select 3)

Select 3 answers

A.Run 'kubectl get nodes' to check node status

B.Run 'kubectl get endpoints' to verify the service has healthy endpoints

C.Exec into the pod and use curl to test connectivity to the service's cluster IP

D.Run 'kubectl logs' on the target pod to check application logs

E.Exec into the pod and run nslookup to verify DNS resolution of the service name

AnswersB, C, E

A Kubernetes Service only forwards traffic to Pod IPs listed in its Endpoints object, which are populated by the controller based on matching selectors and the readiness status of pods. If the selector matches no pods, or the pods are not Ready (e.g., failing readiness probes or CrashLoopBackOff), the Endpoints object is empty, so connections to the Service's ClusterIP are dropped or refused. Running 'kubectl get endpoints' is the quickest way to confirm whether the Service actually has healthy, Ready backends, directly exposing the most common cause of communication failure.

Why this answer

Options B, C, and E are correct. Checking endpoints (B) verifies the service has healthy pods. Exec into the pod and using curl (C) tests connectivity to the service's cluster IP.

Exec into the pod and running nslookup (E) checks DNS resolution of the service name. Option A checks node status, which is not directly related to pod-to-pod communication via service name. Option D checks logs of the target pod, which may not reveal network issues.

Practice this question →

51

Multi-Selecthard

You have a pod that is in CrashLoopBackOff. Which two troubleshooting steps should you take first? (Choose two.)

Select 2 answers

A.kubectl describe pod pod-name

B.kubectl delete pod pod-name

C.kubectl logs pod-name --previous

D.kubectl exec -it pod-name -- sh

E.kubectl rollout restart deployment

AnswersA, C

kubectl describe pod pod-name is correct for CrashLoopBackOff because it displays the pod's full lifecycle events, container states, restart counts, and the last reason/exit code from the previous terminated container. Those events often reveal the root cause, such as image pull failures, failed readiness/liveness probes, or OOMKilled. It also shows the current backoff state and timestamps, making it the first diagnostic command to run.

Why this answer

`kubectl describe pod pod-name` provides detailed information about the pod's current state, including recent events, container restart counts, and the reason for the CrashLoopBackOff (e.g., exit code 137 from OOMKill or 1 from application error). This is the first step to understand the root cause of the crash loop.

Exam trap

The CKA exam often tests the misconception that `kubectl exec` can be used to debug a crashing pod, but in CrashLoopBackOff the container is not running, so exec fails; candidates must remember to use `kubectl logs --previous` to access logs from the terminated instance.

Practice this question →

52

MCQmedium

You want to check the logs of a container that previously crashed. Which command should you use?

A.kubectl logs --previous <pod-name>

B.kubectl logs <pod-name>

C.kubectl exec <pod-name> -- cat /var/log/app.log

D.kubectl describe pod <pod-name>

AnswerA

The `--previous` flag instructs kubectl to retrieve the logs of the last terminated container instance within the pod. When a container has crashed and restarted, the current container's logs are empty or show only new output, while the terminated container's logs remain accessible via this flag. This is the correct way to diagnose why the previous container failed, as it directly fetches the stdout/stderr stream from that dead instance.

Why this answer

The `kubectl logs --previous` command retrieves logs from the previous instance of a container in a Pod that has crashed or been restarted. This is essential for debugging transient failures because the current container's logs may not contain the crash information. The `--previous` flag specifically accesses the terminated container's log stream, which is stored by the kubelet until the pod is deleted.

Exam trap

The trap here is that candidates often choose `kubectl logs <pod-name>` (option B) thinking it shows all logs, but they forget that a crashed container's logs are only accessible with the `--previous` flag.

How to eliminate wrong answers

Option B is wrong because `kubectl logs <pod-name>` only shows logs from the currently running container, not from a previously crashed instance. Option C is wrong because `kubectl exec` runs a command in a running container, which is impossible if the container has crashed and is not running. Option D is wrong because `kubectl describe pod` shows pod metadata, events, and status, but does not retrieve container logs, especially not from a previous crash.

Practice this question →

53

Multi-Selecthard

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Select 3 answers

A.Check the kubelet status using 'systemctl status kubelet' on the node

B.View kubelet logs using 'journalctl -u kubelet'

C.Check node conditions with 'kubectl describe node <node-name>'

D.Restart the kubelet using 'systemctl restart kubelet'

E.Delete the node object and rejoin it to the cluster

AnswersA, B, C

Checking whether the kubelet is actually running on the node is the first diagnostic action: systemctl status kubelet reports whether the unit is active, the main PID, memory/CPU usage, and a short tail of recent log lines. If the service is inactive or failed, the exit status and timestamp help determine whether the node problem is a service crash, a stopped unit, or a configuration failure. This is a quick, non-destructive check that establishes the starting point before digging into logs.

Why this answer

Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step.

Option E (deleting and rejoining) is a recovery step.

Practice this question →

54

Multi-Selecthard

A ClusterIP Service is not reachable from within the cluster. You verify that the Service has endpoints. Which of the following could be the cause? (Select two.)

Select 2 answers

A.kube-proxy is not running on the node.

B.The container is listening on a different port than the Service targetPort.

C.The pod's readiness probe is failing.

D.The Service name is too long.

AnswersA, B

Why this answer

Kube-proxy is responsible for implementing ClusterIP Service networking rules (iptables/IPVS) on each node; if it is not running, traffic to the Service's ClusterIP will not be forwarded to endpoints. Option B is correct because if the container is listening on a different port than the Service's targetPort, the connection will fail at the pod level. Option C is incorrect because a failing readiness probe would cause the pod to be removed from the Service's endpoints, contradicting the premise that the Service has endpoints.

Option D is incorrect because service name length is not a factor for reachability (max is 63 characters).

Exam trap

Candidates may think a failing readiness probe can cause unreachability even when endpoints exist, but that is not possible because the pod would be removed from endpoints upon probe failure.

Why the other options are wrong

D

Service name length does not affect connectivity.

Practice this question →

55

MCQmedium

You run 'kubectl get events --sort-by=.lastTimestamp' and see the following events for a pod: 'Warning FailedScheduling 0/3 nodes are available: 3 Insufficient cpu'. What is the most likely solution?

A.Reduce the CPU request for the pod or remove other workloads to free CPU

B.Change the scheduler to a different one

C.Increase the CPU limit for the pod

D.Add more nodes to the cluster

AnswerA

The Kubernetes scheduler uses a pod's CPU request to determine node feasibility during the filtering phase. Lowering this request value reduces the resource footprint required for scheduling, allowing the pod to fit onto existing nodes with limited allocatable CPU. Alternatively, evicting or deleting non-essential workloads frees up allocatable capacity on those nodes, resolving the scheduling bottleneck without requiring infrastructure changes.

Why this answer

The event '0/3 nodes are available: 3 Insufficient cpu' indicates that all three nodes in the cluster lack sufficient allocatable CPU to satisfy the pod's CPU request. The most direct solution is to either reduce the pod's CPU request (so it fits on an existing node) or remove other workloads to free up CPU capacity. This aligns with Kubernetes resource scheduling, where the scheduler only considers requests (not limits) when placing pods.

Exam trap

The trap here is that candidates often confuse CPU requests with CPU limits and mistakenly think increasing limits will help the pod get scheduled, but the scheduler only evaluates requests, not limits.

How to eliminate wrong answers

Option B is wrong because changing the scheduler does not address the root cause of insufficient CPU resources; the default scheduler already evaluates node capacity, and a different scheduler would face the same resource shortage. Option C is wrong because increasing the CPU limit does not affect scheduling decisions—limits are for resource enforcement at runtime, not for admission; the scheduler only considers CPU requests. Option D is wrong because adding more nodes is an over-engineered solution; the cluster already has three nodes, and the issue is that they are fully utilized, so reducing demand is more efficient and cost-effective than scaling out.

Practice this question →

56

MCQhard

A pod has status 'Init:Error'. What does this indicate?

A.The main container has crashed

B.An init container failed

C.The pod is being initialized

D.There is a network error during initialization

AnswerB

When an init container exits with a non-zero exit code, the pod status transitions to Init:Error (or Init:CrashLoopBackOff if it keeps failing). Kubernetes treats init containers as mandatory prerequisites: they run sequentially to completion before any regular containers start. The failing init container can be identified with kubectl describe pod, which shows the last exit code and reason, and its logs are available via kubectl logs <pod> -c <init-container-name>. This directly matches the init error status shown in the question stem.

Why this answer

The 'Init:Error' status indicates that a pod's init container has failed to complete successfully. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, the pod enters this error state. This is distinct from a main container crash, which would show as 'CrashLoopBackOff' or 'Error' after the pod has started.

Exam trap

The trap here is that candidates confuse 'Init:Error' with a pod initialization phase or a main container error, when in fact it specifically indicates a failed init container that prevents the pod from reaching the running state.

Why the other options are wrong

A

Main container status would be CrashLoopBackOff or Error.

C

That would be Init:0/1 etc.

D

Network error would show as Init:NetworkNotReady or similar.

Practice this question →

57

MCQmedium

You attempt to schedule a pod but it remains 'Pending'. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match node selector.' What is the MOST likely cause?

A.A PersistentVolumeClaim is not bound

B.All nodes have insufficient memory or CPU

C.The nodes have taints that the pod does not tolerate

D.The pod's nodeSelector does not match any node labels

AnswerD

A nodeSelector in the pod spec requires the selected node to have all the specified label key-value pairs. If no node in the cluster carries those labels, the scheduler marks those nodes as failing the `node selector` predicate and the pod remains Pending with an event like `0/N nodes are available: N node(s) didn't match node selector`. This is the canonical cause of a pending pod when there are no volume, resource, or taint issues, and it is confirmed by checking node labels with `kubectl get nodes --show-labels`.

Why this answer

The error '0/3 nodes are available: 3 node(s) didn't match node selector' directly indicates that the pod has a nodeSelector that does not match any node's labels. Option A (PVC not bound) would show a different error like 'persistentvolumeclaim not found'. Option B (insufficient resources) would show 'Insufficient memory/cpu'.

Option C (taints not tolerated) would show 'node(s) had taints'. Therefore, the most likely cause is that the pod's nodeSelector does not match any node labels, which is Option D.

Practice this question →

58

MCQhard

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?

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

B.The node's network plugin is misconfigured

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

D.The kube-dns service is not running or is misconfigured

AnswerD

The `kube-dns` (or `CoreDNS`) service is the designated DNS resolver for pods within a Kubernetes cluster, with pods' `/etc/resolv.conf` typically pointing to its ClusterIP. If the underlying `kube-dns` or `CoreDNS` pods are not running, are crashing, or are misconfigured (e.g., resource starvation, incorrect upstream servers), the DNS service IP will be unresponsive to queries. This directly causes DNS resolution attempts from client pods to time out, as queries are sent to the correct IP but receive no response from the non-functional or overloaded DNS server.

Why this answer

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.

Exam trap

The trap here is that candidates confuse DNS resolution failures with network plugin issues, but the specific 'connection timed out' error points to the DNS service itself being unreachable, not to a general network misconfiguration.

How to eliminate wrong answers

Option A is wrong because if the pod's /etc/resolv.conf had incorrect nameservers, the error would typically be 'server can't find ...' or 'no answer', not a connection timeout; a timeout suggests the DNS server IP is unreachable, not that it's misconfigured. Option B is wrong because a misconfigured node network plugin would cause broader connectivity issues (e.g., pod-to-pod or pod-to-service failures) rather than a DNS-specific timeout; DNS relies on the network plugin only for basic IP reachability, not for DNS resolution logic. Option C is wrong because setting the pod's DNS policy to 'None' would result in an empty /etc/resolv.conf, leading to an immediate 'no servers could be reached' or 'failure: no nameservers' error, not a timeout after attempting to reach servers.

Practice this question →

59

MCQmedium

A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn't tolerate.' What is the MOST likely solution?

A.Remove the taint from the control-plane nodes

B.Delete the pod and recreate it

C.Increase the pod's resource requests

D.Add tolerations to the pod for the control-plane taint

AnswerD

Adding tolerations to the pod's manifest is the correct solution because taints repel pods unless those pods have a matching toleration. Control-plane nodes are typically tainted to prevent general workloads from running on them. By adding a toleration that matches the control-plane node's taint (e.g., `key: node-role.kubernetes.io/control-plane`, `operator: Exists`, `effect: NoSchedule`), the pod explicitly signals to the scheduler that it is permitted to be scheduled on such nodes, resolving the `Pending` state.

Why this answer

The pod is stuck in 'Pending' because it cannot be scheduled. The event shows that 3 control-plane nodes have the 'node-role.kubernetes.io/control-plane' taint, which by default prevents non-tolerant pods from scheduling on them. Adding the corresponding toleration to the pod's spec allows it to be scheduled on those nodes, resolving the pending state.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node affinity or resource constraints, leading them to choose resource-related fixes or node modifications instead of adding the correct toleration to the pod spec.

How to eliminate wrong answers

Option A is wrong because removing the taint from control-plane nodes would allow all pods to schedule on them, which is not the intended solution for a specific pod and could compromise cluster security or workload isolation. Option B is wrong because deleting and recreating the pod without changing its configuration will result in the same scheduling failure, as the taint and lack of toleration remain unchanged. Option C is wrong because increasing resource requests does not address the taint-based scheduling restriction; resource constraints would produce a different event message (e.g., 'Insufficient cpu/memory').

Practice this question →

60

MCQhard

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

A.The pod's memory request is higher than any node's allocatable memory

B.The cluster is using a resource quota that is exhausted

C.The pod's memory limit is set too low

D.The nodes have taints that the pod does not tolerate

AnswerA

The pod's memory request is higher than any node's allocatable memory. The Kubernetes scheduler performs a feasibility check for each node, comparing the pod's sum of memory requests against the node's allocatable memory (which excludes reserved system resources). If no node can satisfy this request, the scheduler cannot bind the pod, leaving it in Pending state. The `kubectl describe` output would include events such as "0/3 nodes are available: insufficient memory" or "Fit failed" for all nodes, directly indicating that the request exceeds every node's capacity.

Why this answer

The '0/3 nodes are available: 3 Insufficient memory' event indicates that the scheduler could not place the pod because each node lacks enough allocatable memory to satisfy the pod's memory request. Even if the cluster has plenty of total memory, the scheduler evaluates each node individually against the pod's resource requests, not the cluster-wide sum. Therefore, if the pod's memory request exceeds the allocatable memory on every node, the pod will remain Pending.

Exam trap

The trap here is that candidates confuse cluster-wide total memory with per-node allocatable memory, assuming that if the sum of free memory across all nodes is sufficient, the pod should schedule — but the scheduler only considers individual node capacity, not aggregated cluster memory.

How to eliminate wrong answers

Option B is wrong because a resource quota limits total resource consumption within a namespace, but the scheduler error specifically says 'Insufficient memory' on nodes, not a quota violation (which would show a different event like 'exceeded quota'). Option C is wrong because a memory limit that is set too low does not prevent scheduling; limits are enforced at runtime by the kubelet, not by the scheduler, and a low limit would cause OOM kills, not a Pending state. Option D is wrong because taints and tolerations produce a different scheduler event: '0/3 nodes are available: 3 node(s) had taint {key: value} that the pod didn't tolerate', not an 'Insufficient memory' message.

Practice this question →

61

Multi-Selectmedium

You want to check resource usage of pods and nodes. Which TWO commands should you use?

Select 2 answers

A.kubectl top pod --nodes

B.kubectl top pods

C.kubectl top nodes

D.kubectl resource usage

E.kubectl top node --containers

AnswersB, C

Shows CPU/memory usage of pods.

Why this answer

To check resource usage, use `kubectl top pods` (B) for pods and `kubectl top nodes` (C) for nodes. The incorrect options use invalid flags: `kubectl top pod --nodes` and `kubectl top node --containers` are not supported, making them syntactically invalid.

Practice this question →

62

Multi-Selectmedium

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

Select 2 answers

A.kubectl get events

B.kubectl get events --sort-by=.metadata.creationTimestamp

C.kubectl get events -w

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

E.kubectl get events --all-namespaces

AnswersA, B

kubectl get events is correct because the default output of the events command is already sorted by lastTimestamp, the moment each event was last observed, from most to least recent. This gives an effective chronological view without needing extra flags, satisfying the requirement to view events sorted by a time field.

Why this answer

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.

Practice this question →

63

MCQeasy

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

A.kubectl logs web-pod --previous

B.kubectl exec web-pod -- cat /var/log/app.log

C.kubectl describe pod web-pod

D.kubectl logs web-pod

AnswerA

kubectl logs web-pod --previous fetches the log stream from the last terminated container instance, which is exactly where the application's crash output is preserved. The --previous flag reads the container's previous log file that survives restarts, allowing you to see the exception, error, or stack trace that triggered the CrashLoopBackOff rather than an empty or fresh current log.

Why this answer

The correct command is kubectl logs web-pod --previous (Option A). This retrieves the logs from the previous instance of the container, which is essential when a pod is in CrashLoopBackOff because the container has restarted and the current logs may be empty or not show the error from the previous run. Option B uses kubectl exec to read a log file, but it does not access previous logs and requires the container to be running.

Option C shows pod details but not logs. Option D shows current logs only, which may not capture the crash reason.

Practice this question →

64

Multi-Selecteasy

Which TWO of the following are valid commands to check the status of control plane components?

Select 2 answers

A.systemctl status kube-apiserver

B.kubectl get nodes

C.kubectl get pods -n kube-system

D.kubectl get events --all-namespaces

E.kubectl top nodes

AnswersA, C

On clusters where control plane components are managed by systemd (e.g., packaged Kubernetes distributions or those set up with kubeadm before static pods became the default), `systemctl status kube-apiserver` queries the service manager for the exact process state, reporting whether the service is active, running, or failed. It also surfaces recent journal logs, making it a direct and authoritative check of the kube-apiserver service. However, this command is only valid when the component actually runs as a systemd unit; on clusters using static pods, it would return an error, so it is environment-specific but nonetheless a correct approach for systemd-based clusters.

Why this answer

`systemctl status kube-apiserver` directly queries the systemd service manager for the status of the kube-apiserver process, which is a core control plane component. Option C is correct because `kubectl get pods -n kube-system` lists all pods in the kube-system namespace, which includes control plane components like etcd, kube-scheduler, and kube-controller-manager when they run as static pods or Deployments. Both commands provide direct visibility into the health of control plane components.

Exam trap

The CKA exam often tests the distinction between commands that check node-level health versus component-level health, trapping candidates who confuse `kubectl get nodes` (node status) with direct control plane component checks.

Practice this question →

65

MCQhard

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?

A.Increase the memory limit of the pod or add more worker nodes

B.Remove the taint from the control-plane node

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

D.Set nodeSelector to schedule on control-plane nodes

AnswerA

Why this answer

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.

Exam trap

The trap here is that candidates focus on the taint error and assume the control-plane node is the bottleneck, ignoring the more critical 'Insufficient memory' message that points to a resource shortage on the worker nodes.

How to eliminate wrong answers

Option B is wrong because removing the taint from the control-plane node does not solve the memory shortage on the three worker nodes; it only makes the control-plane node schedulable, but that node also has a taint that the pod does not tolerate, so it would still be unavailable unless a toleration is added. Option C is wrong because adding a toleration for the control-plane taint would allow the pod to schedule on the control-plane node, but that node also has insufficient memory (as implied by '0/4 nodes are available'), so it would not fix the pending state. Option D is wrong because setting nodeSelector to control-plane nodes would force scheduling on a node that is tainted and likely has insufficient memory, and the pod does not tolerate the taint, so it would remain pending.

Practice this question →

66

Drag & Dropmedium

Drag and drop the steps to back up and restore etcd data for a Kubernetes cluster into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct order ensures that you capture a consistent snapshot, verify its integrity, stop etcd to avoid conflicts, restore the data, start etcd, and then confirm the cluster is healthy. Skipping steps or doing them out of order can lead to data loss or cluster instability.

Practice this question →

67

MCQeasy

Which command can be used to view resource usage of nodes in a cluster?

A.kubectl describe nodes

B.kubectl top pods

C.kubectl get pods --show-resources

D.kubectl top nodes

AnswerD

kubectl top nodes queries the Metrics API, which is backed by metrics-server, to report each node's current CPU and memory usage as a percentage of allocatable capacity. This is the standard command for quickly assessing real-time node utilization in a cluster. It requires the metrics-server (or a compatible metrics API) to be installed and producing node metrics.

Why this answer

'kubectl top nodes', correctly displays CPU and memory usage for all nodes in the cluster, provided the metrics server is deployed. Option A, 'kubectl describe nodes', shows detailed node information but not resource usage metrics. Option B, 'kubectl top pods', shows pod resource usage, not nodes.

Option C, 'kubectl get pods --show-resources', is not a valid command in kubectl.

Practice this question →

68

MCQeasy

You need to check the logs of a kubelet on a node. Which command should you run on the node?

A.journalctl -u docker

B.dmesg

C.tail -f /var/log/apache2/access.log

D.journalctl -u kubelet

AnswerD

`journalctl -u kubelet` is the correct approach because kubelet is registered as a systemd service under the unit name `kubelet.service` on essentially all managed Kubernetes distributions. This command displays all journal entries associated with that unit, preserving timestamps, priorities, and source metadata. It is the standard first step for diagnosing kubelet failures, and can be combined with flags like `-f`, `-n 100`, or `--since` for targeted live troubleshooting.

Why this answer

The correct command to view kubelet logs on a systemd-based node is 'journalctl -u kubelet'. Option D is correct. Option A ('journalctl -u docker') shows Docker daemon logs, not kubelet.

Option B ('dmesg') displays kernel ring buffer messages. Option C ('tail -f /var/log/apache2/access.log') shows Apache web server logs.

Exam trap

Candidates often confuse the kubelet service unit name with Docker. Remember that kubelet logs are accessed with 'journalctl -u kubelet', not 'journalctl -u docker'.

Practice this question →

69

MCQhard

You want to check the current resource usage (CPU and memory) of pods in the 'default' namespace. Which kubectl command should you use?

A.kubectl get pods -o wide

B.kubectl top pods

C.kubectl logs pods

D.kubectl describe pods

AnswerB

`kubectl top pods` is the correct command to view current resource usage. It queries the Metrics API, typically served by metrics-server, which aggregates per-container CPU and memory data from kubelet/cAdvisor. The output shows values like CPU in cores or millicores and memory in bytes or mebibytes, giving an accurate snapshot of live consumption. However, it depends on metrics-server being deployed in the cluster.

Why this answer

`kubectl top pods` retrieves real-time CPU and memory metrics for pods from the metrics server, which is the standard way to check current resource usage in a Kubernetes cluster. This command relies on the Metrics API and requires the metrics server to be deployed.

Exam trap

The trap here is that candidates often confuse `kubectl get pods -o wide` or `kubectl describe pods` with resource monitoring, but neither provides live CPU/memory metrics, which only `kubectl top` (with the metrics server) can deliver.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods -o wide` only shows pod IPs and node assignments, not CPU or memory usage. Option C is wrong because `kubectl logs pods` fetches container logs, not resource metrics. Option D is wrong because `kubectl describe pods` provides detailed pod configuration and status but does not include live CPU or memory utilization data.

Practice this question →

70

MCQhard

A pod remains in Pending state. You run 'kubectl describe pod mypod' and see the following event: '0/3 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules.' What is the best action to schedule the pod?

A.Increase the number of replicas

B.Modify the pod's anti-affinity rules or remove the conflicting pod on the third node

C.Remove the node.kubernetes.io/control-plane taint from the control plane nodes

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

AnswerB

The `podAntiAffinity` rule explicitly prevents a pod from being scheduled on a node that already hosts another pod matching specific labels within a defined topology domain. If the `kubectl describe po` output indicates an anti-affinity conflict on the third node, either relaxing the `podAntiAffinity` rule in the pod's specification or removing the existing, conflicting pod from that node would allow the pending pod to be scheduled. This directly resolves the constraint preventing the pod from finding a suitable node.

Why this answer

The pod is unschedulable because one node has a pod anti-affinity rule conflict, and the other two nodes have a control-plane taint. The best action is to modify the pod's anti-affinity rules (e.g., relax the requiredDuringSchedulingIgnoredDuringExecution constraint) or remove the conflicting pod on the third node, as this directly resolves the scheduling conflict without affecting the control-plane taint or replicas.

Exam trap

The trap here is that candidates often focus on the taint issue (options C or D) because it appears first in the event message, but they overlook the anti-affinity conflict on the third node, which is the actual blocking constraint for that node.

How to eliminate wrong answers

Option A is wrong because increasing the number of replicas does not resolve the underlying scheduling constraints—it only creates more pods that will also remain Pending. Option C is wrong because removing the control-plane taint from control plane nodes is not recommended; those nodes are typically reserved for system components and removing the taint could lead to resource contention or security issues. Option D is wrong because adding a toleration for the control-plane taint would only address the taint issue on two nodes, but the pod would still fail to schedule on the third node due to the anti-affinity conflict.

Practice this question →

71

MCQmedium

A pod is in CrashLoopBackOff. You check the logs with 'kubectl logs my-pod --previous' and see 'Error: cannot connect to database at 10.0.0.1:3306'. The database service is named 'mysql' and runs on port 3306. What is the most likely cause?

A.The application is configured with an incorrect database hostname

B.The pod does not have network access to the mysql service

C.The mysql service is not exposed on port 3306

D.The database pod is not running

AnswerA

The application's logs clearly show an attempt to establish a database connection to the hardcoded IP address "10.0.0.1". In a Kubernetes environment, applications should typically connect to services using their DNS-resolvable service names (e.g., 'mysql' or 'mysql.default.svc.cluster.local') rather than static cluster IPs, which are ephemeral and subject to change. This misconfiguration prevents the application from correctly resolving and connecting to the intended 'mysql' service, leading to the CrashLoopBackOff.

Why this answer

The error message 'cannot connect to database at 10.0.0.1:3306' indicates the application is trying to connect to a hardcoded IP address (10.0.0.1) instead of the Kubernetes service name 'mysql'. In Kubernetes, services are accessed via DNS names (e.g., 'mysql.default.svc.cluster.local'), not static IPs, which are ephemeral and can change. This misconfiguration causes the connection failure, leading to the CrashLoopBackOff as the app repeatedly fails to start.

Exam trap

The trap here is that candidates assume the error is due to network connectivity or the database being down, but the specific mention of a hardcoded IP (10.0.0.1) in the logs points directly to an application configuration issue with the hostname, not a cluster-level network or service problem.

How to eliminate wrong answers

Option B is wrong because if the pod lacked network access to the mysql service, the error would typically be a timeout or 'no route to host', not a specific connection refusal to 10.0.0.1:3306; the pod can reach the IP but the database isn't listening there. Option C is wrong because the mysql service is explicitly stated to run on port 3306, and the error shows the app is attempting port 3306, so the port exposure is not the issue. Option D is wrong because if the database pod were not running, the service would have no endpoints, and the connection attempt would result in a 'connection refused' or timeout, but the error specifically mentions a hardcoded IP (10.0.0.1) rather than the service DNS name, indicating a configuration problem, not a pod status issue.

Practice this question →

72

MCQhard

You are troubleshooting a DNS issue in the cluster. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command returns 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. What is the MOST likely cause?

A.The kube-dns service does not exist

B.The pod's /etc/resolv.conf points to an external DNS server instead of the cluster DNS

C.The CoreDNS pod(s) are not running or are misconfigured

D.The pod's network policy blocks DNS traffic

AnswerC

If CoreDNS is down, DNS resolution fails with NXDOMAIN because there is no server to answer.

Why this answer

NXDOMAIN indicates that the DNS server does not have a record for that name. The most common cause is that the CoreDNS pod(s) are not running or are misconfigured. Option A would cause a timeout not NXDOMAIN.

Option B would cause a different error (connection refused). Option D might cause partial resolution but not NXDOMAIN for the entire service name.

Practice this question →

73

MCQeasy

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

A.kubectl top pods --all-namespaces

B.kubectl describe nodes

C.kubectl get pods -o wide

D.kubectl top nodes

AnswerA

kubectl top pods --all-namespaces is the correct command because it retrieves current CPU and memory utilization for every pod running in every namespace. It sources these figures from the metrics API (backed by metrics-server) and displays them per pod along with the pod's namespace and node. Because the question asks for resource usage of all pods cluster-wide, this command is the only one that directly provides that data without omitting any namespace.

Why this answer

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.

Exam trap

CNCF often tests the distinction between `kubectl top pods` and `kubectl top nodes`, where candidates mistakenly choose `kubectl top nodes` thinking it covers all pods, but it only shows node-level aggregates, not per-pod usage.

How to eliminate wrong answers

Option B is wrong because `kubectl describe nodes` shows node-level resource capacity, requests, and limits, but does not display actual real-time resource usage of individual pods. Option C is wrong because `kubectl get pods -o wide` only lists pod metadata and IP addresses, not resource usage metrics. Option D is wrong because `kubectl top nodes` shows aggregate node-level CPU and memory usage, not per-pod resource usage.

Practice this question →

74

MCQmedium

You are troubleshooting DNS resolution from within a pod. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command fails with 'connection timed out; no servers could be reached'. However, 'kubectl get svc -n kube-system' shows the kube-dns service with a ClusterIP. What is the MOST likely cause?

A.The CoreDNS pods are not running or are crashing

B.The pod's /etc/resolv.conf has incorrect search domains

C.A network policy is blocking traffic to the kube-dns service

D.The DNS name does not exist

AnswerA

This is the correct answer because if the CoreDNS pods are not running or are crashing, the Kubernetes `kube-dns` service will have no healthy endpoints. The `kube-proxy` component, responsible for managing service IPs, will be unable to forward DNS queries from pods to any functional CoreDNS instance. Consequently, any DNS lookup attempt from a pod will result in a connection timeout as the query never reaches an active DNS server to be processed.

Why this answer

The error 'connection timed out; no servers could be reached' from nslookup indicates that the pod cannot reach any DNS server at all. Since the kube-dns service exists (as shown by kubectl), the most likely cause is that the backend CoreDNS pods are not running or are crashing, so there are no endpoints to forward traffic to. Without running CoreDNS pods, the service's ClusterIP has no backing pods, causing all DNS queries to time out.

Exam trap

The trap here is that candidates see the kube-dns service exists and assume DNS is working, but they forget that a service without healthy backend pods (CoreDNS) cannot serve requests, leading to timeouts rather than immediate failures.

How to eliminate wrong answers

Option B is wrong because incorrect search domains in /etc/resolv.conf would cause name resolution failures for short names (e.g., 'kubernetes'), but the fully qualified domain name 'kubernetes.default.svc.cluster.local' would still resolve if the DNS server were reachable; the error here is a connection timeout, not a lookup failure. Option C is wrong because a network policy blocking traffic to the kube-dns service would typically result in a connection refused or timeout, but the question states the service exists and the error is a timeout; however, the most likely cause is the CoreDNS pods not running, as network policies are less common in default clusters and would not prevent the service from having endpoints. Option D is wrong because the DNS name 'kubernetes.default.svc.cluster.local' is a standard Kubernetes service name that exists by default; if it did not exist, nslookup would return 'NXDOMAIN' (non-existent domain), not a connection timeout.

Practice this question →

75

MCQhard

A pod is not able to communicate with another pod in the same namespace. Both pods are running and have IP addresses. Which command can you use to test connectivity from the first pod to the second pod's IP?

A.kubectl exec first-pod -- ping <second-pod-ip>

B.kubectl logs first-pod

C.kubectl top pod first-pod

D.kubectl exec second-pod -- ping <first-pod-ip>

AnswerA

kubectl exec first-pod -- ping <second-pod-ip> is the correct diagnostic because it enters the network namespace of the first pod and sends ICMP echo requests directly to the second pod's IP address. This actively tests layer 3 connectivity along the exact path the failing application would use, rather than relying on any proxy, load balancer, or DNS resolution. A successful reply confirms the network route and firewall rules permit traffic, while a failure localizes the problem to the pod-to-pod networking layer.

Why this answer

`kubectl exec first-pod -- ping <second-pod-ip>` runs the `ping` command inside the first pod, which uses ICMP to test IP-level connectivity to the second pod's IP address. This directly verifies whether the network path between the two pods is functional, including any CNI plugin, overlay network, or network policy rules.

Exam trap

The trap here is that candidates might choose Option D, thinking any ping between pods is equivalent, but the question specifically asks to test connectivity from the first pod to the second pod's IP, not the reverse direction.

How to eliminate wrong answers

Option B is wrong because `kubectl logs first-pod` only retrieves the container logs from the first pod, which does not test network connectivity to another pod. Option C is wrong because `kubectl top pod first-pod` shows resource usage (CPU/memory) of the first pod, not network connectivity. Option D is wrong because it runs `ping` from the second pod to the first pod's IP, which tests the reverse direction and does not diagnose connectivity from the first pod to the second pod as the question requires.

Practice this question →

Page 1 of 2 · 86 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Troubleshooting questions.

Start 20-question session