CKA Troubleshooting Practice Test 7 — 15 Questions

Question 1

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?

Accepted Answer

The CoreDNS deployment has 0 ready replicas.. 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.

Answer

The pod's dnsPolicy is set to Default instead of ClusterFirst.

Answer

The node's network plugin is misconfigured, blocking UDP port 53.

Answer

The pod's /etc/resolv.conf contains incorrect nameserver entries.

Question 2

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

Accepted Answer

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

Answer

kubectl describe node node-1

Answer

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

Answer

kubectl get deployment api -n production -o yaml

Question 3

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?

Accepted Answer

The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.. 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.

Answer

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

Answer

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

Answer

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

Question 4

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

Accepted Answer

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

Answer

The volume driver is not installed on node-1.

Answer

The pod has exceeded its resource limits.

Answer

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

Question 5

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?

Accepted Answer

The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.. 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.

Answer

The Service selector does not match the pod labels.

Answer

The NodePort service type is not enabled in the cluster.

Answer

The Ingress resource is missing or misconfigured.

Question 6

You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?

Accepted Answer

Network connectivity issue between kubelet and API server. When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.

Answer

The kubelet is not installed

Answer

The node has been cordoned

Answer

The API server is down

Question 7

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?

Accepted Answer

All nodes in the cluster are NotReady. 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.

Answer

The pod needs a toleration for node.kubernetes.io/not-ready

Answer

The pod has a resource request that cannot be met

Answer

The scheduler is not running

Question 8

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

Accepted Answer

Check if the service has endpoints. 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.

Answer

Check kube-proxy logs on the nodes

Answer

Check DNS resolution

Answer

Restart the service

Question 9

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

Accepted Answer

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

Answer

The main container has crashed

Answer

The pod is being initialized

Answer

There is a network error during initialization

Question 10

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Accepted Answer

kubectl logs -n kube-system -l k8s-app=kube-dns. `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Answer

kubectl delete pod -n kube-system -l k8s-app=kube-dns

Answer

kubectl scale deployment coredns --replicas=2

Answer

kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default

Question 11

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

Accepted Answer

kubectl describe pod . The `kubectl describe 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.

Answer

kubectl logs <pod>

Answer

kubectl get pod <pod> -o yaml

Answer

kubectl top pod <pod>

Question 12

A Node is in NotReady state. Which action should be taken first to diagnose the issue?

Accepted Answer

kubectl describe node . When a node is in NotReady state, the first diagnostic step is to gather information about the node's current status, conditions, and recent events using `kubectl describe node `. This command reveals the node's conditions (e.g., Ready, DiskPressure, MemoryPressure), the last heartbeat timestamp, and any relevant events that may indicate the root cause, such as network issues or kubelet failures. It provides a high-level overview without requiring direct node access, making it the most efficient initial action.

Answer

Check kubelet logs on the node

Answer

Restart kubelet

Answer

Check API server logs

Question 13

A pod is in ImagePullBackOff. Which command would help determine the exact reason?

Accepted Answer

kubectl describe pod . The `kubectl describe pod ` command provides detailed information about the pod, including the container state, the exact error message from the image pull (e.g., 'ImagePullBackOff'), and the underlying reason (e.g., 'Back-off pulling image', 'manifest for image not found', or 'unauthorized: authentication required'). This is the most direct way to see the specific error without needing to access the container or parse raw events.

Answer

kubectl logs <pod>

Answer

kubectl get events

Answer

kubectl exec -it <pod> -- sh

Question 14

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

Accepted Answer

kube-proxy not running or misconfigured. When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Answer

DNS resolution failure

Answer

Ingress controller not set up

Answer

Service type should be NodePort

Question 15

A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?

Accepted Answer

kubectl describe pod <pod-name>. The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.

Answer

kubectl logs <pod-name>

Answer

kubectl get events --watch

Answer

kubectl exec -it <pod-name> -- /bin/sh