CCNA Cka Troubleshooting Questions

75 of 290 questions · Page 1/4 · Cka Troubleshooting topic · Answers revealed

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

Option C is correct. 'kubectl logs --previous' retrieves logs from the previous instance of a container. Option A shows current logs. Option B shows only the container name.

Option D is for describing.

2
Multi-Selecthard

Which THREE of the following are valid methods to troubleshoot a CrashLoopBackOff pod?

Select 3 answers
A.Run 'kubectl exec -it pod -- bash' and inspect the container
B.Run 'kubectl describe pod' to check events
C.Run 'kubectl delete pod' and recreate it
D.Run 'kubectl logs pod --previous' to see logs from the previous crash
E.Run 'kubectl scale deployment --replicas=0'
AnswersA, B, D

If the container is running temporarily, you can exec in and check for issues.

Why this answer

Common troubleshooting steps include checking events, viewing logs, and examining the pod's YAML for configuration issues.

3
MCQhard

A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?

A.The CoreDNS deployment has 0 ready replicas.
B.The pod's dnsPolicy is set to Default instead of ClusterFirst.
C.The node's network plugin is misconfigured, blocking UDP port 53.
D.The pod's /etc/resolv.conf contains incorrect nameserver entries.
AnswerA

CoreDNS is the cluster DNS provider; if down, in-cluster DNS fails.

Why this answer

When dnsPolicy is ClusterFirst, the pod's DNS queries are forwarded to the cluster's DNS service (CoreDNS by default). If the CoreDNS deployment has 0 ready replicas, the DNS service has no backend endpoints to handle queries, causing all DNS resolutions to fail. This is the most direct and common cause of complete DNS failure in a cluster.

Exam trap

The trap here is that candidates may overthink network-level issues (like UDP port blocking) or misread the dnsPolicy, when the simplest and most common cause is that the DNS service itself (CoreDNS) is not running.

How to eliminate wrong answers

Option B is wrong because the pod's dnsPolicy is already set to ClusterFirst (as stated in the question), so suggesting it is set to Default is factually incorrect and would not explain the failure. Option C is wrong because while a misconfigured network plugin blocking UDP port 53 could cause DNS issues, it is less likely than CoreDNS being down, and the question asks for the 'most likely' cause; also, CoreDNS itself listens on port 53, so if it has 0 replicas, the port is irrelevant. Option D is wrong because with dnsPolicy: ClusterFirst, the pod's /etc/resolv.conf is automatically generated by kubelet to point to the cluster DNS service IP (e.g., 10.96.0.10), and incorrect entries would only occur if the policy were Default or if the kubelet configuration is broken, which is less common than CoreDNS being unavailable.

4
MCQeasy

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

A.kubectl get events --all-namespaces
B.systemctl status kubelet
C.journalctl -u kubelet
D.kubectl logs kubelet -n kube-system
AnswerC

This shows kubelet logs.

Why this answer

journalctl -u kubelet shows kubelet logs from the systemd journal.

5
MCQmedium

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

A.Disk pressure on the node
B.The node is out of memory
C.Cgroup driver mismatch between kubelet and container runtime
D.The kubelet service is not running
AnswerC

The error is characteristic of a cgroup driver mismatch. The kubelet and container runtime must use the same driver.

Why this answer

The error indicates that the kubelet cannot read cgroup statistics, often due to a misconfiguration of the cgroup driver. In Kubernetes v1.29, the kubelet and container runtime must use the same cgroup driver (cgroupfs or systemd). A mismatch causes the kubelet to fail.

6
Multi-Selecthard

You suspect a DNS issue within the cluster. Which TWO commands can you run from within a pod to test DNS resolution?

Select 2 answers
A.ping kubernetes.default.svc.cluster.local
B.kubectl exec -it pod-name -- /bin/sh
C.dig kubernetes.default.svc.cluster.local
D.curl http://kubernetes.default.svc.cluster.local
E.nslookup kubernetes.default.svc.cluster.local
AnswersC, E

dig is a DNS lookup tool.

Why this answer

nslookup (A) and dig (C) are standard DNS troubleshooting tools. 'kubectl exec' itself is a command to enter the pod, not a DNS tool. 'curl' (D) tests HTTP connectivity, not DNS directly. 'ping' (E) tests network connectivity but not DNS resolution directly.

7
MCQmedium

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

A.ping my-svc
B.nslookup my-svc
C.curl http://my-svc
D.nslookup my-svc.app.svc.cluster.local
AnswerD

This fully qualified name should resolve via cluster DNS.

Why this answer

Option C uses nslookup with the service name and namespace in the format required by Kubernetes DNS (service.namespace). Option A is incorrect format. Option B uses curl, which tests HTTP, not DNS.

Option D uses ping, which may be blocked.

8
Drag & Dropmedium

Drag and drop the steps to set up a PersistentVolumeClaim for a pod into the correct order.

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

Steps
Order

Why this order

First ensure PV exists, then create PVC, apply, define pod with volume mount, and verify.

