CCNA Troubleshooting Questions

65 of 290 questions · Page 4/4 · Troubleshooting topic · Answers revealed

226
MCQeasy

Which command would you use to view all events in the cluster sorted by timestamp?

A.kubectl top events
B.kubectl logs --events
C.kubectl describe events
D.kubectl get events
AnswerD

Shows all events in the cluster sorted by last timestamp.

Why this answer

Option D is correct because `kubectl get events` retrieves all cluster events, which are Kubernetes API objects that record state changes and errors. By default, events are sorted by their `lastTimestamp` field, making this the direct command to view events ordered by timestamp.

Exam trap

The trap here is that candidates confuse `kubectl get events` with `kubectl describe events` or assume `kubectl top` or `kubectl logs` can retrieve events, but only `kubectl get events` provides a sorted list of all cluster events by timestamp.

How to eliminate wrong answers

Option A is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (e.g., `kubectl top node`), not events. Option B is wrong because `kubectl logs --events` is invalid; `kubectl logs` retrieves container logs, not cluster events, and the `--events` flag does not exist for this command. Option C is wrong because `kubectl describe events` is not a valid subcommand; `kubectl describe` works on resource types like `events` (e.g., `kubectl describe events`), but it shows details of a specific event or a filtered set, not a sorted list of all events.

227
MCQmedium

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

A.The nodes do not have enough resources to run the metrics collection
B.You do not have permission to view node metrics
C.The kubelet is not running on the nodes
D.The metrics-server is not installed or not running
AnswerD

The metrics server provides the data for kubectl top.

Why this answer

The metrics server is not deployed or not ready; kubectl top requires the metrics server to collect resource usage data.

228
MCQmedium

A Pod is stuck in CrashLoopBackOff. You run `kubectl logs <pod-name>` but see no output. What is the most likely cause?

A.The pod has no container defined.
B.The container crashes before writing to stdout/stderr.
C.The kubelet is not forwarding logs.
D.The pod is in a different namespace.
AnswerB

Why this answer

When a container crashes before it can write any output to stdout or stderr, `kubectl logs` returns no output because there is no log data to retrieve. This is a common symptom of a container that fails during initialization or immediately upon entry point execution, before any logging occurs.

Exam trap

The trap here is that candidates may assume empty logs indicate a logging infrastructure issue (like kubelet failure) rather than recognizing that the container simply never produced any output before crashing.

Why the other options are wrong

A

A pod must have at least one container; if not, it wouldn't be scheduled.

C

The kubelet forwards logs from the container runtime; if logs exist, they should appear.

D

kubectl logs defaults to the default namespace; if the pod is in another namespace, you'd get an error, not empty output.

229
MCQhard

You are debugging a CrashLoopBackOff. The pod YAML includes the following container spec: ```yaml containers: - name: app image: myapp:1.0 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 3 ``` The application starts successfully but crashes after about 10 seconds. What is the most likely cause?

A.The container image myapp:1.0 does not exist
B.The application's health endpoint /healthz is not responding with HTTP 200
C.The liveness probe is too aggressive, causing the container to be killed before it fully initializes
D.The pod is running out of memory
AnswerB

If the health endpoint does not return a success status, the liveness probe fails and kills the container, causing a restart.

Why this answer

Option B is correct. The liveness probe is failing, causing the container to be killed and restarted. The app starts but then the probe fails after a few seconds.

Options A, C, and D are inconsistent with the scenario.

230
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

This command shows logs from the kubelet service.

Why this answer

Option A is correct. 'journalctl -u kubelet' is the standard command to view kubelet logs on systemd-based systems. Option B is for Docker daemon. Option C is for kernel messages.

Option D is for Apache access logs.

231
MCQmedium

You run 'kubectl get pods' and see some pods in 'ImagePullBackOff' state. Which command would best help identify the root cause?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl get events --field-selector involvedObject.kind=Pod
D.kubectl exec <pod-name> -- cat /var/log/containers
AnswerB

Why this answer

Option B is correct because `kubectl describe pod <pod-name>` provides detailed information about the pod, including the status of its containers, events, and error messages from the kubelet. For an `ImagePullBackOff` state, the `describe` output will show the exact reason for the image pull failure (e.g., invalid image name, registry authentication failure, or network issues) in the `Status` and `Events` sections, making it the most direct troubleshooting command.

Exam trap

