CKA Troubleshooting Practice Test 11 — 15 Questions

Question 1

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

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

Accepted Answer

The nodes are unreachable or have network issues. The event '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }' indicates that all nodes in the cluster have the 'node.kubernetes.io/unreachable' taint, which is automatically applied by the node controller when a node becomes unreachable (e.g., due to network partition, node failure, or kubelet not reporting). Since the pod does not have a toleration for this taint, it cannot be scheduled on any node, resulting in a 'Pending' state. This is a classic scheduling failure caused by node unreachability, not by resource constraints or image issues.

Answer

The pod's container image is not found

Answer

The pod has a resource request that cannot be met by any node

Answer

The PersistentVolumeClaim is not bound

Question 2

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?

Accepted Answer

kubectl logs pod-name --previous. The `kubectl logs` command with the `--previous` flag retrieves the logs from the previous instance of a container in a pod, which is exactly what you need when the current container is running but the previous one crashed. This flag works by accessing the terminated container's logs stored by the kubelet, allowing you to debug the crash without needing to access the node directly.

Answer

kubectl exec pod-name -- cat /var/log/crash.log

Answer

kubectl attach pod-name

Answer

kubectl logs pod-name -c container-name

Question 3

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

Accepted Answer

The node has a taint that tolerates the pod. NOT a common cause of ImagePullBackOff because taints and tolerations affect pod scheduling, not image pulling. ImagePullBackOff occurs when the kubelet fails to pull the container image from the registry, which is a runtime issue unrelated to node scheduling constraints.

Answer

The image tag does not exist

Answer

The image registry requires authentication

Answer

The image name is misspelled

Question 4

You want to check the current resource usage (CPU and memory) of pods in the 'default' namespace. Which kubectl command should you use?

Accepted Answer

kubectl top pods. `kubectl top pods` retrieves real-time CPU and memory metrics for pods from the metrics server, which is the standard way to check current resource usage in a Kubernetes cluster. This command relies on the Metrics API and requires the metrics server to be deployed.

Answer

kubectl get pods -o wide

Answer

kubectl logs pods

Answer

kubectl describe pods

Question 5

You are debugging a DNS issue from within a pod. The pod is running 'busybox'. Which command would you use to test DNS resolution for 'kubernetes.default.svc.cluster.local'?

Accepted Answer

kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local. `kubectl exec -it my-pod -- nslookup kubernetes.default.svc.cluster.local` runs the `nslookup` command directly inside the running pod, which uses the pod's configured DNS resolver (typically CoreDNS) to resolve the Kubernetes service FQDN. This is the standard method to test DNS resolution from within a pod, as it bypasses any external DNS and validates the cluster's internal DNS chain.

Answer

kubectl describe svc kubernetes -n default

Answer

kubectl exec -it my-pod -- curl kubernetes.default.svc.cluster.local

Answer

kubectl run test --image=busybox -- nslookup kubernetes.default.svc.cluster.local

Question 6

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?

Accepted Answer

kubectl describe pod . C is correct because 'kubectl describe pod ' provides a detailed summary of the pod's current state, including a chronological list of events related to that specific pod (e.g., image pull failures, container restarts, scheduling issues). This command surfaces the exact error messages and timestamps for each event, making it the most direct way to investigate a 'Failed to pull image' event.

Answer

kubectl get pod <pod-name> -o yaml

Answer

kubectl top pod <pod-name>

Answer

kubectl logs <pod-name>

Question 7

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?

Accepted Answer

kubectl exec first-pod -- ping . `kubectl exec first-pod -- ping ` runs the `ping` command inside the first pod, which uses ICMP to test IP-level connectivity to the second pod's IP address. This directly verifies whether the network path between the two pods is functional, including any CNI plugin, overlay network, or network policy rules.

Answer

kubectl logs first-pod

Answer

kubectl top pod first-pod

Answer

kubectl exec second-pod -- ping <first-pod-ip>

Question 8

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?

Accepted Answer

The kubelet service is stopped. The kubelet is the primary node agent that runs on every node and is responsible for maintaining pod lifecycles. When 'systemctl status kubelet' shows 'Active: inactive (dead)', it means the kubelet systemd service is not running. Since the kubelet must be active for the node to report its status to the control plane, a stopped kubelet directly causes the node to be 'NotReady'.

Answer

The network plugin is misconfigured

Answer

