CKA Troubleshooting Practice Test 5 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Check if the target service's pods have the correct labels.. 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.

Answer

Check if the service has a ClusterIP assigned.

Answer

Check if the kube-dns pod is running.

Answer

Check if the pod-a has network connectivity by pinging the node IP.

Question 2

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?

Accepted Answer

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

Answer

kubectl logs mypod -c mycontainer

Answer

kubectl exec mypod -- curl http://localhost:8080/healthz

Answer

kubectl get pod mypod -o yaml

Question 3

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?

Accepted Answer

kubectl rollout undo deployment/myapp. '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.

Answer

kubectl rollout undo deployment/myapp --to-revision=1

Answer

kubectl delete deployment/myapp --cascade=foreground

Answer

kubectl rollout status deployment/myapp --revision=2

Question 4

You have a pod that is 'CrashLoopBackOff'. 'kubectl logs --previous mypod' shows: 'Liveness probe failed: HTTP probe failed with statuscode: 503'. Which THREE actions could potentially fix the issue? (Choose three)

Accepted Answer

Increase the initialDelaySeconds to give the app more time to start.. Option B (Increase the initialDelaySeconds) is correct because the liveness probe is firing before the application has finished starting up, so giving it more time before the first probe prevents premature failures that trigger restarts and CrashLoopBackOff. Option C (Change the liveness probe path to a valid endpoint that returns 200) is correct because a 503 status code means the probed path is returning Service Unavailable, so pointing the probe at a healthy endpoint that returns HTTP 200 will make the probe succeed. Option D (Increase the failureThreshold) is correct because raising the number of tolerated consecutive failures allows the application to survive transient 503 responses during startup or warm-up without being killed and restarted. Option A is wrong because converting a liveness probe to a readiness probe changes the semantics entirely: readiness only removes the pod from Service endpoints and does not restart the container, so it does not address the CrashLoopBackOff caused by liveness failures. Option E is wrong because removing the liveness probe entirely eliminates health monitoring and is not a proper fix; it would mask the underlying problem rather than resolve the failing probe.

Answer

Change the liveness probe to a readiness probe.

Answer

Remove the liveness probe entirely.

Question 5

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

Accepted Answer

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

Answer

kubectl logs my-pod -c --previous

Answer

kubectl logs my-pod --tail=100

Answer

kubectl logs my-pod --past

Question 6

A Deployment is configured with replicas: 3, but only 2 pods are running. 'kubectl describe deployment' shows 'Replicas: 3 desired | 2 current | 2 available'. What could be the reason for the missing pod?

Accepted Answer

A PersistentVolumeClaim used by the pod is not bound. If a pod uses a PersistentVolumeClaim (PVC) that is not bound to an available PersistentVolume, the pod will remain in a Pending state and never become Running. The Deployment controller creates the ReplicaSet and pods, but the scheduler cannot schedule the pod until the PVC is bound, resulting in only 2 out of 3 desired pods being available.

Answer

The ReplicaSet is not created

Answer

The Deployment's selector does not match the pod template labels

Answer

The node has a disk pressure condition

Question 7

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

Accepted Answer

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

Answer

kubectl get pods -n kube-system

Answer

journalctl -u kubelet

Answer

ps aux | grep kube-controller

Question 8

A pod is in Running state but cannot connect to a service by its DNS name. 'kubectl exec <pod> -- curl http://my-service' fails. Which is the most likely cause?

Accepted Answer

The pod is in a different namespace than the service. The service must be in the same namespace for DNS resolution by short name; otherwise, you need the full name ..svc.cluster.local.

Answer

The service type is NodePort

Answer

The pod's container image does not have curl installed

Answer

The service has no endpoints

Question 9

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

Accepted Answer

kubectl get events --sort-by='.lastTimestamp'. kubectl get events shows cluster events with timestamps.

Answer

kubectl describe events

Answer

kubectl get pods --show-events

Answer

kubectl logs --tail=100

Question 10

Which TWO commands can be used to view logs for a pod?

Accepted Answer