CNCF often tests the misconception that `kubectl logs` can retrieve startup errors, but in `ImagePullBackOff`, the container never runs, so logs are unavailable and `describe pod` is the correct tool to inspect the kubelet's event stream and container status.

Why the other options are wrong

A

The pod has not started, so there are no logs.

C

This would show events but not as detailed as describe pod; still acceptable but less direct.

D

Pod is not running; exec fails.

232
Multi-Selectmedium

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

Select 2 answers
A.The pod's liveness probe is failing
B.The container image is invalid
C.A PersistentVolumeClaim used by the pod is not bound
D.Insufficient CPU or memory resources on nodes
E.The pod's readiness probe is failing
AnswersC, D

If PVC is not bound, pod remains Pending.

Why this answer

Pending means pod cannot be scheduled. Resource constraints and PVC not bound are common causes.

233
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' displays CPU and memory usage of pods, provided the metrics server is deployed.

Why this answer

'kubectl top pods' requires the metrics server to be installed and shows current resource usage.

234
MCQeasy

Which command retrieves logs from a container that has crashed and restarted?

A.kubectl describe pod pod-name
B.kubectl logs pod-name --previous
C.kubectl logs pod-name -c container-name
D.kubectl logs pod-name --tail=100
AnswerB

Why this answer

The --previous flag retrieves logs from the previous instance of the container when the container has restarted.

235
Multi-Selecthard

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

Select 3 answers
A.The container's startup command has invalid arguments
B.The container image does not exist
C.The application tries to bind to a port that is already in use
D.The PersistentVolumeClaim is not bound
E.A required environment variable is not set
AnswersA, C, E

Invalid arguments cause the container to exit with non-zero code and restart.

Why this answer

Missing environment variables, invalid command arguments, and failure to bind to a port are common causes of container crashes. Option D (PVC not bound) causes Pending, not CrashLoopBackOff. Option E (image pull error) causes ImagePullBackOff.

236
MCQeasy

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

A.kubectl get events --watch
B.kubectl get events --sort-by=.metadata.creationTimestamp
C.kubectl logs --events
D.kubectl describe events
AnswerB

Why this answer

The --sort-by flag orders events by creation timestamp, showing recent events first.

237
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 pod anti-affinity prevents scheduling on the node that matches the rule.

Why this answer

Two nodes have a control-plane taint; the pod likely tolerates it. One node fails anti-affinity. To resolve, you must adjust the pod's anti-affinity or remove the conflicting pod.

238
MCQmedium

A pod is stuck in Pending state. Running 'kubectl describe pod mypod' reveals the event '0/4 nodes are available: 3 Insufficient memory, 1 node(s) had taints that the pod didn't tolerate'. What is the most likely cause?

A.The pod requests more memory than available on any node and does not tolerate a node taint
B.The kubelet on all nodes is not running
C.The pod's container image is not pullable
D.The pod is using a hostPort that conflicts with an existing pod
AnswerA

The event explicitly states insufficient memory and an untolerated taint.

Why this answer

The pod is pending because no node can satisfy its resource requirements or tolerate the node taints. The event indicates insufficient memory and a taint issue. The correct answer is that the pod requests more memory than any node can allocate and also does not tolerate a node taint.

239
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

Using a hardcoded IP that may change; should use the service name.

Why this answer

The application is likely using the wrong hostname or IP for the database. It should use the service name 'mysql' instead of a hardcoded IP.

240
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

Option C is correct. 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.

241
MCQeasy

To view the logs of a specific container in a multi-container pod named 'web-pod', which command is correct?

A.kubectl logs web-pod --all-containers
B.kubectl logs web-pod --container app-container
C.kubectl logs app-container -p web-pod
D.kubectl logs -c web-pod app-container
AnswerB

The --container (or -c) flag is used to specify the container name.

Why this answer

The correct command is 'kubectl logs web-pod -c app-container'. The -c flag specifies the container name.

242
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

Shows pod resource usage across all namespaces.

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.

243
Multi-Selectmedium

Which TWO of the following are valid reasons for a pod to be in 'CrashLoopBackOff' state? (Choose two.)

Select 2 answers
A.The pod is requesting more CPU than any node can provide
B.The application inside the container exits with a non-zero exit code immediately after starting
C.The liveness probe is failing, causing the container to be restarted repeatedly
D.The pod's persistent volume claim is not bound
E.The container image does not exist in the registry
AnswersB, C

If the application crashes immediately, the container exits with a non-zero code, and Kubernetes restarts it. This repeated failure leads to CrashLoopBackOff.

