CKA Timed Practice Test 2 — 10 Questions

Question 1

A cluster administrator notices that nodes are not joining the cluster after a kubeadm init. The kubelet logs show: 'failed to run Kubelet: could not init service: open /var/lib/kubelet/config.yaml: permission denied'. What is the most likely cause?

10 minute time limit — choose an answer to begin.

Accepted Answer

The kubelet configuration file has incorrect ownership or permissions.. The error message 'open /var/lib/kubelet/config.yaml: permission denied' indicates that the kubelet process does not have the necessary read permissions to access its configuration file. This is typically caused by incorrect file ownership (e.g., owned by root instead of the kubelet user) or restrictive file permissions (e.g., 600 instead of 644). Since kubelet runs as a systemd service, it requires appropriate access to this file to initialize properly.

Answer

The kubelet is running out of disk space.

Answer

The kubelet is not able to reach the API server.

Answer

The kubelet binary is missing.

Question 2

An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?

Accepted Answer

Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.. When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Answer

Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

Answer

Use a different port for the API server by specifying --apiserver-bind-port.

Answer

Run kubeadm init with --force flag to override the errors.

Question 3

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 4

A Pod is in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate'. What is the most likely issue?

Accepted Answer

The Pod does not have tolerations for the taints on the nodes.. The event '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate' directly indicates that all nodes in the cluster have taints applied, and the Pod's spec does not include corresponding tolerations. Taints and tolerations work together to ensure that Pods are only scheduled onto nodes whose taints they tolerate; without matching tolerations, the scheduler will skip those nodes entirely, leaving the Pod in a Pending state.

Answer

The nodes do not have enough CPU or memory to run the Pod.

Answer

The nodes are not tainted, but the Pod has tolerations.

Answer

The scheduler is not running.

Question 5

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

Accepted Answer

Free up disk space and reduce memory usage on the affected nodes. The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints. The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Answer

Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints

Answer

Add tolerations for both taints to the pod spec

Answer

Delete the pod and recreate it with higher resource requests

Question 6

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 7

A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?

Accepted Answer

journalctl -u kubelet. On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.

Answer

cat /var/log/kubelet/kubelet.log

Answer

kubectl logs kubelet -n kube-system

Answer

systemctl restart kubelet

Question 8

A pod is in CrashLoopBackOff. The YAML for the initContainer is:

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:
  - name: init
    image: busybox
    command: ['sh', '-c', 'sleep 5 && exit 1']
  containers:
  - name: app
    image: nginx

What is the most likely reason for the CrashLoopBackOff?

Accepted Answer

The init container exits with non-zero exit code. Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Answer

The main container image nginx is not pulled successfully

Answer

The init container command is misspelled

Answer

The pod has insufficient memory

Question 9

You suspect the kubelet on a worker node has stopped. Which two commands should you run to confirm the kubelet status and check its logs?

Accepted Answer

systemctl status kubelet and journalctl -u kubelet. To check if the kubelet is running, use 'systemctl status kubelet'. To view logs, use 'journalctl -u kubelet'. The other options target the wrong service or are not applicable.

Answer

systemctl status docker and tail -f /var/log/syslog

Answer

kubectl get nodes and kubectl describe node <node>

Answer

systemctl restart kubelet and journalctl -u containerd

Question 10

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

Accepted Answer

Check kubelet logs with journalctl -u kubelet. Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Answer

Restart the kubelet with systemctl restart kubelet

Answer

Check the container runtime status

Answer

Reboot the node