kubectl describe pod my-pod. Option D, `kubectl logs my-pod`, is correct because it is the primary command for retrieving the stdout/stderr log stream of a container in a pod, which is exactly what is needed to view pod logs. Option C, `kubectl describe pod my-pod`, is also correct because its output includes the pod's Events section, which surfaces log-like diagnostic information such as container start/stop reasons, image pull failures, and scheduling messages. Option A is not the intended answer because `kubectl exec ... cat /var/log/app.log` only works if the application writes to that specific file inside the container and requires exec access, rather than reading the container runtime's log stream. Option B, `kubectl top pod my-pod`, reports CPU and memory usage metrics, not logs. Option E, `kubectl get pod my-pod -o yaml`, returns the pod's manifest/status in YAML and does not display log output.

Answer

kubectl exec my-pod -- cat /var/log/app.log

Answer

kubectl top pod my-pod

Answer

kubectl get pod my-pod -o yaml

Question 11

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?

Accepted Answer

Increase the memory limit in the pod's container resource specification. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification. Option A would delete the namespace and all workloads, which is too drastic and would affect other pods. Option B increases CPU request, which does not address the memory issue. Option D deletes and recreates the pod without fixing the resource limits, so the crash loop would continue.

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Question 12

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows the following event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' Which action would resolve the issue?

Accepted Answer

Add tolerations to the pod spec matching the taints on the nodes. Adding tolerations to the pod spec that match the taints on the nodes. The scheduler event explicitly states that all 4 nodes are unavailable because the pod does not tolerate the master taint (node-role.kubernetes.io/master) or the disk-pressure taint (node.kubernetes.io/disk-pressure), so the pod remains Pending; tolerations in the pod spec allow the scheduler to bind the pod to those tainted nodes. Option A only inspects node conditions and does not change scheduling. Option B removes only the master taint and ignores the disk-pressure taints on the other 3 nodes, so the pod could still fail to schedule. Option C cordons a node, which marks it unschedulable and would worsen the problem rather than resolve it.

Answer

Run 'kubectl describe node node-name' on each node to check conditions

Answer

Run 'kubectl taint nodes node-name node-role.kubernetes.io/master:NoSchedule-' to remove the taint

Answer

Run 'kubectl cordon node-name' on the node with the master taint

Question 13

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. Which of the following is the MOST likely cause?

Accepted Answer

The Metrics Server is not deployed in the cluster. The 'error: Metrics API not available' error indicates that the Metrics API service (v1beta1.metrics.k8s.io) is not registered with the API server, which most commonly happens when the Metrics Server is not deployed in the cluster. Option C is correct. Option A would result in a connection refused error. Option B and D would not prevent the Metrics API itself from being available, though they might lead to missing metrics for specific nodes.

Answer

The Kubernetes API server is down

Answer

The kubelet is not running on all nodes

Answer

One or more nodes are in NotReady state

Question 14

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?

Accepted Answer

The CoreDNS pod(s) are not running or are misconfigured. 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.

Answer

The kube-dns service does not exist

Answer

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

Answer

The pod's network policy blocks DNS traffic

Question 15

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

Accepted Answer

The kubelet service has stopped on the node. Option C is correct because the kubelet is the node agent that registers the node with the API server and continuously reports its status via heartbeats; if the kubelet service stops, the node's status updates cease and the node is marked NotReady. Option E is correct because the node's Ready condition depends on the Container Network Interface (CNI) plugin (e.g., Calico, Flannel) being healthy; if the network plugin is not functioning, the kubelet's network-ready check fails and the node reports NotReady. Option A is incorrect because ImagePullBackOff is a pod-level status affecting a single container's image pull, not the node's Ready condition. Option B is incorrect because insufficient memory typically causes pod evictions or scheduling failures (MemoryPressure conditions), not the node transitioning to NotReady. Option D is incorrect because if the API server is down, the node may still run workloads but status reporting is disrupted cluster-wide, and the node itself is not the cause of the NotReady state.

Answer

A pod on the node is in ImagePullBackOff

Answer

The node has insufficient memory

Answer

The Kubernetes API server is down