Why this answer

Options B and C are correct. A crash loop occurs when the container starts and then crashes repeatedly. The backoff delay increases with each restart.

Option B: If the application exits with a non-zero exit code, it will be restarted, leading to a crash loop if it keeps failing. Option C: A failing liveness probe causes the container to be restarted, leading to a crash loop. Option A (insufficient CPU) causes the pod to be in Pending state, not CrashLoopBackOff.

Option D (image not found) causes ImagePullBackOff. Option E (PVC not bound) causes Pending state.

244
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

If CoreDNS pods are down, the DNS service has no endpoints, causing connection timeouts. Check with 'kubectl get pods -n kube-system'.

Why this answer

Option A is correct. The failure to reach any DNS server suggests that the CoreDNS pod(s) may not be running or are not accessible. Option B would cause a different error (NXDOMAIN).

Option C would not cause a timeout; the pod would still be able to reach the DNS server but get no answer. Option D is a connectivity issue to the ClusterIP, but the timeout suggests the DNS server is not reachable, which points to the pods not running.

245
MCQeasy

Which command shows the logs of a pod that has crashed and restarted?

A.kubectl logs pod-name --previous
B.kubectl logs pod-name
C.kubectl logs pod-name -c container-name
D.kubectl describe pod pod-name
AnswerA

Displays logs from the previous terminated container.

Why this answer

kubectl logs --previous shows logs from the previous container instance.

246
MCQeasy

Which command shows resource usage (CPU/memory) of all pods in the default namespace?

A.kubectl describe pods
B.kubectl logs pods
C.kubectl top pods
D.kubectl get pods -o wide
AnswerC

Correct. kubectl top pods shows pod resource usage.

Why this answer

kubectl top pod shows CPU and memory metrics for pods.

247
MCQmedium

A node in your cluster is marked as NotReady. You SSH into the node and run 'systemctl status kubelet'. The output shows the kubelet is inactive (dead). What should you do FIRST to restore the node?

A.Reboot the node
B.Delete the node object from the cluster
C.Run 'systemctl start kubelet'
D.Reinstall the kubelet package
AnswerC

Starting the kubelet service will bring the node back to Ready.

Why this answer

The kubelet service is stopped. The first step is to start it with 'systemctl start kubelet'. If it fails to start, further investigation with journalctl is needed.

248
MCQmedium

You need to view the logs of the previous instance of a container in a pod. Which command is correct?

A.kubectl describe pod <pod-name>
B.kubectl exec <pod-name> -- cat /var/log/previous.log
C.kubectl logs <pod-name> -c <container-name> --previous
D.kubectl logs <pod-name> --all-containers --previous
AnswerC

The --previous flag combined with -c shows logs of the previous instance of a specific container.

Why this answer

Option A is correct. kubectl logs with --previous retrieves logs from the previous container instance. Option B is also plausible but the question expects the most direct command with container name.

249
MCQeasy

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

A.kubectl get events --watch
B.kubectl logs --events
C.kubectl describe events
D.kubectl get events --sort-by=.metadata.creationTimestamp
AnswerD

This sorts events by creation timestamp.

Why this answer

'kubectl get events --sort-by=.metadata.creationTimestamp' shows events sorted by creation time. Alternatively, 'kubectl get events -w' watches events but does not sort.

250
MCQmedium

You run 'kubectl get nodes' and one node shows 'NotReady'. Which command should you run first to check the kubelet status on that node?

A.journalctl -u kubelet
B.kubectl describe node <node-name>
C.cat /var/log/syslog | grep kubelet
D.systemctl status kube-apiserver
AnswerA

Correct. This shows kubelet logs.

Why this answer

The kubelet is responsible for node status. On the node, you can check its logs with journalctl.

251
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

This runs ping from inside the first pod to the IP of the second pod, testing layer 3 connectivity.

Why this answer

'kubectl exec' allows running commands inside a container, such as ping or curl to test connectivity.

252
MCQhard

You cannot reach a service by its DNS name from within a pod. Running 'kubectl exec -it dnsutils -- nslookup myservice' returns 'server can't find myservice: NXDOMAIN'. Which of the following is the MOST probable cause?

A.The service is in a different namespace and you are not using the fully qualified name
B.The pod's resolv.conf is missing the cluster domain
C.CoreDNS is configured with a custom upstream DNS server
D.The kube-dns pod is not running
AnswerA