9
MCQmedium

You need to test DNS resolution from within a pod. Which command should you run?

A.kubectl describe svc <service-name>
B.kubectl logs <pod> | grep dns
C.kubectl exec <pod> -- nslookup <service-name>
D.kubectl run nslookup --image=busybox -- nslookup <service-name>
AnswerC

Correct. This runs nslookup inside the pod.

Why this answer

nslookup or dig can be used to query DNS. They must be available in the container image.

10
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

Pending indicates the pod cannot be scheduled. Common causes include resource constraints and taint/toleration mismatches.

11
MCQhard

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

A.The node is being drained and the pod is being terminated
B.The container's startup command is invalid
C.The container is exceeding its memory limit and is OOMKilled
D.The liveness probe is failing and Kubernetes is restarting the container
AnswerC

Exit code 137 is SIGKILL, often due to OOM.

Why this answer

Exit code 137 (SIGKILL) typically indicates the container was killed by the OOM killer due to exceeding memory limits. Option B is correct. Option A (liveness probe) would exit with code other than 137.

Option C (invalid command) would exit with non-zero code but not specifically 137. Option D (node restart) would result in pod being rescheduled rather than crash loop.

12
Multi-Selecteasy

A pod is in 'ImagePullBackOff' state. Which TWO are valid first troubleshooting steps?

Select 2 answers
A.Check for network policies blocking egress to the registry
B.Check node CPU/memory resources
C.Verify the image exists in the configured registry
D.Check the image name spelling in the pod spec
E.Restart the kubelet on the node
AnswersC, D

Non-existent images cause pull failures.

Why this answer

Checking the image name spelling (A) and verifying the image exists in the registry (C) are direct causes of ImagePullBackOff. Checking node resources (B) is for Pending pods. Restarting kubelet (D) is not a fix.

Checking network policies (E) might help if there is a network issue, but the most common causes are image-related.

13
MCQmedium

A pod is in ImagePullBackOff state. You run 'kubectl describe pod mypod' and see 'Failed to pull image "myapp:latest": rpc error: code = Unknown desc = Error response from daemon: manifest for myapp:latest not found: manifest unknown'. What is the most likely cause?

A.The image tag does not exist in the registry
B.The node has insufficient disk space
C.The image is too large and exceeds the node's disk quota
D.The container registry requires authentication
AnswerA

The error 'manifest unknown' indicates the tag is not found.

Why this answer

The error indicates the image tag 'latest' does not exist in the registry. The tag may have been deleted or never pushed.

14
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

hostNetwork pods often have different DNS resolution; they may not use the cluster DNS.

Why this answer

Option C is correct. When using hostNetwork, the Pod uses the host's network stack and may not be able to resolve ClusterIP services due to different DNS configuration or network policies. Option A is unlikely because endpoints exist.

Option B would affect all pods. Option D is not directly related.

15
MCQmedium

A pod is in 'ImagePullBackOff' state. You run 'kubectl describe pod' and see the event: 'Failed to pull image "nginx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 8.8.8.8:53: no such host'. What is the MOST likely cause?

A.The container runtime is not installed
B.The image tag is incorrect
C.The registry requires authentication
D.DNS resolution is failing on the node
AnswerD

The error 'no such host' clearly indicates a DNS failure.

Why this answer

Correct answer is D. The error indicates a DNS resolution failure for the registry hostname. Option A would show 'unauthorized'.

Option B would show 'manifest not found'. Option C would show 'connection refused' or timeout, but 'no such host' is DNS.

16
MCQeasy

You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?

A.The Service selector does not match the pod labels.
B.The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.
C.The NodePort service type is not enabled in the cluster.
D.The Ingress resource is missing or misconfigured.
AnswerB

External timeout with internal success indicates network path issue.

Why this answer

The pods are running and ready, and the service has an external IP, but external access fails with a connection timeout while internal access to pod IPs works. This indicates the cloud provider's load balancer is not properly routing traffic to the node ports, or a security group/firewall is blocking inbound traffic on the node port range (30000-32767). The load balancer must forward traffic to the node ports, and the nodes must allow that traffic.

Exam trap

The trap here is that candidates assume a LoadBalancer Service automatically works end-to-end, but the CKA exam tests the understanding that cloud provider integration (security groups, load balancer health checks) is a separate layer that can fail even when Kubernetes components are healthy.

How to eliminate wrong answers

Option A is wrong because if the Service selector did not match the pod labels, the endpoints would be empty and curl to pod IPs would fail, but the user reports internal curl to pod IPs works. Option C is wrong because NodePort is not a service type that needs to be 'enabled'; it is automatically assigned when a Service of type LoadBalancer is created, and the cluster always supports NodePort. Option D is wrong because an Ingress resource is not required for a LoadBalancer Service; the Service itself provides external access via the load balancer, and the issue is a connection timeout, not a routing or hostname mismatch.

17
MCQhard

