CKA Hard Questions — 25 Difficult 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?

Choose an answer to begin — your selection is scored in the full session.

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

Which THREE are valid methods to restore an etcd cluster from a snapshot? (Select 3)

Accepted Answer

Restore snapshot on a new node and add it as a member, then remove old. It describes the standard procedure for replacing a failed etcd member using a snapshot: you restore the snapshot on a new node (using `etcdctl snapshot restore`), start the new etcd instance, add it as a member to the existing cluster, and then remove the old, failed member. This ensures the new node joins with the correct data and the cluster quorum is maintained.

Answer

kubeadm reset and re-init

Answer

kubectl apply -f snapshot.yaml

Question 3

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

Accepted Answer

Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod. The event message explicitly states that 1 node has a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate, and 3 nodes have insufficient CPU. This means the pod's CPU request cannot be satisfied on three nodes, and the remaining node is tainted, leaving no schedulable node. Option A correctly identifies this combination of issues.

Answer

The pod has a resource request that exceeds available CPU on all nodes

Answer

The pod does not tolerate any taints, and all nodes have taints

Answer

The cluster has only one node with sufficient CPU, but it is cordoned

Question 4

You have a cluster with multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0 using kubeadm. What is the correct sequence of steps?

Accepted Answer

Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.. The official kubeadm upgrade workflow requires upgrading kubeadm first on the control plane node, then using `kubeadm upgrade apply` to upgrade control plane components, and finally draining and upgrading each worker node by updating kubelet and kubectl. This sequence ensures the cluster's management plane is updated before worker nodes, maintaining control plane stability and API compatibility during the rolling upgrade.

Answer

Upgrade kubeadm on the control plane node, then upgrade kubelet and kubectl on worker nodes, then upgrade kubelet and kubectl on control plane node.

Answer

Drain all nodes, upgrade kubelet and kubectl on all nodes, then upgrade kubeadm on the control plane node.

Answer

Upgrade kubelet and kubectl on all nodes first, then upgrade kubeadm on the control plane node.

Question 5

You run 'kubectl top nodes' and get an error: 'error: metrics not available yet'. Which of the following is the MOST likely cause?

Accepted Answer

The Metrics Server is not deployed in the cluster. The 'error: Metrics API not available' error indicates that the Metrics API service (v1beta1.metrics.k8s.io) is not registered with the API server, which most commonly happens when the Metrics Server is not deployed in the cluster. Option C is correct. Option A would result in a connection refused error. Option B and D would not prevent the Metrics API itself from being available, though they might lead to missing metrics for specific nodes.

Answer

The Kubernetes API server is down

Answer

The kubelet is not running on all nodes

Answer

One or more nodes are in NotReady state

Question 6

A Job named 'pi' runs a container that computes pi to 2000 digits. The Job's spec has completions=3 and parallelism=2. After some time, you observe that two pods completed successfully, and the third pod is still running. What is the expected behavior when the third pod completes?

Accepted Answer

The Job will be marked as Complete. A Job with `completions=3` and `parallelism=2` is considered complete when the required number of successful pod completions (3) is reached. Since two pods have already completed and the third is still running, once it finishes successfully, the total successful completions will equal the `completions` value, and the Job controller will mark the Job as Complete. The Job does not require all pods to run concurrently or finish simultaneously.

Answer

The Job will restart the completed pods

Answer

The Job will continue to run new pods indefinitely

Answer

The Job will be marked as Failed because parallelism is not fully utilized

Question 7

Which TWO of the following could cause a Node to be in NotReady state?

Accepted Answer

The kubelet process has stopped. A Node is NotReady if the kubelet is not reporting healthy. Common causes include kubelet failure and network plugin issues.

Answer

The node has a taint that prevents scheduling

Answer

The node has insufficient disk space

Answer

The node's IP address has changed

Question 8

A Pod is stuck in Pending state. Running 'kubectl describe pod' shows '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 2 node(s) had taint {node-role.kubernetes.io/master: }'. The Pod does not have tolerations. What is the most likely cause?

Accepted Answer

The Pod does not have tolerations for the control-plane or master taints.. The Pod is stuck in Pending state because it does not have tolerations for the taints present on the nodes. The error message explicitly states that 1 node has the control-plane taint and 2 nodes have the master taint. By default, Pods without matching tolerations cannot be scheduled onto tainted nodes. Since all available nodes are tainted, the scheduler has no eligible node to place the Pod, leaving it in Pending.

Answer

The scheduler is not running.

Answer

