Certified Kubernetes Administrator (CKA)

Question 1

You SSH into a control-plane node after users report that all kubectl commands fail with 'The connection to the server 10.0.1.5:6443 was refused - did you specify the right host or port?'. The node itself is up and other cluster nodes are Ready according to a monitoring dashboard cached minutes ago. The API server runs as a static pod managed by kubelet. Which command sequence will most directly help you diagnose why the API server is not responding?

Accepted Answer

Run 'sudo crictl ps -a' to check the kube-apiserver container state, then 'sudo crictl logs <container-id>' to inspect its output

Answer

Run 'kubectl logs -n kube-system kube-apiserver-<node>' to view the API server logs

Answer

Run 'kubectl describe pod -n kube-system kube-apiserver-<node>' to see recent events

Answer

Run 'systemctl restart kubelet' immediately to force the API server to restart

Question 2

A development team has a backend API running as a Deployment named `orders-api` in the `commerce` namespace. The API only needs to be reachable by other Pods inside the cluster (a frontend Deployment and a batch worker), and must NOT be exposed to any external network or node IP. The team asks you to create a Service that provides a stable virtual IP and DNS name for in-cluster access while minimizing the attack surface. Which Service type should you use?

Accepted Answer

ClusterIP — the default type, which allocates an internal virtual IP reachable only from within the cluster

Answer

NodePort — so the API is reachable on a static port across all node IPs for internal callers

Answer

LoadBalancer — to provision a cloud load balancer that other Pods connect to through its external IP

Answer

ExternalName — to map the Service to an external DNS name for internal Pods to resolve

Question 3

You created a ClusterRole named 'pod-reader' that grants get, list, and watch on pods. A developer's ServiceAccount 'ci-bot' in the 'dev' namespace needs to read pods only within the 'dev' namespace. Which binding correctly grants exactly this access using the existing ClusterRole?

Accepted Answer

Create a RoleBinding in the 'dev' namespace that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot'.

Answer

Create a ClusterRoleBinding that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot' in namespace 'dev'.

Answer

Create a RoleBinding in the 'default' namespace that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot'.

Answer

Convert the ClusterRole to a Role in the 'dev' namespace, then create a ClusterRoleBinding referencing it.

Question 4

After bootstrapping a new single-control-plane cluster with kubeadm, you notice all nodes report NotReady and every Pod (including CoreDNS) remains stuck in ContainerCreating. Running 'kubectl describe pod' on a CoreDNS Pod shows the event: 'Failed to create pod sandbox: ... failed to find plugin "..." in path [/opt/cni/bin] ... network plugin is not ready: cni config uninitialized'. What is the correct action to bring the cluster to a healthy state?

Accepted Answer

Deploy a CNI plugin (e.g., apply the Calico or Flannel manifest) so the Pod network add-on initializes the node network.

Answer

Restart the kubelet on all nodes with 'systemctl restart kubelet' to force sandbox recreation.

Answer

Re-run 'kubeadm init' with the '--pod-network-cidr' flag to reconfigure the cluster networking.

Answer

Increase the CoreDNS Deployment replica count and add tolerations for the node.kubernetes.io/not-ready taint.

Question 5

You maintain a Deployment for a payments service. The team stores 12 application settings in a ConfigMap named 'payments-config' and wants ALL of them injected as environment variables into the container without listing each key individually in the Pod spec. Which configuration achieves this?

Accepted Answer

Add an 'envFrom' entry with 'configMapRef' pointing to 'payments-config' in the container spec.

Answer

Add 12 separate 'env' entries, each with a 'valueFrom.configMapKeyRef' referencing 'payments-config'.

Answer

Mount 'payments-config' as a volume at '/etc/config' so the keys become environment variables automatically.

Answer

Add an 'envFrom' entry with 'secretRef' pointing to 'payments-config' in the container spec.

Question 6

You mount a ConfigMap named app-config into a Deployment's pod using a volume with a subPath reference (mountPath: /etc/app/config.yaml, subPath: config.yaml). After editing the ConfigMap with 'kubectl edit configmap app-config', you notice the running pods still see the old file contents even after several minutes. Other Deployments that mount the same ConfigMap as a full directory (no subPath) do receive the update automatically. What is the correct explanation and fix?

Accepted Answer

ConfigMap volumes mounted with subPath do not receive automatic updates; you must trigger a rollout (e.g. 'kubectl rollout restart deployment') to pick up the new values.

Answer

ConfigMap updates only propagate to pods that reference the ConfigMap via envFrom; convert the mount to environment variables to fix it.

Answer

The kubelet sync period must be lowered on every node before subPath mounts will update; edit the kubelet config and restart it.

Answer

ConfigMaps become immutable once mounted with subPath; you must delete and recreate the ConfigMap with a new name and update the volume reference.

Question 7

You create a Deployment named 'web' with replicas set to 3, but after several minutes 'kubectl get pods' shows no pods at all for that Deployment. 'kubectl get deployment web' shows DESIRED 3 but CURRENT and AVAILABLE both 0, and no ReplicaSet exists. The scheduler and kubelets are healthy, and other existing pods run fine. Which action is the most appropriate first step to diagnose the root cause?

Accepted Answer

Inspect the kube-controller-manager static pod status and logs on the control-plane node (e.g., crictl/kubectl logs or /var/log/pods and the manifest in /etc/kubernetes/manifests)

Answer

Restart kube-scheduler because it is failing to bind the pods to nodes

Answer

Increase the Deployment's replica count to force the API server to create the ReplicaSet

Answer

Delete and recreate the CoreDNS pods to restore controller reconciliation

Question 8

Pods in your cluster can resolve internal service names (e.g., my-svc.default.svc.cluster.local) but all attempts to resolve external domains (e.g., api.github.com) return NXDOMAIN. CoreDNS pods are Running with no restarts, and the CoreDNS Service has valid endpoints. You inspect the CoreDNS ConfigMap and find that the 'forward' plugin line was recently edited. What is the MOST likely cause and the correct fix?

Accepted Answer