You have a multi-node cluster. One node is healthy but pods scheduled on another node are failing to resolve DNS names. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local' and get 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. Running the same command on a pod on the healthy node works. What is the MOST likely cause?

A.The container runtime on the failing node is misconfigured
B.The kube-dns service is not running in the cluster
C.The CoreDNS pod is not scheduled on that node, and network policy blocks cross-node DNS traffic
D.The node's /etc/resolv.conf is pointing to an external DNS server
AnswerC

CoreDNS pods may not be on all nodes; if network policy restricts traffic, DNS fails.

Why this answer

Correct answer is B. DNS resolution relies on CoreDNS pods. If the CoreDNS pod is not running on that node, or the pod cannot reach it due to network policy, DNS will fail.

Option A would affect both nodes. Option C would affect all pods. Option D is not typical; nodes usually use the same DNS config.

18
Multi-Selecthard

A Deployment's pods are failing with 'CrashLoopBackOff'. The container exits with code 1. Which two approaches will help identify the issue? (Choose two.)

Select 2 answers
A.kubectl logs <pod>
B.kubectl describe pod <pod>
C.kubectl get pods -o wide
D.kubectl edit deployment <deploy>
AnswersA, B

Why this answer

A is correct because `kubectl logs <pod>` retrieves the container's stdout/stderr output, which often contains the error message or stack trace that caused exit code 1. This is the first step in debugging a CrashLoopBackOff, as it reveals what the application printed before terminating.

Exam trap

The trap here is that candidates may think `kubectl get pods -o wide` provides troubleshooting details, but it only adds IP and node info, not logs or events, while `kubectl edit` is a remediation step, not a diagnostic one.

Why the other options are wrong

C

Shows status but no logs or details.

D

Edits, not diagnoses.

19
MCQeasy

You want to see events sorted by timestamp in the 'kube-system' namespace. Which command should you use?

A.kubectl describe events -n kube-system
B.kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'
C.kubectl get events -n kube-system --sort-by='.lastTimestamp'
D.kubectl logs -n kube-system events
AnswerB

Correct sorting field and namespace.

Why this answer

kubectl get events --sort-by='.metadata.creationTimestamp' -n kube-system shows events sorted by creation time.

20
MCQeasy

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. What is the most likely cause?

A.The node is out of disk space
B.The pod exceeded its memory limit
C.The container command is invalid
D.The container image name is misspelled
AnswerD

A misspelled image name causes the pull to fail.

Why this answer

ImagePullBackOff typically occurs when Kubernetes cannot pull the container image from the registry.

21
MCQmedium

You suspect the kube-apiserver is down. Which command should you run on the control-plane node to check its status?

A.systemctl status kube-apiserver
B.kubectl get pods -n kube-system
C.journalctl -u kubelet
D.ps aux | grep kube-controller
AnswerA

Correct. This checks the systemd service status.

Why this answer

kube-apiserver runs as a static pod or systemd service. systemctl is used to check systemd services.

22
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

Pending pods often indicate resource constraints (A), taint/toleration mismatch (B), or PVC not bound (C). Node not registered (D) would prevent scheduling but is less common. Image pull error (E) leads to ImagePullBackOff, not Pending.

23
MCQmedium

You run 'kubectl top nodes' but get 'error: metrics not available yet'. What is the most likely cause?

A.kubectl top requires root access
B.Nodes have insufficient CPU
C.The Metrics Server is not deployed
D.Kubelet is not running on nodes
AnswerC

Metrics Server provides resource metrics; without it, top commands fail.

Why this answer

Metrics server is not deployed or not ready, so resource metrics are unavailable.

24
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

journalctl -u kubelet displays the logs for the kubelet service, which is the primary source for troubleshooting node issues.

Why this answer

Option A is correct. The kubelet logs can be viewed using 'journalctl -u kubelet'. Option B is used for system logs, not kubelet-specific.

Option C checks kube-apiserver logs. Option D checks kube-controller-manager logs.

25
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

Kubelet logs often indicate why the node is NotReady.

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 (restarting containers) is not relevant.

Option E (checking kube-proxy) is for service connectivity, not node readiness.

26
MCQeasy

You see events like 'Failed to pull image' when running 'kubectl get events'. Which command can you use to get more detailed information about a specific pod's events?

A.kubectl get pod <pod-name> -o yaml
B.kubectl top pod <pod-name>
C.kubectl describe pod <pod-name>
D.kubectl logs <pod-name>
AnswerC

'kubectl describe pod' includes a section for Events that shows recent events for that pod, such as failed pulls.

Why this answer

'kubectl describe pod' shows events related to the pod, including pull failures.

27
MCQmedium

A pod is stuck in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {key=value: NoSchedule}, 1 node(s) had taint {node.kubernetes.io/unreachable: }. What does this indicate?

A.The nodes are all in NotReady state
B.The pod does not tolerate the taints on the available nodes
C.The pod requires at least 2 nodes
D.The pod has insufficient resources
AnswerB

Taints cause pods without matching tolerations to remain unscheduled.