The Pod requests more CPU than any node can provide.

Answer

The Pod has a node selector that doesn't match any node.

Question 9

Which THREE of the following are valid steps to troubleshoot a Node in NotReady state? (Choose three)

Accepted Answer

Run 'systemctl status kubelet' on the node. The kubelet is the primary node agent that registers the node with the cluster and reports its status. If the kubelet service is not running or has failed, the node will report a NotReady state. Running 'systemctl status kubelet' on the node directly checks the service's current state, recent activity, and any error messages from systemd.

Answer

Restart the kube-apiserver on the control plane

Answer

Run 'kubectl delete node <node-name>' to re-register

Question 10

A kubeadm cluster is being upgraded from v1.28 to v1.29. You have upgraded the control plane components on the first master node. What is the NEXT step according to the recommended upgrade procedure?

Accepted Answer

Upgrade the remaining control plane nodes. After upgrading the control plane components on the first master node in a kubeadm cluster, the next step is to upgrade the remaining control plane nodes. The kubeadm upgrade procedure requires upgrading all control plane nodes before any worker nodes, because the control plane must be fully upgraded to v1.29 to ensure API server compatibility and etcd cluster consistency. Skipping to worker nodes or draining the first node prematurely would violate the upgrade order specified in the official Kubernetes upgrade documentation.

Answer

Drain the first node

Answer

Upgrade the worker nodes

Answer

Run kubeadm upgrade plan

Question 11

Which TWO of the following are valid ways to isolate a set of pods from all ingress traffic except from monitoring pods?

Accepted Answer

Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, ingress: [ { from: [ { podSelector: { matchLabels: { role: monitoring } } } ] } ]. It uses a NetworkPolicy with a `podSelector` targeting the protected pods and an `ingress` rule that explicitly allows traffic only from pods with the label `role: monitoring`. This isolates the target pods from all other ingress traffic, as Kubernetes NetworkPolicy defaults to denying ingress when any ingress rule is defined, and only the specified source pods are permitted.

Answer

Apply a NetworkPolicy with ingress rule allowing from a specific pod only

Answer

Apply a NetworkPolicy with empty podSelector and ingress rule allowing all

Answer

Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp } and ingress rule with namespaceSelector: { matchLabels: { name: monitoring } }

Question 12

You have configured a ServiceAccount with an associated image pull secret. The Pod referencing this ServiceAccount still fails with ImagePullBackOff due to authentication errors. What is the most likely misconfiguration?

Accepted Answer

The secret is not in the same namespace as the Pod.. Secrets in Kubernetes are namespace-scoped. When you configure `imagePullSecrets` on a ServiceAccount, the ServiceAccount admission controller automatically injects these secrets into any Pod referencing that ServiceAccount. However, because Secrets are namespace-scoped, the secret must exist in the same namespace as the ServiceAccount and the Pod. If the secret was created in a different namespace, the Pod will fail to pull the image with an authentication error (ImagePullBackOff).

Answer

The secret type is wrong; it should be kubernetes.io/dockercfg.

Answer

The ServiceAccount does not have the imagePullSecrets field configured.

Answer

The Pod spec must set the secret in imagePullSecrets directly.

Question 13

Refer to the exhibit. A new worker node (node2) has been added to the cluster. It shows NotReady status, and a CertificateSigningRequest (CSR) is pending. What step must the cluster administrator take to make node2 ready?

Accepted Answer

Approve the pending CSR using 'kubectl certificate approve csr-node2'.. When a new node joins, the kubelet creates a CSR for its client certificate. The CSR must be approved by an administrator (or automatically via a controller). Until approved, the node cannot authenticate and remains NotReady.

Answer

Run 'kubeadm join' again with the correct token.

Answer

Add the node's IP to the API server's TLS certificate.

Answer

Restart the kubelet on node2.

Question 14

You are a platform engineer managing a multi-tenant Kubernetes cluster. A development team deploys a StatefulSet for a database with the following configuration: 3 replicas, headless service 'db-headless' for DNS-based discovery, and a regular ClusterIP service 'db' for read/write operations. The cluster uses Calico CNI with default NetworkPolicy enforcement. The team reports that applications in the same namespace can connect to the ClusterIP service but cannot connect to individual pod DNS names (e.g., db-0.db-headless.namespace.svc.cluster.local). You verify that the DNS resolution works (nslookup returns the pod IP). However, a curl to the pod IP on the database port (5432) times out. You check the endpoints and they are correct. Which action should you take to resolve the connectivity issue?

Accepted Answer