DNS names are namespace-scoped. Use 'myservice.namespace.svc.cluster.local'.

Why this answer

The service exists but DNS resolution fails, often because the service is in a different namespace and the DNS query uses only the bare name.

253
MCQmedium

You have two Pods in different namespaces. Pod A (namespace: frontend) cannot reach Pod B (namespace: backend) via the ClusterIP service 'backend-svc' in the backend namespace. Which command should you use from within Pod A to test connectivity?

A.kubectl exec pod-a -n frontend -- curl http://backend-svc.backend.svc.cluster.local:80
B.kubectl exec pod-a -n frontend -- ping backend-svc.backend.svc.cluster.local
C.kubectl exec pod-a -n frontend -- curl http://backend-svc:80
D.kubectl exec pod-a -n frontend -- curl http://backend-svc.backend:80
AnswerA

This uses the full DNS name to access the service via HTTP.

Why this answer

Option C is correct. To test connectivity to a service, use the full DNS name including namespace: <service>.<namespace>.svc.cluster.local. Option A uses incorrect format.

Option B uses ping which tests ICMP, not TCP/UDP. Option D uses the service name without namespace, which may not resolve across namespaces.

254
Multi-Selecteasy

Which TWO of the following are valid methods to troubleshoot a pod that is stuck in 'Pending' state?

Select 2 answers
A.Run 'kubectl describe pod <pod-name>' and check the Events section.
B.Run 'kubectl logs <pod-name>' to view application logs.
C.Run 'kubectl exec -it <pod-name> -- /bin/sh' to inspect the container.
D.Run 'kubectl top pod <pod-name>' to check resource usage.
E.Run 'kubectl get events --sort-by=.metadata.creationTimestamp' to see recent cluster events.
AnswersA, E

Events show scheduling failures.

Why this answer

A is correct because 'kubectl describe pod <pod-name>' displays the Events section, which includes detailed reasons for a pod being stuck in Pending state, such as insufficient CPU/memory, persistent volume claims not binding, or node selector mismatches. This is the primary diagnostic command for understanding scheduling failures.

Exam trap

CNCF often tests the misconception that 'kubectl logs' or 'kubectl exec' can be used on any pod regardless of its lifecycle phase, but these commands require a running container, which does not exist in a Pending pod.

255
MCQmedium

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

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

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

Why this answer

Correct answer is A. 'kubectl logs pod-name --previous' shows logs of the previous container instance. Option B shows current logs. Option C is incorrect flag.

Option D shows logs of all containers, not previous.

256
MCQhard

You have a Deployment with three replicas. After a rolling update, all pods are in 'CrashLoopBackOff'. You want to revert to the previous revision. Which command accomplishes this?

A.kubectl rollout undo deployment/myapp --to-revision=1
B.kubectl delete deployment/myapp --cascade=foreground
C.kubectl rollout undo deployment/myapp
D.kubectl rollout status deployment/myapp --revision=2
AnswerC

This rolls back to the previous revision by default.

Why this answer

Option C is correct. 'kubectl rollout undo deployment myapp' reverts to the previous revision. Option A is incorrect because --to-revision=1 would roll back to the first revision, not the previous one.

257
MCQmedium

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which of the following is NOT a common cause?

A.The image tag does not exist
B.The image registry requires authentication
C.The image name is misspelled
D.The node has a taint that tolerates the pod
AnswerD

Taints affect scheduling, not image pulling. This would cause a Pending state, not ImagePullBackOff.

Why this answer

Node taints affect scheduling, not image pulling. ImagePullBackOff is related to the container image.

258
MCQhard

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

A.The container image is missing the entrypoint
B.The application inside the container is crashing immediately
C.The container command is incorrectly specified
D.The container runtime is unable to start the container due to a timeout
AnswerD

The error 'context deadline exceeded' indicates a timeout in the container runtime when trying to start the container. This could be due to a slow image pull or container runtime issue.

Why this answer

Option B is correct. 'context deadline exceeded' indicates that the container runtime timed out while trying to start the container. This is often due to the container image being large and the pull taking too long, or the container runtime being slow. Option A would show a different error.

Option C would show an application error in the logs. Option D would show a different error like 'executable file not found'.

259
MCQmedium

A pod is unable to resolve DNS names. You exec into the pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command hangs. What is the MOST likely cause?

A.The CoreDNS service is not running or is misconfigured
B.The pod's /etc/resolv.conf is missing
C.The kubelet is not running on the node
D.The pod's network policy blocks DNS traffic
AnswerA