The Corefile's 'forward . /etc/resolv.conf' directive was replaced or removed, so CoreDNS no longer forwards external queries upstream; restore the forward plugin pointing to a valid upstream resolver and reload.

Answer

The kube-dns Service ClusterIP changed; update every pod's /etc/resolv.conf nameserver entry to the new ClusterIP.

Answer

kube-proxy is not programming iptables rules for the DNS Service; restart the kube-proxy DaemonSet to fix external resolution.

Answer

The pods' dnsPolicy is set to None; change it to ClusterFirst so external names resolve.

Question 9

Users report that all applications in the cluster suddenly cannot resolve any DNS names, both internal (svc.cluster.local) and external. Pods themselves start fine and node-to-node connectivity works. Running 'kubectl get pods -n kube-system' shows no CoreDNS pods listed at all, and 'kubectl get deploy coredns -n kube-system' shows READY 0/0. Recent cluster maintenance was performed by another engineer. What is the most likely cause and the correct fix?

Accepted Answer

The CoreDNS Deployment was scaled to 0 replicas; scale it back up with 'kubectl scale deployment coredns -n kube-system --replicas=2'

Answer

The CoreDNS ConfigMap Corefile is corrupted; edit the ConfigMap to restore the default forward directive

Answer

kube-proxy is not programming iptables rules for the kube-dns Service; restart the kube-proxy DaemonSet

Answer

The nodes are under memory pressure and evicted CoreDNS pods; drain and reboot the affected nodes

Question 10

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?

Accepted Answer

One CoreDNS pod is overloaded due to node CPU pressure; add a podAntiAffinity rule so CoreDNS replicas spread across different nodes

Answer

The kube-dns Service selector is wrong; edit the selector to match the CoreDNS pod labels

Answer

CoreDNS is missing the Corefile forward plugin; edit the ConfigMap to add 'forward . /etc/resolv.conf'

Answer

The cluster CIDR overlaps the service CIDR; reinstall the cluster with non-overlapping ranges

Question 11

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?

Accepted Answer

The cluster's CNI network plugin is not installed or not functioning, leaving all nodes in NotReady state

Answer

The CoreDNS Corefile ConfigMap has an invalid forward directive causing the pods to fail scheduling

Answer

The kube-proxy DaemonSet is misconfigured and blocking DNS traffic on port 53

Answer

The CoreDNS Deployment replica count is set to 0 and needs to be scaled up

Question 12

Users report that pods across the cluster cannot resolve any DNS names, both internal and external. You check the CoreDNS deployment and see two CoreDNS pods in Running state with 0 restarts, and the pods' logs show no errors. From a test pod, 'nslookup kubernetes.default' times out. You run 'kubectl get svc -n kube-system' and notice there is no service named 'kube-dns'. What is the most likely cause of the DNS failure?

Accepted Answer

The kube-dns Service (ClusterIP fronting CoreDNS) was deleted, so pods have no reachable DNS endpoint even though CoreDNS pods are healthy

Answer

The CoreDNS Corefile is misconfigured and needs the 'forward' plugin re-added

Answer

The CoreDNS deployment must be renamed to kube-dns for kubelet to inject the correct nameserver

Answer

kube-proxy is down on all nodes, breaking iptables rules for every service

Question 13

A worker node's kubelet is running, but you suspect containers are failing at the runtime level. The node uses containerd as its CRI. You need to list all running containers and inspect a specific container's status directly at the runtime layer, bypassing the Kubernetes API. Which tool and configuration is the correct approach?

Accepted Answer

Use crictl with the runtime endpoint set to unix:///run/containerd/containerd.sock (e.g., via /etc/crictl.yaml or --runtime-endpoint) to run 'crictl ps' and 'crictl inspect'.

Answer

Use 'docker ps' and 'docker inspect' since Kubernetes always manages containers through the Docker daemon socket.

Answer

Run 'kubectl get pods -o wide' on the node, since kubectl communicates directly with the container runtime when run locally.

Answer

Use 'ctr --namespace k8s.io containers list' after setting the CRI endpoint to unix:///var/run/crio/crio.sock.

Question 14

You maintain a monitoring DaemonSet that must run a node-exporter pod on every node in the cluster, including the control-plane nodes. After deploying, you notice the DaemonSet pods are running on all worker nodes but not on the control-plane nodes. Describing a control-plane node shows the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. Which change to the DaemonSet pod spec will allow the pods to also be scheduled on the control-plane nodes without affecting scheduling elsewhere?

Accepted Answer

Add a toleration with key 'node-role.kubernetes.io/control-plane', operator 'Exists', and effect 'NoSchedule'

Answer

Add a nodeSelector matching the label 'node-role.kubernetes.io/control-plane: ""' to target the control-plane nodes

Answer

Add a required nodeAffinity rule selecting nodes with the 'node-role.kubernetes.io/control-plane' label

Answer

Remove the 'node-role.kubernetes.io/control-plane:NoSchedule' taint from every control-plane node with kubectl taint

Question 15

A developer creates a PVC named 'cache-data' that dynamically provisions a PV through a StorageClass whose reclaimPolicy is 'Delete'. After testing, the developer deletes the PVC to free resources. A day later, the team asks you to recover the data that was on that volume. Which statement correctly describes what happened and why?

Accepted Answer

The PV and its underlying storage asset were automatically deleted when the PVC was removed, so the data is unrecoverable from Kubernetes.

Answer

The PV entered the 'Released' state and retained the data, so you can simply re-bind a new PVC to recover it.

Answer

The PV remains 'Bound' until an administrator manually deletes it, so the data is still intact and available.

Answer

Deleting a PVC never affects the PV regardless of reclaim policy; only deleting the StorageClass triggers volume cleanup.

Question 16

You manage a Deployment named 'billing-api' whose pods mount a ConfigMap named 'billing-config' as environment variables using envFrom. After a colleague updates several values in 'billing-config' with 'kubectl edit configmap billing-config', users report the application is still using the old configuration values. The pods are all Running and healthy. What is the correct explanation and remediation?

