Hard CKA practice questions

Users report intermittent DNS resolution failures inside the cluster. Pods sometimes resolve service names correctly and sometimes time out. You run 'kubectl get endpoints kube-dns -n kube-system' and see two endpoint IPs listed. Checking the CoreDNS deployment, you find both replicas are Running, but 'kubectl get pods -n kube-system -o wide' shows both CoreDNS pods scheduled on the same node, and that node is showing high CPU pressure. What is the MOST likely cause of the intermittent failures and the best remediation?

Users report that pods in your cluster cannot resolve service names, though pod-to-pod IP connectivity works. You run 'kubectl get pods -n kube-system' and see that both CoreDNS pods are stuck in 'Pending' status. Describing one pod shows the event: '0/3 nodes are available: 3 node(s) had untolerated taint {node.kubernetes.io/not-ready: }'. What is the most likely root cause you should investigate first?

You manage a payment-processing Deployment with an HPA targeting 60% CPU. During flash sales, the app receives sudden traffic spikes, but you observe that pods are added too aggressively — jumping from 4 to 40 replicas in a single scaling event, overwhelming the downstream database. You want the HPA to add at most 4 pods every 60 seconds regardless of how high the metric spikes. Which HPA configuration achieves this?

You configured a HorizontalPodAutoscaler for a Deployment with a target of 50% average CPU utilization. Each pod has a CPU request of 200m. The Deployment currently runs 3 pods, and the metrics-server reports the pods are consuming 180m, 160m, and 200m of CPU respectively. Based on the standard HPA scaling algorithm, what will the HPA do?

Your cluster runs two Ingress controllers: an NGINX controller (IngressClass 'nginx') for internal apps and an AWS ALB controller (IngressClass 'alb') for public apps. A developer creates an Ingress resource for a public app but omits both the 'spec.ingressClassName' field and the 'kubernetes.io/ingress.class' annotation. The 'nginx' IngressClass has the annotation 'ingressclass.kubernetes.io/is-default-class: "true"'. The public app is unreachable from the internet. What is the most likely cause?

You are bootstrapping a highly-available control plane with kubeadm. The first control-plane node was initialized several hours ago using 'kubeadm init' with a stacked etcd topology behind a load balancer. Now you want to join a second control-plane node using 'kubeadm join --control-plane'. The join command fails because it cannot download the required control-plane certificates from the cluster. What is the correct way to make those certificates available for the join?

You are bootstrapping a highly-available cluster with kubeadm using the stacked etcd topology. After running 'kubeadm init --upload-certs' on the first control-plane node and successfully joining a second control-plane node, you attempt to join a third control-plane node two hours later using the same '--certificate-key' value printed during init. The join fails with an error indicating the certificate key cannot be used to decrypt the certificates. What is the cause and correct remediation?

A worker node suddenly reports NotReady. The kubelet logs on that node show repeated errors: 'x509: certificate has expired or is not yet valid: current time ... is before ...'. The kubelet certificates were recently rotated and are valid for another year. Other nodes are healthy. What is the MOST likely root cause and appropriate fix?

A namespace 'payments' has no NetworkPolicies. You apply a single NetworkPolicy that selects all pods in the namespace, sets 'policyTypes: [Ingress]', and defines one ingress rule allowing traffic only from pods labeled 'app=frontend'. After applying it, the payments pods can no longer reach the external billing API on the internet, even though the ingress rule seems unrelated to outbound traffic. What is the actual cause of the broken outbound connectivity?

A team deploys the 'payments' application into the 'finance' namespace. Security requires that pods in 'finance' may only send traffic to other pods within the same namespace, while continuing to resolve DNS via CoreDNS in kube-system. All other egress must be blocked. The CNI plugin fully supports NetworkPolicy. Which NetworkPolicy configuration correctly enforces this?

A namespace called 'payments' currently has no NetworkPolicies. A team applies a first policy 'deny-all' with an empty podSelector (selecting all pods) and an empty ingress rule set (no rules). Later they apply a second policy 'allow-frontend' that selects pods with label 'app=api' and allows ingress from pods labeled 'app=frontend' on port 8080. After both policies exist, which statement correctly describes the resulting ingress behavior for a pod labeled 'app=api'?

A user reports that a newly created Pod in the 'batch' namespace has been stuck in the 'ContainerCreating' state for several minutes. Running 'kubectl describe pod' shows the events: 'Successfully assigned batch/job-runner to worker-3' followed by repeated warnings 'FailedCreatePodSandBox ... failed to set up sandbox container ... plugin type="bridge" failed (add): failed to allocate for range 0: no IP addresses available in range set'. Other Pods scheduled to worker-3 show similar errors. What is the most likely root cause?

A developer creates a PersistentVolumeClaim requesting 10Gi with accessMode ReadWriteOnce. The cluster has three manually-created PersistentVolumes with no storageClassName set: PV-a (5Gi, ReadWriteOnce, Available), PV-b (20Gi, ReadWriteMany, Available), and PV-c (15Gi, ReadWriteOnce, Available). No StorageClass and no dynamic provisioner exist. Which PV will the PVC bind to?