Why this answer

If nslookup hangs, it suggests the DNS server is not responding, typically a CoreDNS issue.

260
MCQmedium

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

A.The network plugin is misconfigured
B.The node has been cordoned
C.The kubelet service is stopped
D.The container runtime is not installed
AnswerC

The status 'inactive (dead)' means the kubelet service is not running. Starting the service may resolve the issue.

Why this answer

The kubelet service is stopped or dead, which would cause the node to be NotReady.

261
MCQeasy

Which command would you use to check the status of the kube-apiserver on a control plane node managed by systemd?

A.kubectl get apiservice
B.service kube-apiserver status
C.journalctl -u kubelet
D.systemctl status kube-apiserver
AnswerD

Standard way to check the service status.

Why this answer

systemctl status shows the current state of a systemd service.

262
MCQeasy

A node in your cluster is reporting a DiskPressure condition. Which kubectl command would you use to get details about the node's condition?

A.kubectl get nodes
B.kubectl describe node <node-name>
C.kubectl logs <node-name>
D.kubectl get events --field-selector involvedObject.kind=Node
AnswerB

Why this answer

The `kubectl describe node <node-name>` command provides detailed information about a node, including its status, capacity, allocatable resources, and a list of conditions (e.g., DiskPressure, MemoryPressure, PIDPressure, Ready). This is the standard way to inspect the exact reason and timestamps for a DiskPressure condition, as well as related metrics like disk usage and inode consumption.

Exam trap

CNCF often tests the distinction between high-level status commands (`kubectl get nodes`) and detailed diagnostic commands (`kubectl describe node`), trapping candidates who think a simple status list is sufficient to investigate a specific condition like DiskPressure.

Why the other options are wrong

A

This only lists nodes and high-level status, not detailed conditions.

C

Logs are for pods, not nodes.

D

Events may show node issues but the describe command is more comprehensive for conditions.

263
MCQhard

You have a Deployment with livenessProbe configured. The pod restarts every few minutes. 'kubectl describe pod' shows the liveness probe is failing with 'HTTP probe failed with statuscode: 503'. The application's /healthz endpoint returns 200 from within the pod using 'kubectl exec'. What could be the issue?

A.The readinessProbe is interfering with the livenessProbe
B.The application has a memory leak
C.The kubelet on the node is misconfigured
D.The livenessProbe is configured with the wrong port
AnswerD

If the probe uses a port that the application is not listening on, it will get a non-200 response.

Why this answer

The liveness probe is failing externally but the endpoint works internally. This suggests the probe is hitting the wrong port or the network path is different. The most likely cause is that the livenessProbe is configured with a wrong port number.

264
MCQeasy

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

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

Both commands are commonly used to check the status of the API server, depending on whether it's managed by systemd or as a static pod.

Why this answer

Option C is correct. On a control plane node, you can check the kube-apiserver status using 'systemctl status kube-apiserver' if it's running as a systemd service, or by checking the pod if it's running as a static pod: 'kubectl get pods -n kube-system'. Option A uses 'ps aux' which is not a standard systemctl command.

Option B 'docker ps' would show containers but not the service status. Option D 'journalctl -u kubelet' shows kubelet logs, not apiserver.

265
MCQeasy

Which command can you use to view the logs of a container that has crashed and been restarted?

A.kubectl describe pod pod-name
B.kubectl logs pod-name --previous
C.kubectl exec pod-name -- cat /var/log/crash.log
D.kubectl logs pod-name
AnswerB

This shows logs from the previous terminated container.

Why this answer

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

266
MCQmedium

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

A.kubectl describe events
B.kubectl get events --sort-by='.lastTimestamp'
C.kubectl get pods --show-events
D.kubectl logs --tail=100
AnswerB

Correct. This sorts events by timestamp.

Why this answer

kubectl get events shows cluster events with timestamps.

267
MCQhard

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

A.journalctl -u kubelet
B.systemctl start kubelet
C.kubectl delete node <node-name>
D.systemctl restart docker
AnswerB

The service is stopped; starting it may resolve the issue.

Why this answer

Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

268
Multi-Selecthard

Which THREE are valid steps to troubleshoot a node that is in 'NotReady' state? (Select 3)