Accepted Answer

Environment variables from a ConfigMap are injected only at pod startup and are not updated in-place; trigger a rolling restart with 'kubectl rollout restart deployment/billing-api' so new pods pick up the updated values.

Answer

ConfigMap changes propagate to environment variables automatically within about 60 seconds; the delay indicates the kubelet sync period must be lowered on each node.

Answer

The ConfigMap must be deleted and recreated with the same name for changes to take effect; editing in place is silently ignored by the API server.

Answer

You must scale the Deployment to zero replicas and back up so the ReplicaSet re-reads the ConfigMap; a rolling restart alone will not reload environment values.

Question 17

A Deployment named web has 10 replicas and uses the default RollingUpdate strategy with maxSurge: 0 and maxUnavailable: 25%. You trigger a rolling update with a new image. During the rollout, you observe that only some old pods are terminated at a time and no extra pods beyond 10 are ever created. What is the maximum number of pods that can be unavailable at any moment during this rollout?

Accepted Answer

2 pods (25% of 10, rounded down)

Answer

3 pods (25% of 10, rounded up)

Answer

5 pods (half of the replicas)

Answer

0 pods (maxSurge is 0, so no unavailability is allowed)

Question 18

You need to apply several changes to a running Deployment named 'web': update the container image, add a new environment variable, and increase the CPU request. You want to make all these edits without triggering a separate rolling update for each change, then roll them all out together as a single revision. Which sequence of commands achieves this?

Accepted Answer

kubectl rollout pause deployment/web, apply the image/env/resource changes, then kubectl rollout resume deployment/web

Answer

kubectl rollout undo deployment/web, apply all changes, then kubectl rollout restart deployment/web

Answer

kubectl scale deployment/web --replicas=0, apply all changes, then kubectl scale deployment/web --replicas=3

Answer

kubectl annotate deployment/web kubernetes.io/change-cause, apply all changes, then kubectl rollout status deployment/web

Question 19

A platform engineer manages a Deployment named 'payments-api'. After several rolling updates, they attempt to roll back two revisions using 'kubectl rollout undo deployment/payments-api --to-revision=3', but the command fails with an error stating that the revision was not found. Running 'kubectl rollout history deployment/payments-api' shows only the two most recent revisions. What is the most likely cause?

Accepted Answer

The Deployment's spec.revisionHistoryLimit is set to a low value, so older ReplicaSets (and their revisions) were garbage-collected.

Answer

Rollbacks to a specific revision are only supported for StatefulSets, not Deployments.

Answer

The Deployment uses the Recreate strategy, which does not retain any revision history.

Answer

The --to-revision flag must be set to 0 to roll back to any previous revision.

Question 20

You deployed a new version of an application by updating the image on a Deployment named 'payment-api'. After the rollout completes, users report errors and you confirm the new image is broken. You need to quickly revert 'payment-api' to the exact configuration it had before this latest update, while preserving the ability to inspect what changed. Which command accomplishes this most directly?

Accepted Answer

kubectl rollout undo deployment/payment-api

Answer

kubectl rollout restart deployment/payment-api

Answer

kubectl scale deployment/payment-api --replicas=0 && kubectl scale deployment/payment-api --replicas=3

Answer

kubectl delete deployment payment-api && kubectl apply -f payment-api.yaml

Question 21

A Deployment named 'payments' runs 10 replicas behind a Service that must never drop below full capacity during updates. The team also wants updates to proceed as fast as possible while guaranteeing that at no point are fewer than 10 Pods Ready. Which rollingUpdate strategy configuration satisfies these requirements?

Accepted Answer

maxUnavailable: 0 and maxSurge: 3

Answer

maxUnavailable: 3 and maxSurge: 0

Answer

maxUnavailable: 0 and maxSurge: 0

Answer

maxUnavailable: 25% and maxSurge: 25%

Question 22

You maintain a Deployment named `web` running 3 replicas. Marketing needs the app to handle a traffic spike, so you must temporarily scale it to 10 replicas without editing or reapplying the Deployment manifest and without triggering a new rollout of the pod template. Which command accomplishes this most directly?

Accepted Answer

kubectl scale deployment web --replicas=10

Answer

kubectl rollout restart deployment web --replicas=10

Answer

kubectl edit deployment web and change the image tag to force a new ReplicaSet with 10 pods

Answer

kubectl autoscale deployment web --min=10 --max=10

Question 23

A frontend Deployment reports intermittent 502 errors when calling the 'payments' Service. The Service selector matches the pods, and `kubectl get endpoints payments` shows several IPs listed. However, inspecting `kubectl get endpointslices -l kubernetes.io/service-name=payments -o yaml` reveals that some endpoints have `conditions.ready: false` while their pods show STATUS Running. What is the most likely cause of the endpoints being marked not ready?

Accepted Answer

The affected pods are failing their readiness probe, so kube-proxy excludes them from load balancing even though the containers are running.

Answer

The Service is missing a targetPort, so the EndpointSlice controller cannot populate ready addresses.

Answer

CoreDNS is returning stale records, causing the EndpointSlice to mark addresses as not ready.

Answer

The pods are on a node that is cordoned, which automatically sets their EndpointSlice condition to not ready.

Question 24

After a maintenance reboot of a single-node control plane, `kubectl get nodes` fails with 'The connection to the server 10.0.0.5:6443 was refused'. You SSH into the control-plane node. `systemctl status kubelet` shows kubelet is active and running. You need to find out why the kube-apiserver static pod is not serving requests. What is the BEST first step to diagnose the failure?

Accepted Answer

Inspect container runtime logs directly with `crictl ps -a` and `crictl logs <apiserver-container-id>` on the node

Answer

Run `kubectl logs -n kube-system kube-apiserver-<node>` to view the API server logs

Answer

Restart the kubelet with `systemctl restart kubelet` and wait for the API server to recover

Answer

Edit `/etc/kubernetes/manifests/kube-apiserver.yaml` to add a readiness probe and let kubelet recreate the pod

Question 25