Why this answer

The pod cannot tolerate the taints. One node has a custom taint, another is unreachable.

28
MCQmedium

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'active (running)'. What should you check NEXT?

A.Check if the kubelet is registered with the API server using 'kubectl get cs'
B.Check the kubelet logs with 'journalctl -u kubelet' for errors
C.Restart the kubelet service
D.Check if the node has sufficient disk space
AnswerB

Why this answer

Even if kubelet is running, it may have errors. Journalctl shows detailed logs to diagnose why the node is NotReady.

29
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

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

30
MCQeasy

A pod is in CrashLoopBackOff state. Which command shows the last termination reason?

A.kubectl logs <pod>
B.kubectl describe pod <pod>
C.kubectl get pod <pod> -o yaml
D.kubectl top pod <pod>
AnswerB

Why this answer

The `kubectl describe pod <pod>` command displays detailed information about the pod, including the container state transitions and the last termination reason in the `Last State` field under the container status. This is the correct way to see why the container previously exited, which is essential for diagnosing a CrashLoopBackOff.

Exam trap

The trap here is that candidates often reach for `kubectl logs` first, not realizing that in a CrashLoopBackOff the container may have already restarted, so the logs from the last crash are not visible without the `--previous` flag, whereas `kubectl describe pod` directly shows the last termination reason.

Why the other options are wrong

A

Shows current logs, not termination reason.

C

Shows state but not human-readable termination reason.

D

Shows resource usage, not status.

31
MCQeasy

A pod is in CrashLoopBackOff state. Which command should you use to see the logs of the previous instance?

A.kubectl logs <pod-name>
B.kubectl logs -p <pod-name>
C.kubectl describe pod <pod-name>
D.kubectl logs --previous <pod-name>
AnswerB

Why this answer

When a pod is in CrashLoopBackOff state, the current container instance has crashed and Kubernetes is restarting it. The `-p` flag (or `--previous`) in `kubectl logs` retrieves logs from the previous terminated container instance, which contains the crash output. Option B is correct because `kubectl logs -p <pod-name>` is the exact syntax to view logs of the previous instance.

Exam trap

The trap here is that candidates confuse `kubectl logs` with `kubectl describe pod` for viewing crash logs, or they forget the `-p` flag and assume the current logs will show the crash, when in fact the crash output is only in the previous instance's logs.

Why the other options are wrong

A

Shows current container logs, not previous.

C

Describes pod status but does not show logs.

D

Flag is -p, not --previous.

32
Multi-Selecteasy

Which TWO of the following are valid commands to check resource usage of pods?

Select 2 answers
A.kubectl top nodes
B.kubectl describe pods
C.kubectl top pod <pod-name>
D.kubectl get pods --watch
E.kubectl top pods
AnswersC, E

Shows resource usage for a specific pod.

Why this answer

Options A and E are correct. kubectl top pods and kubectl top pod <pod-name> display resource usage for pods. Option B is for details. Option C is for nodes.

Option D is for watching status.

33
Multi-Selectmedium

Which of the following are valid methods to troubleshoot a Node that is 'NotReady'? (Select all that apply)

Select 3 answers
A.Check the kubelet logs on the node via journalctl
B.Verify that the kubelet certificate is valid and not expired
C.Restart the node's container runtime (e.g., containerd)
D.Delete the node object and re-create it
E.Reinstall the entire Kubernetes cluster
AnswersA, B, C

Why this answer

Option A is correct because the kubelet is the primary node agent that communicates with the control plane. When a node is 'NotReady', checking the kubelet logs via `journalctl -u kubelet` can reveal errors such as network connectivity issues, certificate problems, or resource exhaustion. Option B is correct because an expired or invalid kubelet certificate will cause TLS authentication failures with the API server, leading to the node being marked 'NotReady'.

Option C is correct because the container runtime (e.g., containerd) is responsible for managing containers; if it is down or misconfigured, the kubelet cannot start pods, and restarting it can resolve transient failures.

Exam trap

CNCF often tests the misconception that deleting and re-creating a Node object is a valid troubleshooting step, when in reality it only removes the API server's representation and does not fix the underlying cause of the 'NotReady' state.

Why the other options are wrong

D

Deleting the node does not fix the node condition; it only removes it from the cluster.

E

Overkill; a single node issue doesn't require cluster reinstall.

34
MCQhard

A node in your cluster is reporting 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. Which command should you run FIRST to attempt to resolve this?

A.journalctl -u kubelet
B.systemctl status kubelet
C.reboot
D.systemctl start kubelet
AnswerD

The kubelet is inactive/dead, so starting it will bring the node to Ready state.

Why this answer

Option C is correct. Since the kubelet service is inactive/dead, you need to start it using 'systemctl start kubelet'. Option A shows status only.

Option B restarts the node, which is too aggressive. Option D checks logs but does not start the service.

35
MCQmedium

You are unable to resolve a Service DNS name from within a pod. To test DNS resolution, which command should you run inside the pod?