Select 3 answers
A.Check kubelet logs with 'journalctl -u kubelet'
B.Verify that the CNI plugin pods are running
C.SSH into the node and run 'systemctl status kubelet'
D.Run 'kubectl get events' from the control plane
E.Restart the kube-apiserver on the control plane
AnswersA, B, C

Logs reveal kubelet errors.

Why this answer

Check kubelet status, logs, and network plugin. Restarting kubelet may help; checking API server is not node-specific.

269
MCQmedium

You deploy a pod with a readiness probe that checks an HTTP endpoint. The probe fails and the pod is marked as 'NotReady'. Which command would you use to see the exact HTTP response from the probe?

A.kubectl logs mypod -c mycontainer
B.kubectl describe pod mypod
C.kubectl exec mypod -- curl http://localhost:8080/healthz
D.kubectl get pod mypod -o yaml
AnswerB

Describe shows the last probe result and the reason for failure.

Why this answer

'kubectl describe pod' shows the probe details including the specific failure message (e.g., HTTP response code).

270
MCQmedium

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

A.ssh to the node and run 'docker ps'
B.kubectl describe node <node-name>
C.kubectl logs kubelet -n kube-system
D.systemctl status kubelet
AnswerD

'systemctl status kubelet' shows the current status of the kubelet service and can reveal if it is stopped or failing.

Why this answer

The kubelet is the primary node agent. Using 'journalctl -u kubelet' shows the kubelet logs, which can indicate why the node is not ready.

271
MCQmedium

A pod is in 'CrashLoopBackOff' state. You run 'kubectl logs my-pod' and see 'exec format error: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

A.The container has insufficient memory
B.The container runtime is not installed
C.The container image is missing the specified command or entrypoint
D.The pod's service account lacks permissions
AnswerC

The error 'exec format error' or 'no such file or directory' typically means the command specified in the image or pod spec is incorrect or the binary is missing.

Why this answer

The error indicates the container's entrypoint or command is trying to execute a file that does not exist or is not executable.

272
MCQmedium

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

A.kubectl logs my-pod -c --previous
B.kubectl logs my-pod --tail=100
C.kubectl logs my-pod -p
D.kubectl logs my-pod --previous
AnswerD

Correct. kubectl logs --previous retrieves logs from the previous container instance.

Why this answer

The --previous flag shows logs from the previous instance of the container.

273
MCQeasy

You have a pod that is in 'Pending' state. Which command would you use to view detailed information about the pod's status, including events that may indicate why it is not running?

A.kubectl get endpoints
B.kubectl logs pod
C.kubectl describe pod
D.kubectl get pod
AnswerC

'kubectl describe pod' shows detailed information including events and conditions.

Why this answer

Option B is correct. 'kubectl describe pod' provides detailed information including events, conditions, and container statuses that help troubleshoot why a pod is pending. Option A only shows a brief summary. Option C is for viewing container logs.

Option D checks service endpoints.

274
MCQeasy

You deploy a pod with the following YAML and it remains in 'Pending' state. What is the most likely cause? ```yaml apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: myapp image: nginx resources: requests: memory: "64Gi" ```

A.The pod requests more memory than any node can allocate.
B.The pod is missing a required label.
C.The pod has a taint that no toleration matches.
D.The image 'nginx' does not exist.
AnswerA

64Gi is a large memory request that may exceed the capacity of nodes in the cluster.

Why this answer

The pod requests 64Gi of memory, which is likely not available on any node in the cluster. The pod remains Pending because no node can satisfy the resource request.

275
MCQhard

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

A.A NetworkPolicy is blocking traffic from the test pod to the service IP.
B.The service type should be NodePort to allow in-cluster access.
C.The readiness probe is failing on all pods, causing them to be removed from service endpoints.
D.The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.
AnswerD

Selector mismatch is the classic cause of empty endpoints.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

276
MCQmedium

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

A.Delete the namespace and redeploy all workloads
B.Increase the CPU request for the container
C.Increase the memory limit in the pod's container resource specification
D.Delete and recreate the pod to clear the crash loop
AnswerC

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.

277
Multi-Selecthard

You have a Deployment that is not scaling up beyond 1 replica despite setting replicas: 3. Which of the following could be the cause? (Select all that apply)

Select 3 answers
A.A ResourceQuota in the namespace limits the number of pods
B.The cluster has insufficient resources (CPU/memory) to schedule additional pods
C.A PodDisruptionBudget is set with minAvailable: 1
D.The ReplicaSet controller is malfunctioning
AnswersA, B, D

Why this answer