Your production cluster uses an external etcd topology (etcd runs on dedicated nodes outside the control-plane machines). You need to take an etcd snapshot for backup from one of the etcd nodes using etcdctl v3. The etcd cluster is secured with client certificate authentication. Which command correctly produces the snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl snapshot save /backup/snap.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/server.crt --key=/etc/etcd/server.key

Answer

ETCDCTL_API=3 etcdctl snapshot save /backup/snap.db --endpoints=http://127.0.0.1:2379

Answer

kubectl exec -n kube-system etcd-master -- etcdctl snapshot save /backup/snap.db

Answer

ETCDCTL_API=2 etcdctl backup --data-dir=/var/lib/etcd --backup-dir=/backup

Question 26

You are responsible for etcd backups on a kubeadm-provisioned cluster where etcd runs as a stacked static pod on the control-plane node. Before a risky upgrade, you must take a manual snapshot of the etcd data from the control-plane host. The etcd server certificates are located in /etc/kubernetes/pki/etcd/. Which command correctly captures a consistent snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key

Answer

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db --endpoints=https://127.0.0.1:2379 --insecure-skip-tls-verify

Answer

kubectl get etcd -n kube-system -o yaml > /opt/etcd-backup.db

Answer

cp -r /var/lib/etcd /opt/etcd-backup.db while the etcd static pod is running

Question 27

You are administering a three-node stacked etcd control plane provisioned with kubeadm. After a network partition, users report intermittent API server errors. You want to inspect the etcd cluster membership and confirm each member's health directly from one control-plane node. Which command correctly queries etcd using the certificates that kubeadm places on the node?

Accepted Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key endpoint health --cluster

Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/ca.crt --cert=/etc/kubernetes/pki/apiserver.crt --key=/etc/kubernetes/pki/apiserver.key endpoint health --cluster

Answer

kubectl get --raw /healthz/etcd --server=https://127.0.0.1:2379

Answer

ETCDCTL_API=2 etcdctl cluster-health --endpoints=https://127.0.0.1:2379 --ca-file=/etc/kubernetes/pki/etcd/ca.crt

Question 28

You are deploying a Cassandra cluster as a StatefulSet named 'cassandra' in the 'data' namespace. The application requires each pod to be individually addressable via a stable DNS name so peers can discover each other directly, rather than routing through a single virtual IP that load-balances requests. Which Service configuration will produce per-pod DNS A records like 'cassandra-0.cassandra.data.svc.cluster.local'?

Accepted Answer

A Service with 'clusterIP: None' (headless) and a selector matching the StatefulSet pods

Answer

A standard ClusterIP Service with a selector matching the StatefulSet pods

Answer

A NodePort Service so each pod is exposed on a unique node port

Answer

A Service with 'clusterIP: None' but with no selector, relying on manual Endpoints

Question 29

You are deploying an application named 'billing' with Helm. The chart's values.yaml sets 'replicaCount: 2'. Your team maintains an environment file prod-values.yaml that sets 'replicaCount: 4'. During a hotfix rollout you run: helm install billing ./billing-chart -f prod-values.yaml --set replicaCount=6. After the release completes, how many replicas will the Deployment be configured with, and why?

Accepted Answer

6 replicas, because --set has the highest precedence and overrides both values.yaml and the -f file

Answer

4 replicas, because the -f file is applied last and overrides both the chart default and --set

Answer

2 replicas, because the chart's built-in values.yaml always takes priority over runtime overrides

Answer

The install fails because you cannot combine -f and --set in a single helm command

Question 30

A platform engineer reports that a Helm release named 'billing-api' was installed several days ago, but running `helm list` in their current shell shows no releases. Other teammates confirm the workload pods are running in the 'finance' namespace. Which command will correctly reveal the 'billing-api' release and its status?

Accepted Answer

helm list --all-namespaces

Answer

helm status billing-api --revision 0

Answer

helm repo list | grep billing-api

Answer

kubectl get releases -A

Question 31

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?

Accepted Answer

Set spec.behavior.scaleUp.policies with a type: Pods policy of value 4 and periodSeconds 60, and set selectPolicy accordingly

Answer

Set spec.behavior.scaleUp.stabilizationWindowSeconds to 60 so scaling waits before adding pods

Answer

Lower spec.maxReplicas to a smaller number so the HPA cannot scale beyond the database's capacity

Answer

Increase the target CPU utilization to 90% so the HPA reacts less frequently to spikes

Question 32

You are managing a Deployment named 'payments' with 3 replicas. The team wants each replica to run on a different node for high availability, but they notice all 3 pods have been scheduled onto the same node. Which addition to the pod template will BEST guarantee that the scheduler spreads the replicas across separate nodes?

Accepted Answer

A podAntiAffinity rule under requiredDuringSchedulingIgnoredDuringExecution matching the pod's own label with topologyKey 'kubernetes.io/hostname'

Answer

A nodeSelector matching the label 'kubernetes.io/hostname' on each pod

Answer

A podAffinity rule under requiredDuringSchedulingIgnoredDuringExecution matching the pod's own label with topologyKey 'kubernetes.io/hostname'

Answer

A NoSchedule taint on each node so only one pod lands per node

Question 33

An HPA managing a Deployment is configured with a target CPU utilization of 60%. During a short traffic spike the HPA scaled the workload from 3 to 10 replicas. After the spike ended, the pod count dropped back to 3 within about 15 seconds, but a follow-up spike a minute later caused rapid re-scaling, producing noticeable 'flapping' of replica counts. Which change to the HPA best prevents the aggressive scale-down and resulting oscillation?

Accepted Answer

Set spec.behavior.scaleDown.stabilizationWindowSeconds to a higher value (e.g., 300) so scale-down decisions consider the highest recommendation over that window

Answer

Lower the target CPU utilization to 40% so the HPA keeps more replicas running at all times

Answer

Set spec.behavior.scaleUp.stabilizationWindowSeconds to 300 to slow down how quickly new pods are added

Answer

Increase the Deployment's minReadySeconds so pods take longer to become Ready and reduce scaling churn