The node has been cordoned

Answer

The container runtime is not installed

Question 9

A pod is stuck in 'Pending' state. Which TWO of the following are common causes?

Accepted Answer

A taint on the node that the pod does not tolerate. A pod enters 'Pending' state when it cannot be scheduled onto a node. Taints on a node with `NoSchedule` or `NoExecute` effects prevent pods that do not have matching tolerations from being scheduled there. This is a common cause because the scheduler skips tainted nodes unless the pod explicitly tolerates the taint, leaving the pod unscheduled and stuck in Pending.

Answer

The service account does not exist

Answer

The pod's liveness probe is failing

Answer

The pod's container image does not exist

Question 10

Which TWO of the following are valid commands to check the status of control plane components?

Accepted Answer

systemctl status kube-apiserver. `systemctl status kube-apiserver` directly queries the systemd service manager for the status of the kube-apiserver process, which is a core control plane component. Option C is correct because `kubectl get pods -n kube-system` lists all pods in the kube-system namespace, which includes control plane components like etcd, kube-scheduler, and kube-controller-manager when they run as static pods or Deployments. Both commands provide direct visibility into the health of control plane components.

Answer

kubectl get nodes

Answer

kubectl get events --all-namespaces

Answer

kubectl top nodes

Question 11

Which kubectl command is used to view the logs of a container that has previously crashed in a pod?

Accepted Answer

kubectl logs pod-name --previous. The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and been restarted. This is essential for debugging crash loops, as the current container may have no logs or only startup logs, while the crashed container's logs contain the error.

Answer

kubectl logs pod-name -c container-name --tail=100

Answer

kubectl logs pod-name --all-containers

Answer

kubectl logs pod-name

Question 12

You have a pod that is in 'Pending' state. Which command would you run to get more information about why the pod cannot be scheduled?

Accepted Answer

kubectl describe pod . `kubectl describe pod ` provides detailed information about the pod, including events, conditions, and scheduler-related messages. For a pod stuck in 'Pending', the 'Conditions' and 'Events' sections will reveal scheduling failures such as insufficient resources, node selector mismatches, or taint toleration issues, which are not visible in logs or basic status output.

Answer

kubectl logs <pod-name>

Answer

kubectl get events

Answer

kubectl get pod <pod-name> -o wide

Question 13

A node in your cluster shows status 'NotReady'. You have SSH access to the node. What is the first command you should run to check the kubelet status?

Accepted Answer

systemctl status kubelet. When a node is NotReady, the first step is to check if the kubelet service is running, because the kubelet is the primary agent responsible for reporting node status to the control plane. Running `systemctl status kubelet` immediately shows whether the kubelet service is active, failed, or stopped, along with recent log snippets, making it the fastest diagnostic command.

Answer

systemctl status docker (or containerd)

Answer

cat /var/log/kubelet.log

Answer

journalctl -u kubelet

Question 14

You create a Deployment with the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"
          requests:
            cpu: "200m"
            memory: "128Mi"

After applying it, the pods are in 'CrashLoopBackOff'. You check logs and see 'Error: container process exited with error'. What is the MOST likely cause?

Accepted Answer

The application is crashing at startup due to a missing dependency. The error message 'container process exited with error' indicates the application itself is failing to start, not that it is being killed by Kubernetes. Since the container exits immediately after starting, the most likely cause is a missing dependency or misconfiguration in the application code, such as a missing environment variable, database connection, or file. Resource limits and probes affect running containers, not initial startup failures.

Answer

The container is being OOMKilled because memory limit is too low

Answer

The readiness probe is failing

Answer

The container has insufficient CPU resources

Question 15

You are troubleshooting a pod that cannot start. Running 'kubectl describe pod' shows the event: 'Failed to pull image "myregistry.io/myapp:1.0": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry.io/myapp:1.0 not found'. What is the MOST likely cause?

Accepted Answer

The image tag '1.0' does not exist in the registry. The error message 'manifest for myregistry.io/myapp:1.0 not found' indicates that the registry successfully received the pull request but could not locate the specific image tag '1.0'. This is a manifest lookup failure, not a connectivity or authentication issue. The most likely cause is that the tag '1.0' does not exist in the repository, either because it was never pushed or was removed.

Answer

The registry is unreachable due to network issues

Answer

The image registry requires authentication and the imagePullSecret is missing

Answer

The image has been deleted from the registry