Certified Kubernetes Administrator (CKA) — All Questions

A Pod is stuck in the Pending state and never starts. Which command gives the most direct clue about why the scheduler cannot place it?

• a.kubectl logs <pod>
• b.kubectl exec -it <pod> -- sh
• c.kubectl top pod <pod>
• d.kubectl describe pod <pod>✓

kubectl describe pod shows the Events section, which typically reports scheduling failures such as insufficient CPU or memory, unsatisfied node selectors, or untolerated taints. Logs and exec require a running container, and top requires metrics and a scheduled Pod, so they cannot explain a Pending state.

A container repeatedly restarts with status CrashLoopBackOff. Which action most directly reveals why the previous container instance failed?

• a.kubectl get pods -o wide
• b.kubectl logs <pod> --previous✓
• c.kubectl scale the Deployment up
• d.kubectl cordon the node

CrashLoopBackOff means the container starts and exits repeatedly. kubectl logs --previous shows the logs from the last terminated instance, which usually contains the error that caused the crash. Scaling or cordoning does not surface the application-level failure reason.

kubectl commands begin failing with connection-refused errors to the API server on a kubeadm cluster. Which node-level check is most relevant first?

• a.Check the kubelet status and the API server static Pod and its container logs on the control-plane node✓
• b.Delete all worker nodes and re-add them
• c.Rotate every Secret in the cluster
• d.Increase the replica count of every Deployment

On a kubeadm control-plane node, the API server runs as a static Pod managed by the kubelet, so checking kubelet status (systemctl status kubelet) and the API server container logs (via crictl) is the correct first step. The other actions are disruptive and unrelated to why the API server is unreachable.

A worker node shows status NotReady. Which component running on that node is most directly responsible for reporting node health to the control plane?

• a.kube-proxy
• b.kube-scheduler
• c.kubelet✓
• d.etcd

The kubelet on each node registers the node and continually reports its status to the API server; a NotReady node usually means the kubelet is down or cannot reach the API server. kube-proxy handles Service networking, the scheduler runs on the control plane, and etcd is the datastore, not a node health reporter.

Before draining a node for maintenance so that Pods are safely rescheduled elsewhere, which command marks the node unschedulable and evicts its Pods respecting disruption budgets?

• a.kubectl taint node <node> maintenance=true:NoExecute
• b.kubectl drain <node> --ignore-daemonsets✓
• c.kubectl delete node <node>
• d.kubectl label node <node> unschedulable=true

kubectl drain cordons the node (marking it unschedulable) and gracefully evicts its Pods, honoring PodDisruptionBudgets, with --ignore-daemonsets to skip DaemonSet-managed Pods that cannot be evicted. Deleting the node removes it abruptly, and a plain label does not trigger eviction.