Question 34

You created a HorizontalPodAutoscaler targeting a Deployment named 'web' with 'kubectl autoscale deployment web --cpu-percent=50 --min=2 --max=10'. Metrics-server is installed and healthy, and 'kubectl top pods' returns CPU values for the web pods. However, running 'kubectl get hpa' shows the TARGETS column as '<unknown>/50%' and the HPA never scales beyond the minimum. What is the most likely cause?

Accepted Answer

The Deployment's pod template does not define a CPU resource request in its container spec.

Answer

The metrics-server is not exposing the custom metrics API required for CPU-based scaling.

Answer

The HPA minReplicas is set to 2, which prevents CPU utilization from being calculated.

Answer

The Deployment must use a readiness probe before the HPA can read CPU metrics.

Question 35

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?

Accepted Answer

Scale up to 6 replicas, because current average utilization is 90% and the target is 50%

Answer

Scale up to 4 replicas, because at least one pod exceeds the 50% target

Answer

Keep 3 replicas, because total CPU usage is below the sum of all requests

Answer

Scale down to 2 replicas, because average absolute CPU is under 200m

Question 36

A newly deployed pod in the 'payments' namespace remains in ImagePullBackOff. The image is hosted in a private registry at registry.internal.corp/payments/api:v2.3. Running 'kubectl describe pod' shows the event: 'Failed to pull image ... failed to authorize: 401 Unauthorized'. Other pods in the 'default' namespace pull from the same registry successfully. What is the most likely cause and correct fix?

Accepted Answer

The imagePullSecret exists only in the 'default' namespace; create the docker-registry secret in the 'payments' namespace and reference it in the pod's imagePullSecrets.

Answer

The image tag v2.3 does not exist in the registry; edit the deployment to use the 'latest' tag instead.

Answer

CoreDNS cannot resolve registry.internal.corp; restart the CoreDNS deployment to refresh its cache.

Answer

The node's container runtime is out of disk space; drain the node and prune unused images.

Question 37

You deploy an Ingress resource named 'web-ingress' in the 'shop' namespace to route external traffic to a ClusterIP Service. The Service has healthy endpoints and is reachable from inside the cluster. However, after several minutes, 'kubectl get ingress web-ingress -n shop' shows an empty ADDRESS field, and no external traffic reaches the application. What is the most likely cause?

Accepted Answer

No Ingress controller is running (or the Ingress does not reference a matching ingressClassName), so nothing is programming the routing rules or assigning an address.

Answer

The backing Service must be of type NodePort or LoadBalancer; an Ingress cannot forward traffic to a ClusterIP Service.

Answer

CoreDNS has not created a DNS record for the Ingress hostname, so the ADDRESS field remains empty until DNS propagates.

Answer

A default-deny NetworkPolicy in the 'shop' namespace is blocking the controller from populating the Ingress status.

Question 38

You deployed an NGINX Ingress controller in a bare-metal cluster. The controller Pods are Running, and an Ingress resource with a valid IngressClass points to a backend Service that has healthy endpoints. External clients on the corporate network can reach worker nodes directly by IP, but there is no cloud load balancer available. You want external HTTP traffic to reach the Ingress controller reliably through any node. Which configuration of the Ingress controller's own Service enables this in a bare-metal environment without a cloud provider?

Accepted Answer

Expose the Ingress controller with a Service of type NodePort (or a LoadBalancer backed by MetalLB), so external clients can reach the controller on a node IP and the request is then routed by the Ingress rules.

Answer

Expose the Ingress controller with a Service of type ClusterIP, since the Ingress resource already provides the external entry point independent of the controller's Service.

Answer

Delete the Ingress controller's Service entirely; the Ingress resource binds directly to node ports automatically once an IngressClass is set.

Answer

Create a headless Service (clusterIP: None) for the Ingress controller so DNS returns the Pod IPs directly to external clients.

Question 39

You deploy an Ingress resource that routes traffic for the host 'shop.example.com' to a Service named 'storefront'. The NGINX Ingress controller is running with a valid external IP and the 'storefront' Service has healthy endpoints. A user reports that requests to 'shop.example.com' work correctly, but requests sent to the controller's external IP using a host header of 'unknown.example.com' return a generic 404 from the ingress controller rather than a connection error. Your team wants requests that match no configured host/path rule to be served by a custom maintenance Service instead of the controller's built-in 404 page. What is the correct way to achieve this?

Accepted Answer

Add a 'defaultBackend' with the maintenance Service to the Ingress resource (or configure a default backend on the controller) so unmatched requests route there

Answer

Add a NetworkPolicy allowing ingress from 'unknown.example.com' so the request reaches the maintenance Service

Answer

Change the 'storefront' Service type from ClusterIP to NodePort so it can catch all unmatched host headers

Answer

Create a wildcard DNS record '*.example.com' pointing to the maintenance Service's ClusterIP

Question 40

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?

Accepted Answer

The Ingress was claimed by the NGINX controller because 'nginx' is the default IngressClass, so no ALB was provisioned for the public app.

Answer

An Ingress without an ingressClassName is ignored by every controller, so no controller processed the resource at all.

Answer

Both controllers processed the Ingress simultaneously, causing a routing conflict that dropped all external traffic.

Answer

The ALB controller processed the Ingress but requires a matching NetworkPolicy before it can expose the app externally.

Question 41

You deployed an NGINX Ingress controller and created an Ingress resource that maps host 'shop.example.com' with path '/api' (pathType: Prefix) to service 'api-svc:8080' and path '/' to service 'web-svc:80'. Requests to 'shop.example.com/' work correctly, but requests to 'shop.example.com/api/orders' return a 503 Service Temporarily Unavailable from NGINX. The web-svc endpoints are healthy. What is the MOST likely cause of the 503?

Accepted Answer

The 'api-svc' service has no ready endpoints (its selector matches no running/ready pods)

Answer

The Ingress resource is missing the correct ingressClassName, so the controller ignores the '/api' rule

Answer