A.kubectl describe svc <service-name>
B.kubectl logs <pod>
C.kubectl attach <pod>
D.kubectl exec <pod> -- nslookup <service-name>
AnswerD

This runs nslookup inside the pod to test DNS resolution.

Why this answer

The correct command is 'kubectl exec <pod> -- nslookup <service-name>'. nslookup or dig are common DNS troubleshooting tools.

36
MCQhard

You have a Deployment with 3 replicas. One pod is in CrashLoopBackOff. The other two are Running. You run 'kubectl get events' and see 'Liveness probe failed: HTTP probe failed with statuscode: 503'. What should you do?

A.Increase the initialDelaySeconds of the liveness probe
B.Scale down the deployment
C.Check the application health endpoint and fix it to return 200
D.Remove the liveness probe
AnswerC

The app's health endpoint returns 503; fix the app to respond correctly.

Why this answer

Liveness probe failure causes container restart. The fix could be adjusting the probe or fixing the app to respond correctly.

37
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
AnswersA, B

Contains container logs from the kubelet.

Why this answer

kubectl logs with --previous flag shows the logs of the terminated container. journalctl -u kubelet can show container logs if the kubelet is configured to send them there, but it's not the standard way; however, the question asks for commands that can view logs of a crashed container. kubectl logs --previous is direct. Also, kubectl logs without --previous may show logs of the current (crashed) container if it restarted, but it's not guaranteed. Actually, the reliable way is --previous.

Many would say kubectl logs and kubectl logs --previous are both valid? But kubectl logs without --previous shows logs of the currently running container (if any). For a crashed container, --previous is needed. Another command is 'crictl logs' but not listed.

The typical CKA answer is kubectl logs --previous and journalctl -u kubelet (since kubelet logs contain container logs). However, the question specifies 'two commands'. Let's choose the two most direct: kubectl logs --previous and docker logs (if using docker).

But docker is not listed. We have options: A) kubectl logs pod-name, B) kubectl logs pod-name --previous, C) journalctl -u kubelet, D) kubectl describe pod, E) systemctl status kubelet. Correct: B and C. journalctl -u kubelet can show container logs because kubelet logs include them.

38
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

Correct answer is A. 'kubectl logs pod-name --previous' retrieves the logs from the previous instance of a container. Option B shows current logs. Option C and D are incorrect flags.

39
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 TWO actions would resolve the issue? (Choose two)

Select 2 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, D

Removing the taint also allows the pod to be scheduled on those nodes.

Why this answer

Increasing memory availability or tolerating the taint would allow the pod to be scheduled.

40
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
AnswerB

Shows events sorted by timestamp by default.

Why this answer

kubectl get events shows events sorted by timestamp by default.

41
MCQhard

You need to check the logs of a container that previously crashed. The pod is currently running, but the previous instance of the container exited with an error. Which command will show you the logs from the crashed container?

A.kubectl logs pod-name --previous
B.kubectl exec pod-name -- cat /var/log/crash.log
C.kubectl attach pod-name
D.kubectl logs pod-name -c container-name
AnswerA

'kubectl logs --previous' retrieves logs from the previous terminated container, exactly what is needed to see the crash output.

Why this answer

The '--previous' flag shows logs from the previous instance of a container in a pod, which is useful for debugging crash loops.

42
Multi-Selectmedium

Which THREE are valid methods to debug DNS resolution inside a pod? (Select 3)

Select 3 answers
A.kubectl exec <pod> -- ping kubernetes.default.svc.cluster.local
B.kubectl exec <pod> -- nslookup kubernetes.default.svc.cluster.local
C.kubectl logs <pod>
D.kubectl exec <pod> -- dig kubernetes.default.svc.cluster.local
E.kubectl exec <pod> -- curl http://kubernetes.default
AnswersB, D, E

nslookup queries DNS.

Why this answer

nslookup, dig, and curl to a service name test DNS. ping uses ICMP, not DNS. kubectl logs does not test resolution.

43
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

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

44
MCQeasy

You run 'kubectl top nodes' and it returns an error: 'error: metrics not available yet'. What does this indicate?

A.The kubelet is not running on the nodes.
B.The cluster is using an older version of Kubernetes.
C.The nodes are under heavy load.
D.The Metrics Server is not installed or not functioning.
AnswerD

Metrics Server must be deployed to collect and expose resource metrics.

Why this answer

The 'top' command relies on the metrics server to provide resource usage data. The error means the metrics server is not deployed or not ready.

45
MCQmedium

A pod is in CrashLoopBackOff. You run 'kubectl logs pod-name' and see nothing. You suspect the app is failing due to a missing environment variable. Which command can you use to verify environment variables inside the container?

A.kubectl exec pod-name -- env
B.kubectl get pod pod-name -o yaml
C.kubectl logs pod-name --previous
D.kubectl describe pod pod-name
AnswerA

Runs 'env' in the container, showing actual env vars.

Why this answer

kubectl exec allows running commands inside a container. 'env' will list environment variables.

