cka exam questions Advanced Practice Exam: Hard Questions 2025

You manage a kubeadm-based cluster with stacked etcd on the control-plane node(s). After an unplanned reboot of the only control-plane node, the API server does not come up. `crictl ps -a` shows the etcd container repeatedly exiting. You must recover the cluster with the least risk of data loss and without reinitializing the cluster. Which action is the most appropriate first step?

A kubeadm cluster has two control-plane nodes and an external etcd cluster. One control-plane node shows `kubectl get nodes` as Ready, but scheduling fails intermittently with authentication errors to the API server when traffic hits that node via the load balancer. You suspect a certificate/key mismatch on that node. What is the best diagnostic action to confirm this hypothesis without rotating everything unnecessarily?

Your cluster uses the PodSecurity Admission controller in `enforce` mode with a policy that blocks privileged containers. A new CNI DaemonSet requires `hostNetwork: true` and privileged access to set up iptables rules. You must deploy it while keeping the policy enforced for all other workloads. What is the most secure and operationally correct approach?

A critical Deployment must only run on a subset of worker nodes with GPUs. GPU nodes are tainted with `gpu=true:NoSchedule`. Additionally, the app should prefer nodes in zone `zone-a` for latency, but must fail over to other zones if needed. Which scheduling configuration best meets the requirements?

A batch Job processes large input and must not be evicted during node memory pressure because reprocessing is expensive. However, the cluster is multi-tenant, and you cannot starve system daemons. What is the best configuration to maximize protection against eviction while respecting cluster stability?

A Service of type ClusterIP targets a set of Pods. From another Pod in the same namespace, DNS resolves the Service name correctly, but connections to the Service IP time out. Direct Pod IP connectivity works. Which is the most likely root cause?

You run an Ingress controller that relies on a Service of type LoadBalancer. The load balancer health checks pass, but clients get 502 errors intermittently. You observe that endpoints for the Ingress controller Service fluctuate even though Pods are Ready. What Kubernetes setting is most likely causing endpoint churn during rolling updates and leading to intermittent 502s?

A StatefulSet uses a StorageClass with `volumeBindingMode: WaitForFirstConsumer` on a multi-zone cluster. Pods remain Pending with events showing `0/6 nodes are available: pod has unbound immediate PersistentVolumeClaims`. The PVCs are created successfully but never bind. What is the most likely underlying issue?

After a node upgrade, Pods using a local PersistentVolume (local PV) fail to start on a different node when the original node is NotReady. The workload is a StatefulSet with `podManagementPolicy: OrderedReady`. You must restore service quickly without changing application code. What is the best explanation and corrective action?

A Deployment experiences random latency spikes. You suspect intermittent DNS resolution delays inside Pods. `kubectl exec` shows `/etc/resolv.conf` has a very large `ndots` value, and CoreDNS metrics show increased query load. You cannot change application code, but you can modify cluster/pod configuration. What is the best targeted fix to reduce unnecessary DNS queries while minimizing side effects?