pathType Prefix is invalid for multi-segment paths like '/api/orders' and must be changed to Exact

Answer

CoreDNS cannot resolve 'api-svc', so the Ingress controller returns 503

Question 42

You deploy an Ingress resource named 'shop-ingress' in the 'ecommerce' namespace to expose an HTTPS endpoint for shop.example.com. You reference a TLS secret named 'shop-tls' in the spec.tls section. The Ingress controller is running and healthy, and HTTP requests to the host route correctly, but HTTPS requests fail with a default self-signed certificate being served instead of your certificate. Running 'kubectl get secret shop-tls -n default' shows the secret exists there. What is the most likely cause and correct fix?

Accepted Answer

The TLS secret must reside in the same namespace as the Ingress resource; create/copy 'shop-tls' into the 'ecommerce' namespace and reference it there.

Answer

Ingress cannot serve TLS at all; you must terminate TLS at a LoadBalancer Service instead and remove the spec.tls block.

Answer

The secret type is wrong; change it to Opaque so the Ingress controller can read the certificate keys.

Answer

You must add the annotation 'nginx.ingress.kubernetes.io/ssl-passthrough: true' so the controller loads the secret from the default namespace.

Question 43

Users report that ClusterIP Services are unreachable from Pods running on worker node-3, while the same Services work fine from Pods on other nodes. You confirm the target Service has healthy Endpoints and CoreDNS resolves the Service name correctly on all nodes. Running 'kubectl get pods -n kube-system -o wide' shows the kube-proxy Pod on node-3 is in CrashLoopBackOff, while all other kube-proxy Pods are Running. What is the most likely reason Services fail specifically on node-3?

Accepted Answer

kube-proxy on node-3 is not programming the iptables/IPVS rules needed to redirect Service VIP traffic to backend Pods on that node

Answer

The Service selector no longer matches the backend Pods, so Endpoints are stale on node-3

Answer

CoreDNS is caching a stale ClusterIP that only affects node-3

Answer

The kubelet on node-3 is NotReady and cannot schedule the Service's backend Pods

Question 44

A ClusterIP Service named 'billing-api' correctly lists healthy pod endpoints when you run 'kubectl get endpoints billing-api'. However, requests from other pods to the Service's ClusterIP consistently time out, while connecting directly to the pod IPs works fine. On the affected worker node, you notice the kube-proxy pod has been in a running state but its logs show it failed to apply rules. Which action is the MOST likely to resolve the connectivity problem?

Accepted Answer

Restart the kube-proxy pod on the affected node so it can rebuild the iptables/IPVS rules that map the ClusterIP to backend endpoints

Answer

Recreate the Service object so a new ClusterIP is allocated and the endpoints are regenerated

Answer

Edit the Service and change its type to NodePort so traffic bypasses the ClusterIP routing layer

Answer

Add the pod IPs directly to a manually created Endpoints object to override the failed rules

Question 45

You deploy a new Deployment with 3 replicas, but all its Pods remain in the Pending state indefinitely. Existing Pods on the cluster continue running normally. Running 'kubectl get pods -o wide' shows the new Pods have no assigned node, and 'kubectl describe pod' shows no scheduling events at all (not even FailedScheduling). Node resources are plentiful and there are no taints. Which action is the most appropriate next step to diagnose the root cause?

Accepted Answer

Check the status and logs of the kube-scheduler static Pod in the kube-system namespace on the control-plane node

Answer

Delete and recreate the Deployment to force the scheduler to reassign the Pods

Answer

Add more worker nodes to the cluster to increase available scheduling capacity

Answer

Restart the kubelet service on all worker nodes to re-register them with the API server

Question 46

You maintain a kubeadm-provisioned cluster that has been running for just over a year. This morning, kubectl commands from the admin workstation begin failing with 'x509: certificate has expired or is not yet valid', and the API server static pod is repeatedly restarting. Investigation shows the cluster's PKI certificates were never rotated. Which single command should you run on the control-plane node to renew all kubeadm-managed certificates at once, after which you must restart the control-plane components?

Accepted Answer

kubeadm certs renew all

Answer

kubeadm init phase certs all --force

Answer

kubeadm alpha kubeconfig user --client-name admin

Answer

kubectl certificate approve $(kubectl get csr -o name)

Question 47

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?

Accepted Answer

Run 'kubeadm init phase upload-certs --upload-certs' on the first control-plane node to re-upload the certificates to a new kubeadm-certs Secret, then obtain the new certificate key and pass it to the join command with --certificate-key

Answer

Manually copy the /etc/kubernetes/pki directory from the first node to the second node and re-run the same join command, since kubeadm never distributes certificates over the network

Answer

Regenerate the bootstrap token with 'kubeadm token create' and pass it with --token; the certificate download uses the same token and no separate key is needed

Answer

Run 'kubeadm certs renew all' on the first node to refresh the certificates, which automatically re-populates the certificate cache used by joining control-plane nodes

Question 48