46
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 reports network plugin not ready when the CNI plugin is not operational.

Why this answer

The kubelet's network plugin (e.g., CNI) is not ready, often because the pod network add-on is not deployed or misconfigured.

47
Multi-Selectmedium

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

Select 2 answers
A.Node resource pressure (CPU/memory)
B.Misconfigured startup probe
C.NetworkPolicy blocking egress
D.Application initialization failure
E.PersistentVolume not mounted
AnswersB, D

Why this answer

CrashLoopBackOff occurs when a container repeatedly starts and crashes. Application errors or misconfigured probes that cause the container to be killed lead to this state. Node resource pressure causes Pending or Eviction, not CrashLoopBackOff.

Missing volumes cause CreateContainerConfigError or CrashLoopBackOff only if the app fails without the volume. NetworkPolicy does not cause a container to crash.

48
MCQmedium

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

A.The PersistentVolumeClaim referenced by the pod does not exist or is not bound
B.The storage class used by the PVC does not match any PV
C.The scheduler is not configured to handle persistent volumes
D.The nodes do not have enough CPU or memory
AnswerA

The event explicitly states the PVC is not bound.

Why this answer

The PVC referenced by the pod is not bound to a PV. Option A correctly identifies this. Option B (different storage class) is a possible reason but not directly indicated.

Option C (scheduler conflict) is irrelevant. Option D (node resources) would produce a different event.

49
MCQmedium

You need to investigate why a service is not reachable from within the cluster. Which of the following is the first step?

A.Check kube-proxy logs on the nodes
B.Check DNS resolution
C.Check if the service has endpoints
D.Restart the service
AnswerC

Why this answer

Option C is correct because the most fundamental check when a service is unreachable from within the cluster is to verify whether the service has any endpoints. A service without endpoints means no pods are matching its selector, so traffic cannot be forwarded regardless of DNS or kube-proxy status. The `kubectl get endpoints <service>` command directly reveals this, making it the logical first step before deeper diagnostics.

Exam trap

The trap here is that candidates often jump to DNS or kube-proxy issues because those are common networking topics, but the CKA exam expects you to follow a logical troubleshooting hierarchy, starting with the simplest check—whether the service has any backing pods.

Why the other options are wrong

A

More advanced step; start with endpoints.

B

DNS is for service discovery, not connectivity.

D

Restarting is not troubleshooting.

50
Matchingmedium

Match each scheduling concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Simple label-based constraint

Expressive scheduling rules using labels

Repels Pods unless they tolerate the taint

Allows a Pod to be scheduled on a tainted Node

Determines scheduling precedence based on priority class

Why these pairings

Scheduling controls where Pods run; these mechanisms enforce placement policies.

51
MCQeasy

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

A.kubectl top pods -n production
B.kubectl get pods -n production --show-labels
C.kubectl get resourceusage pods -n production
D.kubectl top nodes -n production
AnswerA

This shows CPU and memory usage for pods in the namespace.

Why this answer

'kubectl top pods -n production' shows CPU and memory usage. Option A is for nodes. Option C is a made-up command.

Option D shows pod status, not resource usage.

52
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

If kubelet is not running, the node cannot report its status and becomes NotReady.

Why this answer

Options A and D are correct. Kubelet not running and network plugin issues are common reasons for a node to be NotReady. Option B (insufficient memory) would cause pods to be evicted, but the node remains Ready.

Option C (API server down) affects the entire cluster but nodes may still report Ready if kubelet is healthy. Option E (image pull) is a pod-level issue.

53
MCQmedium

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

A.The pod's log path is misconfigured
B.The container crashed before generating any log output
C.The kubelet has logging disabled
D.The pod is using a sidecar container for logging
AnswerB

If the container fails early, no logs may be produced.

Why this answer

If the container crashes before writing anything to stdout/stderr, logs will be empty. The crash may happen early in the startup process.

54
Multi-Selectmedium

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

Select 2 answers
A.The node is running an outdated kernel version
B.The kubelet service has stopped on the node
C.The node's disk is full
D.The container network plugin (e.g., Calico, Flannel) is not functioning
E.The node has insufficient CPU resources
AnswersB, D

If kubelet stops, the node status becomes NotReady.

Why this answer

Correct answers are B and C. Kubelet stopped or network plugin issues are common causes. A would cause scheduling issues but node would still be Ready.

D is not a direct cause. E is not a direct cause.

55
MCQhard

A user reports that they cannot access a service running in the cluster from within another pod. They run 'kubectl exec -it pod-a -- curl http://service-b:8080' and get a connection timeout. What is the first thing you should check?

A.Check if the service has a ClusterIP assigned.
B.Check if the kube-dns pod is running.
C.Check if the pod-a has network connectivity by pinging the node IP.
D.Check if the target service's pods have the correct labels.
AnswerD

If the selector doesn't match any pods, the service will have no endpoints and connections will timeout.

Why this answer

