CKA Troubleshooting Practice Test 18 — 15 Questions

Question 1

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?

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

Accepted Answer

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

Answer

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

Answer

Check if the container runtime is Docker

Answer

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

Question 2

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

Answer

kubectl logs --all-namespaces [wrong]

Answer

kubectl top events [wrong]

Answer

kubectl describe events [wrong]

Answer

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

Question 3

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

Accepted Answer

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

Answer

The pod's liveness probe is misconfigured

Answer

The pod's container image is missing

Answer

The pod has a memory limit that is too low

Question 4

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

Accepted Answer

Check the kubelet status using 'systemctl status kubelet' on the node. Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step. Option E (deleting and rejoining) is a recovery step.

Answer

Restart the kubelet using 'systemctl restart kubelet'

Answer

Delete the node object and rejoin it to the cluster

Question 5

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

Accepted Answer

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

Answer

kubectl get pod

Answer

kubectl logs <pod-name>

Answer

kubectl edit pod <pod-name>

Question 6

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?

Accepted Answer

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

Answer

The pod does not have network access to the mysql service

Answer

The mysql service is not exposed on port 3306

Answer

The database pod is not running

Question 7

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

Accepted Answer

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

Answer

The cluster is using a resource quota that is exhausted

Answer

The pod's memory limit is set too low

Answer

The nodes have taints that the pod does not tolerate

Question 8

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

Accepted Answer

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

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

Answer

journalctl -u kubelet

Answer

kubectl describe pod pod-name

Answer

systemctl status kubelet

Question 9

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

Accepted Answer

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

Answer

kubectl delete pod pod-name

Answer

kubectl exec -it pod-name -- sh

Answer

kubectl rollout restart deployment

Question 10

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

Accepted Answer

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

Answer

journalctl -u docker

Answer

journalctl -u kube-apiserver

Answer

journalctl -u kube-controller-manager

Question 11

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

Accepted Answer

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

Answer

kubectl exec pod-a -- nslookup service-b

Answer

curl http://:

Answer

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

Question 12

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?

Accepted Answer

The container runtime is unable to start the container due to a timeout. The error 'context deadline exceeded' indicates that the container runtime failed to start the container within the allowed time. This can happen if the container image takes too long to pull, the runtime is slow, or there is a network issue. Option A would produce an 'executable file not found' error. Option B would result in the application crashing, but logs would show output before the crash. Option C would also show a similar error to A. Therefore, D is the most likely cause.

Answer

The container image is missing the entrypoint

Answer

The application inside the container is crashing immediately

Answer

The container command is incorrectly specified

Question 13

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

Accepted Answer

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

Answer

kubectl describe nodes

Answer

kubectl top pods

Answer

kubectl get pods --show-resources

Question 14

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

Accepted Answer

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

Answer

Change the scheduler to a different one

Answer

Increase the CPU limit for the pod

Answer

Add more nodes to the cluster

Question 15

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?

Accepted Answer

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

Answer

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

Answer

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

Answer

The DNS name does not exist