You are provisioning a new control-plane node with kubeadm. The node has both containerd (socket at unix:///run/containerd/containerd.sock) and CRI-O (socket at unix:///run/crio/crio.sock) installed. When you run 'kubeadm init', the command fails with an error indicating that multiple container runtime endpoints were detected and it cannot proceed. You want the cluster to use containerd. Which action correctly resolves this and initializes the cluster?

Accepted Answer

Run 'kubeadm init --cri-socket unix:///run/containerd/containerd.sock' to explicitly select the containerd runtime endpoint.

Answer

Set the KUBELET_EXTRA_ARGS environment variable to point to containerd and re-run 'kubeadm init' without additional flags.

Answer

Uninstall the kubelet, reinstall it, and run 'kubeadm init', which auto-detects the first runtime alphabetically.

Answer

Run 'kubeadm init --container-runtime=containerd' since kubeadm reads the runtime name directly.

Question 49

You are bootstrapping a new control-plane node with kubeadm on a server inside an air-gapped datacenter that has no internet access. Before running 'kubeadm init', you want to verify exactly which container images this specific kubeadm version requires so you can pre-load them into your local registry mirror. Which command lets you list those required images without contacting any external endpoint or initializing the cluster?

Accepted Answer

kubeadm config images list

Answer

kubeadm init --dry-run

Answer

kubeadm config images pull

Answer

crictl images list

Question 50

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?

Accepted Answer

The certificate key expired because uploaded certs in the kubeadm-certs Secret are deleted after two hours; run 'kubeadm init phase upload-certs --upload-certs' on an existing control-plane node to regenerate a new key, then join with that key.

Answer

The bootstrap token expired; regenerate a token with 'kubeadm token create' and reuse the original certificate key to join the node.

Answer

The CA certificate rotated automatically; renew all certificates with 'kubeadm certs renew all' on the first node before joining the third node.

Answer

Control-plane joins are limited to two nodes with stacked etcd; you must switch to an external etcd topology to add a third control-plane node.

Question 51

You are adding a new worker node to an existing kubeadm cluster. On the worker, you run 'kubeadm join 10.0.0.5:6443 --token abc123.def4567890ghijkl' without any other flags. The join fails immediately with an error stating that the cluster CA could not be validated because no --discovery-token-ca-cert-hash was provided and --discovery-token-unsafe-skip-ca-verification was not set. You want to join securely without disabling verification. Which action correctly obtains the value needed to complete the join?

Accepted Answer

On a control plane node, compute the CA cert hash with: openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der | openssl dgst -sha256 -hex, then pass it as --discovery-token-ca-cert-hash sha256:<hash>

Answer

Regenerate the bootstrap token with 'kubeadm token create' and rerun join; the new token embeds the CA hash automatically

Answer

Copy /etc/kubernetes/admin.conf to the worker and pass it via --kubeconfig so the join trusts the CA implicitly

Answer

Add --discovery-token-unsafe-skip-ca-verification to bypass the CA check, which is the standard secure way to join production nodes

Question 52

You are adding a new worker node to an existing kubeadm cluster. The control plane was set up two days ago. When you run the 'kubeadm join' command that was printed during 'kubeadm init', the node fails with an error indicating the bootstrap token is invalid or has expired. You need to generate a fresh join command from the control plane node. Which command produces a complete, ready-to-use join command including a new token and the discovery CA cert hash?

Accepted Answer

kubeadm token create --print-join-command

Answer

kubeadm token list

Answer

kubeadm init phase upload-certs --upload-certs

Answer

kubeadm token generate

Question 53

You administer a kubeadm-managed cluster where the control-plane node currently runs Kubernetes v1.29.4. You have already run 'apt-get install -y kubeadm=1.30.1-*' on the control-plane node and confirmed the kubeadm binary reports v1.30.1. Your goal is to upgrade the control-plane components (API server, controller manager, scheduler, etcd static pods) to v1.30.1. Which command should you run next to perform this upgrade on the first control-plane node?

Accepted Answer

kubeadm upgrade apply v1.30.1

Answer

kubeadm upgrade node

Answer

kubectl set image -n kube-system pod/kube-apiserver kube-apiserver=registry.k8s.io/kube-apiserver:v1.30.1

Answer

apt-get install -y kubelet=1.30.1-* && systemctl restart kubelet

Question 54

You are upgrading a kubeadm-managed cluster. The control plane has already been upgraded to v1.29.2. You now need to upgrade a worker node named 'worker-3'. You have run 'apt-get install kubeadm=1.29.2-*' and 'kubeadm upgrade node' on worker-3. What is the correct sequence of remaining steps to safely complete the worker upgrade, minimizing disruption to running workloads?

Accepted Answer

From a control-plane node run 'kubectl drain worker-3 --ignore-daemonsets', then on worker-3 upgrade kubelet and kubectl packages, run 'systemctl daemon-reload && systemctl restart kubelet', then run 'kubectl uncordon worker-3'.

Answer

On worker-3 upgrade kubelet and kubectl packages first, restart kubelet, then run 'kubectl drain worker-3' and finally 'kubectl uncordon worker-3'.

Answer

Run 'kubectl cordon worker-3', upgrade kubelet, restart kubelet, then re-run 'kubeadm upgrade apply v1.29.2' on worker-3 to finalize the node.

Answer

From a control-plane node run 'kubectl drain worker-3 --force --delete-emptydir-data', upgrade kubelet, restart kubelet — no uncordon is needed because drain automatically re-enables scheduling after upgrade.

Question 55

You manage a highly-available cluster that was bootstrapped with kubeadm using an external etcd topology (etcd runs on dedicated hosts, not as static pods managed by kubeadm). You are upgrading the first control-plane node from v1.29 to v1.30 and run 'kubeadm upgrade apply v1.30.0'. The command reports it will manage component upgrades. What is the correct expectation about etcd during this kubeadm upgrade?

Accepted Answer

kubeadm will not upgrade or manage etcd; you must upgrade the external etcd cluster manually and separately from the kubeadm workflow.

Answer

kubeadm automatically upgrades the external etcd members by connecting to each etcd host over SSH during 'upgrade apply'.

Answer

kubeadm regenerates the etcd static pod manifests on the control-plane node, which restarts the external etcd members.

Answer

kubeadm refuses to run 'upgrade apply' entirely until etcd is converted to a stacked topology.

Question 56

You are upgrading a worker node named worker-3 as part of a rolling kubeadm upgrade. Before running the kubelet package upgrade, you attempt to drain the node with `kubectl drain worker-3`, but the command fails with an error stating that the node contains DaemonSet-managed Pods and Pods with local storage (emptyDir volumes). You must safely evict the workloads and proceed with the upgrade without losing critical control-plane agents that run on every node. Which command correctly drains the node in this situation?

Accepted Answer

kubectl drain worker-3 --ignore-daemonsets --delete-emptydir-data

Answer

kubectl drain worker-3 --force --grace-period=0

Answer

kubectl cordon worker-3 --ignore-daemonsets

Answer

kubectl drain worker-3 --delete-daemonsets --keep-emptydir-data

Question 57

You upgraded the control plane of a kubeadm cluster to v1.30 successfully. When you run `kubectl get nodes`, the control-plane node shows v1.30 but three worker nodes still show v1.28 and remain Ready. New pods scheduled to the workers run fine, but you are preparing to upgrade the workers. Before draining and upgrading a worker, which command should you run ON that worker node to update the local kubeadm-managed component configuration and pull the correct kubelet config?

Accepted Answer

kubeadm upgrade node

Answer

kubeadm upgrade apply v1.30

Answer

kubeadm init phase kubelet-start

Answer

kubectl drain <node> --ignore-daemonsets && systemctl restart kubelet

Question 58

You are the administrator of a kubeadm-managed cluster currently running control-plane version v1.28.3. Before beginning an upgrade, you want to verify which target versions are available and confirm the component version state without making any changes to the cluster. Which command should you run on the first control-plane node?

Accepted Answer

kubeadm upgrade plan

Answer

kubeadm upgrade apply v1.29.0 --dry-run

Answer

kubeadm config images list

Answer

kubectl get nodes -o wide

Question 59

A pod using a PersistentVolumeClaim backed by a local PersistentVolume is stuck in Pending. The PVC is Bound, and cluster nodes have ample CPU and memory. Running 'kubectl describe pod' shows the event: '0/4 nodes are available: 4 node(s) had volume node affinity conflict.' What is the most likely cause?

Accepted Answer

The PersistentVolume defines nodeAffinity restricting it to a node whose labels do not match any schedulable node, so the scheduler cannot place the pod.

Answer

The StorageClass has volumeBindingMode set to Immediate, which forces the pod onto a random node.

Answer

The PVC requests more storage than the PersistentVolume provides, preventing scheduling.

Answer

The pod is missing a nodeSelector, so the scheduler defaults to rejecting all nodes.

Question 60

A pod named `web-stack` in the `frontend` namespace runs two containers: `nginx` and `log-agent`. Users report the web page returns HTTP 502 errors. You run `kubectl logs web-stack -n frontend` and receive the error: `Error from server (BadRequest): a container name must be specified for pod web-stack`. You need to view only the logs from the `nginx` container to diagnose the 502. Which command retrieves the correct container's logs?

Accepted Answer

kubectl logs web-stack -c nginx -n frontend

Answer

kubectl logs web-stack --all-containers -n frontend | grep nginx

Answer

kubectl logs web-stack -n frontend --container=log-agent

Answer

kubectl describe pod web-stack -n frontend | grep nginx

Question 61

A frontend web application deployed as a Deployment in the 'shop' namespace is responding slowly under load. The Deployment sets a CPU limit of 200m per container. You run 'kubectl top pods -n shop --containers' and observe the frontend container consistently reporting 200m CPU usage, matching its limit exactly, while node CPU is only 40% utilized overall. Pods are Running with no restarts. What is the most likely cause of the slow responses?

Accepted Answer

The container is being CPU throttled because it has hit its CPU limit; raising or removing the CPU limit would allow it to consume more CPU.

Answer

The node is out of allocatable CPU, so the scheduler cannot give the pod more capacity.

Answer

The metrics-server is reporting stale data and the real usage is much lower; the slowness is unrelated to CPU.

Answer

The pod is being OOMKilled repeatedly, which causes request latency spikes.

Question 62

A worker node suddenly shows NotReady. On the node, 'systemctl status kubelet' shows the service is active (running), but the kubelet logs repeatedly report: 'Unable to register node with API server' and 'x509: certificate has expired or is not yet valid'. The control plane and other nodes are healthy. What is the most likely root cause and appropriate first action?

Accepted Answer

The kubelet client certificate used to authenticate to the API server has expired; rotate/renew the kubelet's certificate (or approve its pending CSR) so it can re-authenticate.

Answer

CoreDNS is down on the node, so the kubelet cannot resolve the API server hostname; restart the CoreDNS Deployment.

Answer

The node has a NoSchedule taint that prevents registration; remove the taint with 'kubectl taint nodes'.

Answer

The container runtime (containerd) has crashed; restart containerd to restore node readiness.

Question 63

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?

Accepted Answer

The node's system clock is skewed (out of sync with the control plane), causing TLS validation to fail; sync time via NTP and restart the kubelet.

Answer

The kubelet client certificate was revoked by the API server; delete the node object and rejoin it with kubeadm.

Answer

The CA bundle on the node is corrupted; regenerate the cluster CA with kubeadm on all nodes.

Answer

The kubelet is using an expired bootstrap token; generate a new token and update /etc/kubernetes/bootstrap-kubelet.conf.

Question 64

Users report that pods on node worker-2 are being terminated and rescheduled unexpectedly. Running 'kubectl describe node worker-2' shows the condition 'DiskPressure  True' and events indicating 'The node had condition: [DiskPressure]'. Several pods on that node show status 'Evicted'. What is the most likely root cause and appropriate first action?

Accepted Answer

The kubelet has crossed its eviction threshold for available disk space; investigate and free space on the node's filesystem (e.g., prune unused images/logs) or expand the disk.

Answer

The pods have invalid resource requests; edit each pod spec to lower CPU and memory requests so they can be rescheduled.

Answer

kube-proxy is misconfigured on worker-2; restart kube-proxy to clear the DiskPressure condition.

Answer

The control-plane scheduler is failing; restart kube-scheduler to stop the evictions.

Exam domain	Exam weight	Practice
Troubleshooting	30%	Practice this topic
Cluster Architecture, Installation and Configuration	25%	Practice this topic
Services and Networking	20%	Practice this topic
Workloads and Scheduling	15%	Practice this topic
Storage	10%	Practice this topic

Certified Kubernetes Administrator (CKA) (CKA) practice exam & study guide

Start studying CKA

All CKA study resources

CKA exam domains

Sample CKA questions

Key CKA terms

CKA frequently asked questions

Troubleshooting (30%)

Cluster Architecture, Installation and Configuration (25%)

Services and Networking (20%)

Workloads and Scheduling (15%)

Storage (10%)