Since curl from within the pod times out, the issue might be that the service does not have any endpoints (no pods matching the selector). Checking endpoints is a quick way to verify if the service is backed by running pods.

56
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

Increasing the memory limit allows the container to use more memory and avoids OOMKilled.

Why this answer

Option C is correct. Memory limit is specified under resources.limits.memory. Option A is for requests, not limits.

Option B is for CPU. Option D is for CPU.

57
MCQeasy

You want to see the last 50 lines of logs from a pod named 'api-pod' for the container 'api-container'. Which command accomplishes this?

A.kubectl logs -l app=api --tail=50
B.kubectl logs api-pod --tail=50
C.kubectl logs api-pod -c api-container --tail=50
D.kubectl logs api-container -p api-pod --tail 50
AnswerC

The --tail flag limits output to the last N lines.

Why this answer

'kubectl logs api-pod -c api-container --tail=50' shows the last 50 lines for the specified container.

58
Multi-Selectmedium

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Select 3 answers
A.PersistentVolumeClaim not bound
B.Liveness probe failing
C.Container image does not exist
D.Insufficient CPU or memory resources on any node
E.Node taints that the pod does not tolerate
AnswersA, D, E

If pod uses a PVC that is not bound, it stays Pending.

Why this answer

Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

59
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

This shows the pod's status and events, including reason for ImagePullBackOff.

Why this answer

'kubectl describe pod <pod-name>' shows events and status details including image pull errors. Option A shows logs of a container, but the container hasn't started yet. Option C shows resource usage.

Option D lists events cluster-wide, but the pod description includes relevant events.

60
Matchingmedium

Match each logging/monitoring component to its role.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Log aggregator and forwarder

Metrics collection and alerting system

Dashboard and visualization tool

Exposes cluster object metrics

Provides resource usage metrics for autoscaling

Why these pairings

Observability relies on these components for logs, metrics, and visualization.

61
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 tolerations allows the Pod to be scheduled on tainted nodes.

Why this answer

Option B is correct. The Pod does not tolerate the taints on the nodes. Adding tolerations to the Pod's spec allows it to be scheduled.

Option A is possible but not appropriate if the taints are intentional. Option C is unrelated. Option D is about pods, not nodes.

62
Multi-Selecthard

A pod is repeatedly killed with 'OOMKilled'. The container's memory request is 256Mi and limit is 512Mi. Which THREE steps could help resolve the issue?

Select 3 answers
A.Increase the memory limit to 1Gi
B.Set memory request equal to limit (512Mi)
C.Remove the memory limit to allow unlimited usage
D.Optimize the application to use less memory
E.Check for memory leaks in the application
AnswersA, D, E

More headroom prevents OOM kills.

Why this answer

Increasing the memory limit to 1Gi (A) allows more memory. Reducing container memory usage (C) addresses root cause. Checking if there is a memory leak (E) helps prevent future OOM.

Removing the limit (B) is not recommended; setting request equal to limit (D) may not help and wastes resources.

63
MCQeasy

Which of the following is a valid command to check the status of the kubelet service on a node running systemd?

A.systemctl status kubelet
B.initctl status kubelet
C.systemctl list-units kubelet
D.service kubelet status
AnswerA

systemctl is the correct command to check service status on systemd-based systems.

Why this answer

Option A is correct. 'systemctl status kubelet' is the appropriate command for systemd-managed services. Option B is for systemd units that are not services. Option C is for init.d.

Option D is a deprecated command.

64
MCQhard

A Deployment has 3 replicas. One pod is in CrashLoopBackOff. You run 'kubectl logs <pod> --previous' and see only a single line: 'Error: failed to start container'. What is the most likely cause?

A.The container registry is not accessible
B.The container image is missing an entrypoint
C.The application crashes immediately due to a misconfiguration
D.The pod is exceeding its memory limit
AnswerC

A crash on startup often leaves little to no logs; the container runtime reports failure to start.

Why this answer

The --previous flag shows logs from the previous container instance. A single line about failing to start container indicates the application exited immediately before the container runtime could capture logs; usually due to a configuration issue that causes a crash on startup.

65
Multi-Selectmedium

A developer reports that a newly deployed Deployment named 'web-app' is not serving traffic. The Deployment has 3 replicas, a Service of type ClusterIP, and an Ingress. Which TWO commands should you run first to diagnose the issue?

Select 2 answers
A.kubectl describe svc web-app
B.kubectl logs deployment/web-app
C.kubectl get pods -l app=web-app
D.kubectl get events --sort-by='.lastTimestamp'
E.kubectl describe ingress web-app
AnswersA, C

Shows endpoints and selector matching.

Why this answer

Option A is correct because `kubectl describe svc web-app` shows the Service's ClusterIP, port mapping, and endpoint list. If the endpoints are empty, the Service has no healthy Pods to route traffic to, which is a common cause of traffic failure. This command directly checks whether the Service is correctly wired to the Pods.

Exam trap