A ResourceQuota in the namespace can limit the total number of Pods that can be created. If the quota is set to a value that allows only one Pod (or the current count already meets the quota), the Deployment cannot scale beyond 1 replica. This is enforced by the API server during Pod creation, and the ReplicaSet controller will see the quota limit and stop creating additional Pods.

Exam trap

The trap here is that candidates confuse PodDisruptionBudget with a scaling limiter, but PDB only restricts voluntary disruptions, not the number of replicas a Deployment can create.

Why the other options are wrong

C

PDB prevents voluntary disruptions, not scaling up; it does not block creation of new pods.

278
Multi-Selectmedium

You run 'kubectl get pods' and see that a pod named 'db' is in 'CrashLoopBackOff'. Which TWO commands are most useful for diagnosing the issue? (Choose two)

Select 2 answers
A.kubectl top pod db
B.kubectl describe pod db
C.kubectl logs db
D.kubectl get pod db -o yaml
E.kubectl exec db -- /bin/sh
AnswersB, C

Shows events, state, and last termination reason.

Why this answer

Describe and logs are the standard first steps to see events and container output.

279
MCQmedium

A Node is reporting DiskPressure condition. Which action is most appropriate to resolve this without losing data?

A.kubectl delete node <node-name>
B.Add additional disk space to the node or clean up unused images and logs
C.kubectl drain <node-name> --ignore-daemonsets
D.Restart the kubelet service
AnswerB

Why this answer

Option B is correct because DiskPressure indicates that the node's disk usage has exceeded the eviction threshold (default 85% for imagefs.available and nodefs.available). Adding disk space or cleaning up unused container images (via `crictl rmi` or `docker image prune`) and logs (via log rotation or `journalctl --vacuum`) directly frees up space without affecting running workloads or causing data loss, addressing the root cause.

Exam trap

The trap here is that candidates confuse DiskPressure with node unavailability and choose `kubectl drain` (Option C) to evacuate pods, not realizing that draining does not resolve the disk space issue and can cause data loss for stateful workloads.

Why the other options are wrong

A

Deleting the node removes it from cluster; does not fix disk pressure.

C

Drain evicts pods but does not free disk space; disk pressure persists.

D

Restarting kubelet does not free disk space; pressure will remain.

280
MCQmedium

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

A.Taint toleration mismatch and pod anti-affinity conflicts
B.Pod anti-affinity and node selector issues
C.Node selector and taint toleration mismatch
D.Resource constraints and taint toleration mismatch
AnswerA

The event explicitly mentions both.

Why this answer

The event message directly states two issues: one node has a taint not tolerated, and three nodes don't match pod anti-affinity rules. Option A correctly identifies both. Option B describes two similar issues but not the exact ones.

Option C adds an incorrect issue (resource constraints). Option D doesn't match.

281
MCQhard

You run 'kubectl get pods' and see a pod in CrashLoopBackOff. The pod has a single container. You want to see the last termination message from the container. Which command will provide that information?

A.kubectl events pod
B.kubectl get pod -o yaml
C.kubectl logs pod --tail=50
D.kubectl describe pod
AnswerD

The describe output includes the last termination message under container status.

Why this answer

kubectl describe pod shows the last state's termination message in the container status section.

282
Multi-Selecteasy

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

Select 2 answers
A.kubectl get nodes
B.journalctl -u docker
C.journalctl -u kubelet
D.systemctl status kubelet
E.kubectl describe pod
AnswersC, D

Shows kubelet logs from systemd journal, useful for troubleshooting.

Why this answer

journalctl -u kubelet (A) shows kubelet logs from systemd journal, and systemctl status kubelet (C) shows current kubelet status. 'kubectl get nodes' shows node status but not kubelet details. 'kubectl describe pod' is for pods. 'journalctl -u docker' shows container runtime logs, not kubelet.

283
MCQmedium

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

A.ping
B.tcpdump
C.curl
D.nslookup
AnswerD

nslookup queries DNS servers and is commonly used for DNS troubleshooting.

Why this answer

Option B is correct. nslookup and dig are DNS troubleshooting tools. Option A is for network debugging but not DNS-specific. Option C is for HTTP requests.

Option D is for network connectivity.

284
MCQmedium

You deploy a pod with the following YAML: apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test image: nginx resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" The pod starts, but after a few minutes it is killed with OOMKilled. What is the MOST likely reason?