Create a NetworkPolicy that allows ingress traffic from all pods in the namespace to the database pods on port 5432.. To make the scenario technically accurate, the stem should state that both ClusterIP and direct Pod IP connections fail (or simply that connections to the database fail), while DNS resolution still succeeds (since CoreDNS is typically permitted). This correctly points to a NetworkPolicy blocking traffic to the database pods.

Answer

Modify the CoreDNS configuration to use a different DNS policy.

Answer

Remove the headless service and use a regular ClusterIP service for pod discovery.

Answer

Change the ClusterIP service 'db' to NodePort to expose the database on each node.

Question 15

A pod's YAML specifies 'restartPolicy: Never' and the container exits with code 0. What state will the pod be in?

Accepted Answer

Succeeded. When a pod's restartPolicy is set to 'Never' and its container exits with code 0 (indicating a successful termination), the pod transitions to the 'Succeeded' phase. This is because Kubernetes treats a zero exit code as a successful completion, and with restartPolicy: Never, no restart is attempted, leaving the pod in a terminal Succeeded state.

Answer

Completed

Answer

Failed

Answer

Running

Question 16

An administrator runs 'kubeadm certs check-expiration' and sees that the kubelet client certificate expires in 7 days. What is the correct way to renew it?

Accepted Answer

Run 'kubeadm certs renew kubelet-client'. The `kubeadm certs renew kubelet-client` command is the correct way to renew only the kubelet client certificate without affecting other certificates. This targeted renewal is appropriate when only the kubelet client certificate is expiring, as it avoids unnecessary disruption to other components. The command regenerates the certificate using the existing CA, and the kubelet will automatically reload it.

Answer

Run 'kubeadm init phase certs kubelet-client'

Answer

Renew all certificates using 'kubeadm certs renew all'

Answer

Delete the old certificate and restart kubelet

Question 17

Which TWO statements about EndpointSlices are correct?

Accepted Answer

EndpointSlices improve scalability compared to Endpoints.. EndpointSlices are designed to overcome the scalability limitations of the older Endpoints API. A single Endpoint object stores all endpoints for a Service, which can become a large, monolithic object that causes performance issues in the control plane and etcd when a Service has many pods. EndpointSlices break this into smaller, manageable slices, each containing up to 100 endpoints by default, reducing the impact of updates and improving overall cluster scalability.

Answer

EndpointSlices are created manually by the user.

Answer

Each EndpointSlice can contain only one endpoint.

Answer

EndpointSlices are only used with ClusterIP services.

Question 18

Which THREE of the following are steps required when restoring an etcd cluster from a snapshot?

Accepted Answer

Run 'etcdctl snapshot restore' specifying a new data directory. 'etcdctl snapshot restore' is the command used to restore an etcd cluster from a snapshot. You must specify a new data directory (e.g., --data-dir=/var/lib/etcd-restored) to avoid overwriting existing data and to allow the restored snapshot to be used as a fresh data source for the etcd member.

Answer

Restore the snapshot on every etcd member in the cluster

Answer

Run 'kubeadm init' to reinitialize the control plane

Question 19

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules'. What is the most likely cause?

Accepted Answer

The pod has a requiredDuringSchedulingIgnoredDuringExecution anti-affinity rule that is too restrictive. The event '0/3 nodes are available: 3 node(s) didn't match pod anti-affinity rules' directly indicates that the pod's scheduling is being blocked by anti-affinity constraints. Option B is correct because a `requiredDuringSchedulingIgnoredDuringExecution` anti-affinity rule is a hard constraint that must be satisfied at scheduling time; if no node meets the rule (e.g., the rule prevents co-location with other pods that are present on all nodes), the pod remains Pending.

Answer

The nodes have insufficient resources

Answer

The pod has a taint tolerance issue

Answer

The nodes are all cordoned

Question 20

A cluster has a NetworkPolicy that denies all ingress traffic by default. An administrator wants to allow TCP traffic on port 8080 from pods with label 'app: web' in the same namespace. Which NetworkPolicy egress rule is needed?

Accepted Answer

An ingress rule with podSelector matching 'app: web' and ports.. To allow incoming traffic to a pod that has a default-deny ingress policy, an ingress rule must be defined on that pod's NetworkPolicy. The rule needs to specify a podSelector matching the source pods ('app: web') and the destination port (8080).

Answer

An ingress rule with namespaceSelector matching the same namespace.

Answer

An egress rule with namespaceSelector and podSelector.

Answer

An egress rule with podSelector matching 'app: web' and ports.