The trap here is that candidates often jump to Ingress or logs first, but the CKA exam tests the systematic troubleshooting approach: verify the Service's endpoints and Pod health before examining higher-level abstractions like Ingress or cluster events.

66
MCQmedium

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

A.Test DNS resolution from a pod on the node
B.Run 'kubectl describe pod' for pods on that node
C.Check the kube-apiserver logs on the master node
D.Run 'journalctl -u kubelet' on the node to check kubelet logs
AnswerD

The kubelet is the node agent; its logs reveal why the node is NotReady.

Why this answer

Option B is correct. The kubelet is the primary agent on each node responsible for node status. Checking its logs with journalctl is the standard first step.

Option A is about the API server. Option C is for pods. Option D is for DNS.

67
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

Why this answer

If curl localhost works but external connection fails, the application is likely listening only on 127.0.0.1 instead of 0.0.0.0.

68
MCQeasy

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

A.kubectl logs --all-namespaces
B.kubectl top events
C.kubectl describe events
D.kubectl get events --sort-by='.metadata.creationTimestamp'
AnswerD

This command retrieves events sorted by creation timestamp.

Why this answer

Option A is correct. kubectl get events with --sort-by flag displays events sorted by timestamp. Option B is invalid. Options C and D are incorrect.

69
Multi-Selecthard

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

Select 3 answers
A.Run 'systemctl status kubelet' on the node
B.Restart the kube-apiserver on the control plane
C.Verify that the container runtime (e.g., containerd) is running
D.Run 'kubectl delete node <node-name>' to re-register
E.Check the kubelet logs with 'journalctl -u kubelet'
AnswersA, C, E

Why this answer

Troubleshooting a Node involves checking kubelet status, logs, and container runtime. Restarting apiserver or deleting the node are not appropriate first steps.

70
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 may be blocking traffic from pod-a to pod-b, especially across namespaces.

Why this answer

Option A is correct. NetworkPolicies can restrict ingress traffic across namespaces. Since pod-a can reach the Kubernetes service, the issue is likely a NetworkPolicy blocking the specific traffic.

Options B, C, and D are less likely.

71
Multi-Selecthard

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

Select 3 answers
A.A PersistentVolumeClaim used by the pod is not bound
B.The container image is not found and the pod is in ImagePullBackOff
C.Insufficient CPU or memory resources available on any node
D.The pod's tolerations do not match the taints on any node
E.The container's startup command is misconfigured
AnswersA, C, D

If a PVC is not bound, the pod cannot start and remains pending.

Why this answer

Correct answers are A, B, and D. Resource constraints, taint/toleration issues, and PVC not bound are common causes. C would cause CrashLoopBackOff, not Pending.

E would cause the pod to run.

72
Multi-Selecthard

You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)

Select 3 answers
A.Run 'kubectl describe pod pod-name' to check events
B.Run 'kubectl logs pod-name'
C.Run 'kubectl get pod pod-name -o jsonpath={.status.containerStatuses[0].state.waiting.reason}'
D.Run 'kubectl top pod pod-name'
E.Run 'kubectl delete pod pod-name'
AnswersA, B, C

Describe shows events and state information.

Why this answer

To debug a crash loop, check logs, describe events, and inspect the container exit code via describe.

73
MCQeasy

You need to check the logs of a container that previously ran but has crashed. Which command would you use?

A.kubectl logs pod --previous
B.kubectl logs pod -p
C.kubectl logs pod --all-containers
D.kubectl describe pod
AnswerA

kubectl logs pod --previous shows the logs of the last terminated container.

Why this answer

The --previous flag retrieves logs from the previous instance of a container in a pod.

74
MCQhard

A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?

A.The pod needs a toleration for node.kubernetes.io/not-ready
B.All nodes in the cluster are NotReady
C.The pod has a resource request that cannot be met
D.The scheduler is not running
AnswerB

Why this answer

The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Exam trap

The trap here is that candidates often confuse 'tolerating a taint' with 'fixing the node condition', and assume that adding a toleration is the correct solution, when the error message explicitly states that all nodes have the taint, meaning the nodes themselves are NotReady.

Why the other options are wrong

A

Tolerating this taint would schedule pods on unhealthy nodes.

C

Would show insufficient resources, not taint.

D

Would show 0 nodes available due to other reasons.

75
Multi-Selectmedium

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

Select 3 answers
A.Insufficient CPU or memory resources in the cluster
B.Taints on nodes that are not tolerated by the Pod
C.PersistentVolumeClaim is not bound to a PersistentVolume
D.Container exits with OOMKilled
E.Image pull error due to incorrect image name
AnswersA, B, C

If no node has enough resources, the Pod cannot be scheduled.

Why this answer

Options A, B, and E are correct. Insufficient cluster resources (A), taint/toleration mismatch (B), and PVC not bound (E) are common reasons for Pending. Option C (image pull error) causes ImagePullBackOff.

Option D (OOMKilled) causes CrashLoopBackOff.

Page 1 of 4 · 290 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cka Troubleshooting questions.