A.The memory limit is lower than the memory request
B.The node has swap enabled
C.The container's memory usage exceeds the configured limit
D.The container is using too much CPU
AnswerC

The container is using more than 128Mi of memory, causing the OOM killer to terminate it.

Why this answer

Option D is correct. OOMKilled occurs when the container exceeds its memory limit. The limit is 128Mi, so if the nginx container uses more than 128Mi of memory, it will be killed.

Option A is incorrect because CPU limits cause throttling, not OOM. Option B is incorrect because swap is typically disabled in Kubernetes. Option C is incorrect because the request is lower than the limit, which is allowed.

285
MCQmedium

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

A.kubectl top pod <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl rollout status deployment <deployment-name>
D.kubectl get events --field-selector involvedObject.name=<pod-name>
AnswerB

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

Why this answer

kubectl describe pod shows the last state and exit code, and kubectl logs shows application output; but for a crash loop, describe gives the last state details.

286
MCQeasy

You need to verify if the kube-apiserver is running on the control plane node. Which command should you use?

A.kubectl describe node controlplane
B.kubectl get services -n default
C.systemctl status kube-apiserver
D.kubectl get pods -n kube-system
AnswerD

The kube-apiserver typically runs as a pod in the kube-system namespace (e.g., in kubeadm clusters). Checking this namespace shows its status.

Why this answer

'kubectl get pods -n kube-system' lists system pods including the kube-apiserver, if it runs as a static pod or deployed by kubeadm.

287
Multi-Selectmedium

A worker node is marked NotReady. Which two checks are most relevant to diagnose the node's kubelet health? (Choose two.)

Select 2 answers
A.systemctl status kubelet
B.kubectl get nodes
C.journalctl -u kubelet -n 50
D.Check API server logs
AnswersA, C

Why this answer

A is correct because `systemctl status kubelet` directly queries the systemd service manager to report whether the kubelet process is running, its current state (active/inactive/failed), and recent log entries. Since the kubelet is the primary node agent responsible for registering the node and reporting status to the control plane, checking its service status is the most immediate step when a node is NotReady.

Exam trap

CNCF often tests the misconception that `kubectl get nodes` is a diagnostic tool for node-level issues, when in fact it only reflects the symptom, not the cause; candidates must remember that local service inspection (systemctl/journalctl) is required for kubelet troubleshooting.

Why the other options are wrong

B

Shows status but not kubelet health directly.

D

Not specific to node kubelet.

288
MCQmedium

You have a Deployment that is failing to update. You run 'kubectl rollout status deployment/myapp' and it hangs. Which command should you run to see the status of individual ReplicaSets and pods?

A.kubectl describe deployment myapp
B.kubectl rollout history deployment/myapp
C.kubectl logs deployment/myapp
D.kubectl get replicasets -l app=myapp
AnswerB

This command lists revisions and the ReplicaSets associated with each revision.

Why this answer

'kubectl rollout history' shows revision history and details of each ReplicaSet, which helps in troubleshooting rollout issues.

289
Multi-Selecteasy

Which TWO of the following are valid ways to view the status of the kube-apiserver? (Select 2)

Select 2 answers
A.kubectl describe node
B.journalctl -u kubelet
C.systemctl status kube-apiserver
D.kubectl get pods -n kube-system -l component=kube-apiserver
E.kubectl logs kube-apiserver
AnswersC, D

If kube-apiserver runs as a systemd service.

Why this answer

On static-pod clusters, kubectl get pods -n kube-system shows apiserver status. On systemd systems, systemctl status kube-apiserver works.

290
MCQhard

You have a Deployment with 3 replicas. Two pods are Running, one is CrashLoopBackOff. You run 'kubectl logs pod-crash -c app' and see: 'Error: failed to connect to database at 10.0.0.5:5432'. The database is a separate Pod with a ClusterIP service. How should you verify network connectivity from the crashing pod to the database service?

A.kubectl exec -it running-pod -- sh -c 'curl http://db-service:5432'
B.kubectl port-forward svc/db-service 5432:5432
C.kubectl exec -it pod-crash -- sh -c 'curl http://db-service:5432'
D.kubectl logs db-pod
AnswerA

Exec into a healthy pod and test connectivity to the db-service.

Why this answer

Using kubectl exec to run a command like curl or telnet from a running pod in the same namespace can test connectivity to the database service.

← PreviousPage 4 of 4 · 290 questions total

Ready to test yourself?

Try a timed practice session using only Troubleshooting questions.