CKA Practice Test 13 — 15 Questions

Question 1

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 2

A node in the cluster is reporting NotReady. You run 'journalctl -u kubelet' and see repeated errors: 'failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats'. What is the most likely cause?

Accepted Answer

Cgroup driver mismatch between kubelet and container runtime. The error 'failed to get cgroup stats' indicates that the kubelet cannot read container cgroup statistics, which typically occurs when the cgroup driver used by kubelet (e.g., cgroupfs) does not match the driver used by the container runtime (e.g., systemd). This mismatch prevents the kubelet from properly monitoring container resource usage, causing the node to report NotReady.

Answer

Disk pressure on the node

Answer

The node is out of memory

Answer

The kubelet service is not running

Question 3

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 4

A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?

Accepted Answer

journalctl -u kubelet. `journalctl -u kubelet` retrieves the systemd journal logs specifically for the kubelet service, which is the standard way to access detailed, timestamped logs when the kubelet is running but malfunctioning. Since the kubelet is active (not stopped), its logs are captured by systemd and can be inspected without restarting the service, preserving the current state for troubleshooting.

Answer

kubectl describe node <node-name>

Answer

kubectl logs kubelet -n kube-system

Answer

systemctl restart kubelet

Question 5

You want to check the memory usage of nodes in your cluster. Which command should you use?

Accepted Answer

kubectl top nodes. `kubectl top nodes` directly queries the metrics-server (or Heapster) to retrieve real-time CPU and memory usage data for all nodes in the cluster. This command relies on the resource metrics pipeline, which collects metrics from kubelet's cAdvisor endpoint and exposes them via the metrics API, making it the standard way to check node-level memory utilization.

Answer

kubectl describe nodes

Answer

kubectl get nodes -o wide

Answer

kubectl get --raw /api/v1/nodes

Question 6

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?

Accepted Answer

nslookup. `nslookup` is a dedicated DNS lookup utility that queries DNS servers directly, making it the standard tool for testing DNS resolution from within a Pod. It sends DNS queries to the cluster's DNS service (e.g., CoreDNS or kube-dns) and returns the resolved IP addresses, allowing you to verify that DNS records for Services, Pods, or external hosts are correctly configured and reachable.

Answer

ping

Answer

tcpdump

Answer

curl

Question 7

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?

Accepted Answer

Taint toleration mismatch and pod anti-affinity conflicts. The error message explicitly states two distinct scheduling failures: '1 node(s) had taint {key1: value1}, that the pod didn't tolerate' and '3 node(s) didn't match pod anti-affinity rules.' These correspond directly to a taint toleration mismatch and pod anti-affinity conflicts. No other issues (node selector, resource constraints) are mentioned in the describe output.

Answer

Pod anti-affinity and node selector issues

Answer

Node selector and taint toleration mismatch

Answer

Resource constraints and taint toleration mismatch

Question 8

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

Accepted Answer

systemctl status kube-apiserver. The kube-apiserver is a systemd service on control plane nodes managed by systemd. The `systemctl status kube-apiserver` command queries systemd for the current state, including active status, PID, memory usage, and recent log entries, which is the standard method for checking a systemd-managed service.

Answer

kubectl get apiservice

Answer

service kube-apiserver status

Answer

journalctl -u kubelet

Question 9

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 10

A node in your cluster is reporting 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'Active: inactive (dead)'. Which command should you run FIRST to attempt to resolve this?

Accepted Answer

systemctl start kubelet. The kubelet service is the primary Kubernetes agent on each node, and when it is 'inactive (dead)', the node cannot report its status to the control plane. The first step to restore the node is to start the kubelet service using 'systemctl start kubelet', which will attempt to bring the kubelet process back online and allow it to reconnect to the API server.

Answer

journalctl -u kubelet

Answer

systemctl status kubelet

Answer

reboot

Question 11

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?

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 12

A pod is in 'ImagePullBackOff' state. You run 'kubectl describe pod' and see the event: 'Failed to pull image "nginx:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on 8.8.8.8:53: no such host'. What is the MOST likely cause?

Accepted Answer

DNS resolution is failing on the node. The error message 'no such host' when trying to resolve 'registry-1.docker.io' on DNS server 8.8.8.8:53 indicates that the node's DNS resolution is failing. Kubernetes nodes rely on DNS to resolve container registry hostnames; if the node cannot resolve the registry's domain, the container runtime cannot pull the image, resulting in ImagePullBackOff. This is a node-level DNS issue, not a container runtime or image tag problem.

Answer

The container runtime is not installed

Answer

The image tag is incorrect

Answer

The registry requires authentication

Question 13

A pod is in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 PersistentVolumeClaim is not bound'. What is the most likely cause?

Accepted Answer

The PersistentVolumeClaim referenced by the pod does not exist or is not bound. The event '0/3 nodes are available: 3 PersistentVolumeClaim is not bound' indicates that the pod's PersistentVolumeClaim (PVC) is not in a 'Bound' state. This means the PVC either does not exist in the namespace or has not been successfully bound to a PersistentVolume (PV). The scheduler cannot schedule the pod because the PVC requirement is unsatisfied, which is a prerequisite for pod startup.

Answer

The storage class used by the PVC does not match any PV

Answer

The scheduler is not configured to handle persistent volumes

Answer

The nodes do not have enough CPU or memory

Question 14

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 15

You run 'kubectl get pods' and see a pod named 'db' in CrashLoopBackOff. 'kubectl logs db' shows nothing. 'kubectl logs db --previous' shows 'Error: database connection failed'. What is the most likely cause?

Accepted Answer

The environment variable for database host is incorrect. The 'kubectl logs db --previous' output shows 'Error: database connection failed', which indicates the application inside the container is failing to connect to a database. Since the current logs are empty (the container restarted), the previous logs reveal the root cause: a configuration issue, most likely an incorrect database host environment variable. This is a classic application-level startup failure, not a resource or probe issue.

Answer

The node is out of memory

Answer

The pod's liveness probe is misconfigured

Answer

The container image is missing