Knowledge + Practice

Certified Kubernetes Administrator CKA (CKA) — Questions 376–450

1005 questions total · 14pages · All types, answers revealed

Take a mock exam Exam hub

Page 6 of 14

376

MCQhard

An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?

A.Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.

B.Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.

C.Use a different port for the API server by specifying --apiserver-bind-port.

D.Run kubeadm init with --force flag to override the errors.

AnswerA

kubeadm reset removes the cluster state and configuration.

Why this answer

When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Exam trap

The trap here is that candidates may think a simple file deletion or port change is sufficient, but the CKA exam expects you to know that `kubeadm reset` is the only safe, comprehensive cleanup method for re-initializing a cluster on the same node.

How to eliminate wrong answers

Option B is wrong because manually deleting only the kube-apiserver.yaml manifest and killing its process does not remove other critical residual files (e.g., etcd data, kubelet config, CA certificates, or other static pod manifests), leaving the node in an inconsistent state that will still cause `kubeadm init` to fail. Option C is wrong because changing the API server port with `--apiserver-bind-port` does not address the root cause of leftover cluster state; it merely avoids the port conflict temporarily while other conflicts (e.g., existing etcd data, stale certificates) remain. Option D is wrong because `kubeadm init` does not support a `--force` flag; attempting to override errors without proper cleanup can lead to a corrupted or non-functional cluster.

Full explanation →

377

MCQeasy

What is the function of the 'kube-scheduler' in Kubernetes?

A.It runs the container runtime

B.It manages network rules for services

C.It stores cluster state

D.It assigns pods to nodes

AnswerD

The scheduler watches for unscheduled pods and selects a suitable node for them.

Why this answer

The kube-scheduler is a core control plane component that watches for newly created Pods with no assigned node and selects an optimal node for them to run on. It makes scheduling decisions based on resource requirements, constraints like affinity/anti-affinity rules, data locality, and other policies. Option D is correct because the scheduler's primary function is to assign pods to nodes.

Exam trap

The trap here is that candidates often confuse the kube-scheduler with kubelet or kube-proxy, but the scheduler's sole role is node selection for pods, not running containers or managing network rules.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) runs containers, not the kube-scheduler. Option B is wrong because managing network rules for services is the job of the kube-proxy component, which implements Service networking via iptables/IPVS. Option C is wrong because storing cluster state is the responsibility of etcd, a distributed key-value store; the kube-scheduler does not persist any state.

Full explanation →

378

MCQmedium

You need to schedule a pod to a specific node named 'worker-2' for testing purposes. Which field should you set in the pod spec?

A.schedulerName

B.affinity

C.nodeSelector

D.nodeName

AnswerD

Setting nodeName to 'worker-2' will schedule the pod directly to that node.

Why this answer

The `nodeName` field in the PodSpec directly assigns the pod to a specific node by name, bypassing the scheduler entirely. Setting `nodeName: worker-2` forces the kubelet on that node to run the pod, making it the correct choice for pinning a pod to a specific node for testing.

Exam trap

CNCF often tests the distinction between `nodeSelector` (label-based scheduling) and `nodeName` (direct assignment), leading candidates to choose `nodeSelector` when the question explicitly requires a specific node name.

How to eliminate wrong answers

Option A is wrong because `schedulerName` specifies a custom scheduler to use for scheduling decisions, not a direct node assignment; it still relies on scheduling logic. Option B is wrong because `affinity` (node affinity or pod affinity) provides soft or hard constraints for scheduling preferences but does not guarantee placement on a specific node like `nodeName` does. Option C is wrong because `nodeSelector` matches labels on nodes to schedule the pod to any node with those labels, not a single named node.

Full explanation →

379

MCQhard

You are upgrading a Kubernetes cluster from version 1.28 to 1.29. What is the correct order of steps?

A.Upgrade all worker nodes first, then upgrade control plane nodes.

B.Upgrade control plane nodes first, then upgrade worker nodes without draining them.

C.Upgrade control plane nodes first, then drain each worker node before upgrading it.

D.Upgrade all nodes simultaneously.

AnswerC

This follows the recommended upgrade procedure: control plane first, then drain and upgrade worker nodes.

Why this answer

Option C is correct because the Kubernetes upgrade process requires upgrading the control plane nodes first to ensure the cluster's management layer is running the new version before worker nodes are upgraded. Draining each worker node before upgrading it is essential to safely evict pods and maintain application availability, as the kubelet on the node must be stopped during the upgrade and the node must be cordoned to prevent new pods from being scheduled.

Exam trap

The trap here is that candidates may think upgrading worker nodes without draining is acceptable if they use a rolling update strategy, but the CKA exam specifically tests the requirement to drain nodes before upgrading to avoid pod disruption.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before control plane nodes violates the Kubernetes upgrade order; the control plane must be upgraded first to avoid version skew incompatibilities. Option B is wrong because upgrading worker nodes without draining them first can cause pod disruptions and data loss, as the kubelet is stopped during the upgrade and pods are not gracefully terminated. Option D is wrong because upgrading all nodes simultaneously is not supported; Kubernetes requires a sequential upgrade to maintain cluster stability and prevent version mismatch between components.

Full explanation →

380

Multi-Selecthard

Which THREE of the following are valid ways to provide storage to a pod in Kubernetes? (Select three.)

Select 3 answers

A.hostPath

B.emptyDir

C.secret

D.PersistentVolumeClaim

E.configMap

AnswersA, B, D

hostPath mounts a file or directory from the host node's filesystem.

Why this answer

PersistentVolumeClaim, emptyDir, and hostPath are all valid volume sources. configMap and secret are also valid, but they are for configuration data, not general storage. However, the question asks for 'storage' broadly. Typically, these are considered storage options.

But to align with common exam topics, I'll include configMap as a valid volume type. Actually, configMap is a volume type that provides configuration data, not general storage. I'll adjust: correct answers are PVC, emptyDir, hostPath.

ConfigMap and secret are also volume types, but they are for specific purposes. I'll stick with PVC, emptyDir, hostPath as the most direct storage options.

Full explanation →

381

MCQmedium

A pod remains in Pending state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the solution?

A.Increase the pod's CPU request

B.Add a toleration to the pod spec

C.Remove the pod and recreate it

D.Delete the taint from the node

AnswerB

Tolerations allow the pod to schedule on tainted nodes.

Why this answer

The pod cannot tolerate the master taint. Remove the taint or add tolerations.

Full explanation →

382

MCQeasy

Which reclaim policy will cause the underlying storage to be deleted when the associated PersistentVolume is released from a PersistentVolumeClaim?

A.Delete

B.Recycle

C.Retain

D.Archive

AnswerA

Delete removes the PV and the associated storage asset from the external infrastructure.

Why this answer

The Delete reclaim policy causes the PV and its associated storage asset to be deleted upon release. Retain keeps the data, Recycle (deprecated) used to scrub and re-use.

Full explanation →

383

MCQhard

You have a NodePort service. Which kube-proxy mode allows for better performance and more sophisticated load balancing algorithms like 'least connection'?

A.ipvs

B.iptables

C.kernelnet

D.userspace

AnswerA

Correct. IPVS supports multiple scheduling algorithms including least connection.

Why this answer

Option C is correct. IPVS mode supports multiple scheduling algorithms (rr, lc, dh, sh, sed, nq). Iptables mode uses random selection.

Userspace mode is deprecated. KernelNet is not a valid kube-proxy mode.

Full explanation →

384

MCQhard

An administrator backs up etcd data using 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. Which command correctly restores this snapshot on a new etcd instance?

A.kubectl apply -f /backup/etcd-snapshot.db

B.etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir=/var/lib/etcd-restored

C.etcdctl snapshot load /backup/etcd-snapshot.db

D.ETCDCTL_API=3 etcdctl restore /backup/etcd-snapshot.db

AnswerB

Why this answer

Option B is correct because `etcdctl snapshot restore` is the proper command to restore an etcd snapshot to a new data directory. The `--data-dir` flag specifies where the restored data should be placed, allowing the new etcd instance to use that directory. This command recreates the etcd member's data from the snapshot file, which is essential for disaster recovery.

Exam trap

CNCF often tests the exact subcommand syntax, so candidates mistakenly choose `etcdctl restore` or `etcdctl snapshot load` instead of the correct `etcdctl snapshot restore`.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` is used to apply Kubernetes resources from YAML/JSON manifests, not to restore etcd snapshots; it cannot interpret a binary snapshot file. Option C is wrong because `etcdctl snapshot load` is not a valid subcommand; the correct subcommand is `snapshot restore`. Option D is wrong because `etcdctl restore` is not a valid subcommand; the correct syntax requires `snapshot restore`, and the `ETCDCTL_API=3` environment variable is not needed when using the v3 API by default.

Full explanation →

385

MCQhard

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?

A.Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod

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

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

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

AnswerA

The event message directly indicates both issues.

Why this answer

The event shows two distinct issues: one node has a taint that the pod doesn't tolerate, and three nodes have insufficient CPU. Option D correctly identifies both. Options A, B, C each miss one or both issues.

Full explanation →

386

MCQmedium

A DaemonSet is expected to run on all nodes, but a particular node does not have the pod. The node is Ready and has no taints. You run 'kubectl describe daemonset <name>' and see 'MISSING' for that node. What is a likely cause?

A.The DaemonSet is configured to run only on control plane nodes

B.The DaemonSet has a nodeSelector that the node does not match

C.The node has insufficient resources for the DaemonSet pod

D.The node has a taint that is not tolerated

AnswerB

Correct. nodeSelector filter causes the DaemonSet to skip nodes that don't match labels.

Why this answer

When a DaemonSet shows 'MISSING' for a specific node that is Ready and has no taints, the most common cause is that the node does not match the DaemonSet's nodeSelector. The nodeSelector field in the DaemonSet spec defines a set of key-value pairs that must match the node's labels. If the node lacks the required labels, the DaemonSet controller will not schedule the pod on that node, resulting in the 'MISSING' status.

Exam trap

The trap here is that candidates often assume 'MISSING' implies a resource or taint issue, but the CKA exam tests the understanding that nodeSelector mismatches cause the DaemonSet controller to skip the node entirely, not just fail to schedule.

How to eliminate wrong answers

Option A is wrong because a DaemonSet configured to run only on control plane nodes would use a nodeSelector or node affinity targeting control plane labels (e.g., node-role.kubernetes.io/control-plane), and the question states the node is Ready with no taints, but does not indicate it is a control plane node; however, the 'MISSING' status would occur for worker nodes, not for a specific node that is Ready—this option does not explain why only one node is missing. Option C is wrong because insufficient resources (CPU/memory) would cause the pod to be in a 'Pending' state, not 'MISSING'; the DaemonSet controller would still attempt to schedule and show the pod as pending, not missing. Option D is wrong because the question explicitly states the node has no taints, so a taint that is not tolerated cannot be the cause.

Full explanation →

387

MCQeasy

Which of the following Service types does NOT assign a ClusterIP to the Service?

A.LoadBalancer

B.Headless

C.ClusterIP

D.NodePort

AnswerB

A Headless Service is created with clusterIP: None and does not get a ClusterIP.

Why this answer

A Headless Service has no ClusterIP. You create it by setting clusterIP: None.

Full explanation →

388

MCQeasy

A pod named 'app' is not starting. You run 'kubectl describe pod app' and see the event: 'MountVolume.SetUp failed for volume "pvc-volume" : rpc error: code = NotFound desc = volume not found'. What is the most likely issue?

A.The container image is not found in the registry

B.The node running the pod is out of disk space

C.The pod has insufficient CPU resources

D.The PersistentVolumeClaim (PVC) referenced by the pod does not exist or is not bound

AnswerD

The error indicates the volume is not found, meaning the PVC is missing or not bound to a PV.

Why this answer

Option A is correct. The error 'volume not found' typically indicates the PVC does not exist or is not bound. Options B, C, and D cause different symptoms.

Full explanation →

389

MCQeasy

Which of the following commands will list all PersistentVolumeClaims in a cluster?

A.kubectl get pv

B.kubectl get pvc

C.kubectl get claims

D.kubectl get persistentvolumeclaims

AnswerB, D

This lists PVCs in the current namespace.

Why this answer

'kubectl get pvc' lists PVCs across all namespaces if no namespace flag is given, but it defaults to the current namespace. To list all namespaces, use --all-namespaces. The correct answer is B as it lists PVCs in the current namespace, which is a common way.

Full explanation →

390

Multi-Selecteasy

Which TWO of the following are control plane components? (Select 2)

Select 2 answers

A.kubelet

B.kube-proxy

C.container runtime

D.etcd

E.kube-apiserver

AnswersD, E

etcd is a control plane component.

Why this answer

etcd is a distributed key-value store that serves as the primary datastore for all cluster state and configuration data in Kubernetes. It is a core control plane component because the API server relies on it to persist and retrieve cluster state, and without it the cluster cannot function.

Exam trap

CNCF often tests the distinction between control plane and node components, and the trap here is that candidates confuse kubelet or kube-proxy as control plane components because they are critical to cluster operation, but they actually run on every node and are not part of the control plane.

Full explanation →

391

MCQmedium

You run 'kubectl get pods' and see a pod named 'db' in CrashLoopBackOff. 'kubectl logs db' shows nothing. 'kubectl logs db --previous' shows 'Error: database connection failed'. What is the most likely cause?

A.The node is out of memory

B.The environment variable for database host is incorrect

C.The pod's liveness probe is misconfigured

D.The container image is missing

AnswerB

The error indicates the application cannot connect to the database, likely due to wrong host.

Why this answer

The previous logs indicate the container failed due to a database connection error, likely a misconfigured environment variable for the database host.

Full explanation →

392

Multi-Selecteasy

Which TWO of the following are correct commands to view the current context in kubeconfig? (Select 2)

Select 2 answers

A.kubectl config get-contexts -o name

B.kubectl config view --context current

C.kubectl config current-context

D.kubectl config get-contexts

E.kubectl config view --minify

AnswersC, E

Displays the current context.

Why this answer

Option C is correct because `kubectl config current-context` is the dedicated command to display the currently active context from the kubeconfig file. It directly outputs the context name without any additional formatting or filtering, making it the simplest and most straightforward way to view the current context.

Exam trap

The trap here is that candidates often confuse commands that list all contexts (like `get-contexts`) with commands that specifically output only the current context, leading them to select options that require manual parsing or do not explicitly show the active context.

Full explanation →

393

MCQhard

A Service of type ClusterIP is not reachable from within the cluster. Pods backing the Service are running and healthy. What is the most likely cause?

A.DNS resolution failure

B.kube-proxy not running or misconfigured

C.Ingress controller not set up

D.Service type should be NodePort

AnswerB

Why this answer

When Pods are healthy but a ClusterIP Service is unreachable from within the cluster, the most common cause is that kube-proxy is not running or is misconfigured. kube-proxy is responsible for implementing the ClusterIP virtual IP by programming iptables (or IPVS) rules on each node to forward traffic to the selected Pods. Without these rules, packets destined for the ClusterIP are dropped or rejected, even though the Service and Endpoints objects exist.

Exam trap

The trap here is that candidates often assume a healthy Pod and Service object guarantee connectivity, overlooking that kube-proxy must actively program the underlying network rules to make the ClusterIP routable.

Why the other options are wrong

A

DNS resolves Service name to ClusterIP; connectivity fails after.

C

Ingress is for external; ClusterIP is internal.

D

ClusterIP works internally.

Full explanation →

394

Multi-Selecthard

Which THREE of the following are true about expanding a PersistentVolumeClaim?

Select 3 answers

A.After expanding the PVC, the pod must be recreated for the new size to take effect.

B.You can reduce the size of a PVC after creation.

C.The StorageClass must have allowVolumeExpansion: true.

D.The volume plugin must support expansion.

E.You can expand a PVC by editing its spec.resources.requests.storage field.

AnswersC, D, E

This is required for PVC expansion.

Why this answer

Expanding a PVC requires the StorageClass to have allowVolumeExpansion: true. The PVC can be edited to request more storage, but only if the underlying volume plugin supports expansion. After expansion, the filesystem may need to be resized.

Full explanation →

395

MCQeasy

Which of the following is a valid CNI plugin for Kubernetes networking?

A.Calico

B.etcd

C.Docker

D.Kubelet

AnswerA

Calico is a CNI plugin.

Why this answer

Calico is a popular CNI plugin that provides networking and network policy enforcement.

Full explanation →

396

MCQeasy

An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?

A.Ensure that containerd is installed and running on the worker node.

B.Verify that the control plane node is healthy.

C.Check if the join token has expired.

D.Install a network plugin like Calico on the control plane.

AnswerA

The CRI error indicates the runtime is not running.

Why this answer

The error 'container runtime is not running' on the worker node indicates that the CRI (Container Runtime Interface) implementation, typically containerd, is not active. Since kubelet relies on a running container runtime to manage pods, the administrator must first check that containerd is installed and running on the worker node using commands like 'systemctl status containerd' or 'systemctl start containerd'.

Exam trap

The trap here is that candidates often assume the error is related to the control plane or networking, but the CRI error specifically points to a missing or stopped container runtime on the node attempting to join.

How to eliminate wrong answers

Option B is wrong because the control plane node's health is irrelevant to a preflight error on the worker node; the worker node's kubelet cannot even start without a runtime. Option C is wrong because a token expiration would produce an authentication error (e.g., 'error: failed to request certificate'), not a CRI runtime error. Option D is wrong because a network plugin like Calico is installed after nodes have joined and is not required for the join process; the preflight check fails before any network plugin is considered.

Full explanation →

397

MCQhard

An administrator runs 'kubectl get nodes' and sees that one node is in the 'NotReady' state. Which component should be checked FIRST to diagnose the issue?

A.kubelet on the worker node

B.kube-apiserver on the control plane

C.kube-controller-manager

D.etcd cluster health

AnswerA

The kubelet is the primary agent that reports node status. If it fails, the node becomes NotReady.

Why this answer

The kubelet is the primary node agent that runs on every worker node and is responsible for registering the node with the cluster and periodically reporting its status via NodeStatus updates. When a node is in 'NotReady' state, it means the kubelet has failed to send heartbeats or report readiness to the control plane, typically due to a crash, misconfiguration, or resource exhaustion. Checking the kubelet's logs and service status (e.g., 'systemctl status kubelet' or 'journalctl -u kubelet') is the first diagnostic step because it directly controls node health reporting.

Exam trap

CNCF often tests the misconception that the kube-controller-manager or kube-apiserver is the root cause of node unreadiness, but the trap here is that the kubelet is the sole component responsible for reporting node health, and its failure is the most direct cause of a 'NotReady' state.

How to eliminate wrong answers

Option B is wrong because the kube-apiserver is the front-end for the Kubernetes API and handles all REST requests, but it does not directly report node health; a failing kube-apiserver would affect all API calls, not just a single node's status. Option C is wrong because the kube-controller-manager runs controllers like the Node Controller that reacts to node status changes, but it does not generate the initial health data; it only acts on the status reported by the kubelet. Option D is wrong because etcd stores cluster state, including node status, but a healthy etcd cluster is required for the control plane to function; however, if only one node is NotReady, the issue is almost certainly local to that node, not the distributed key-value store.

Full explanation →

398

Matchingmedium

Match each cluster upgrade step to its purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Update the cluster bootstrap tool

Update the node agent

Evict Pods gracefully before upgrade

Update API server, scheduler, controller-manager

Allow Pods to be scheduled again after upgrade

Why these pairings

Upgrading a cluster follows a specific order to maintain availability.

Full explanation →

399

MCQmedium

An administrator runs `kubectl port-forward service/my-svc 8080:80`. What does this command do?

A.Creates a new Service with port mapping 8080:80

B.Forwards port 8080 from the Service to port 80 on the local machine

C.Forwards port 80 from the local machine to port 8080 on the Service

D.Forwards local port 8080 to port 80 on the Service

AnswerD

The command syntax is `kubectl port-forward <resource> <local>:<remote>`.

Why this answer

`kubectl port-forward` creates a tunnel from a local port to a resource in the cluster. For a Service, it forwards local port 8080 to the Service's port 80, allowing local access to the Service.

Full explanation →

400

MCQeasy

Which access mode allows multiple pods running on different nodes to read from and write to a PersistentVolume at the same time?

A.ReadOnlyMany

B.ReadWriteMany

C.ReadWriteOnce

D.ReadWriteOncePod

AnswerB

RWX allows multiple nodes to mount with read-write access.

Why this answer

Option C is correct: ReadWriteMany (RWX) allows multiple nodes to mount the volume with read-write access. Option A (RWO) allows only one node. Option B (ROX) is read-only for many nodes.

Option D (RWOP) is for a single pod, not multiple nodes.

Full explanation →

401

MCQeasy

A Pod is in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate'. What is the most likely issue?

A.The nodes do not have enough CPU or memory to run the Pod.

B.The Pod does not have tolerations for the taints on the nodes.

C.The nodes are not tainted, but the Pod has tolerations.

D.The scheduler is not running.

AnswerB

The error message directly indicates that the Pod cannot tolerate the node taints.

Why this answer

The event '0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate' directly indicates that all nodes in the cluster have taints applied, and the Pod's spec does not include corresponding tolerations. Taints and tolerations work together to ensure that Pods are only scheduled onto nodes whose taints they tolerate; without matching tolerations, the scheduler will skip those nodes entirely, leaving the Pod in a Pending state.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, so candidates may incorrectly assume the error is about resource exhaustion when the event message explicitly mentions taints.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory would produce a different event, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option C is wrong because if nodes are not tainted, the Pod would be scheduled normally regardless of tolerations; the event explicitly states nodes had taints, so this scenario contradicts the observed error. Option D is wrong because if the scheduler were not running, the Pod would remain in Pending state without any scheduling events at all, and 'kubectl describe pod' would not show taint-related messages.

Full explanation →

402

MCQmedium

Based on the exhibit, what is the most likely cause of the worker2 node being NotReady?

A.The kubelet on worker2 has stopped reporting to the control plane

B.The node has insufficient memory

C.The node is experiencing disk pressure

D.The network plugin (Calico) is not running on worker2

AnswerA

The Ready condition is Unknown with message 'Kubelet stopped posting node status'.

Why this answer

The kubelet on worker2 has stopped reporting to the control plane, which is the most likely cause of the node being NotReady. The kubelet is responsible for periodically posting node status updates (including heartbeats) to the API server via the NodeStatus update mechanism. If the kubelet process is down, unresponsive, or cannot communicate with the control plane (e.g., due to network partition or certificate expiry), the node controller marks the node as NotReady after the `node-monitor-grace-period` (default 40 seconds) elapses.

Exam trap

CNCF often tests the distinction between node conditions (MemoryPressure, DiskPressure) and the overall Ready status; the trap here is that candidates confuse a node being under resource pressure (which still allows it to report Ready) with the node being completely unreachable due to kubelet failure.

How to eliminate wrong answers

Option B is wrong because insufficient memory would typically result in the node condition `MemoryPressure` being set to True, but the node would still report as Ready (unless the kubelet evicts pods or the node becomes unreachable). Option C is wrong because disk pressure is indicated by the `DiskPressure` condition, which does not directly cause the node to become NotReady; the node remains Ready but may evict pods. Option D is wrong because if the network plugin (Calico) is not running, the node would still report as Ready (the kubelet continues to report status), but pods would fail to start or have networking issues; the NotReady condition is specifically tied to the kubelet's heartbeat, not the CNI plugin.

Full explanation →

403

MCQhard

During a cluster upgrade using kubeadm, after upgrading the control plane, you attempt to upgrade a worker node. The command `kubeadm upgrade node` fails with the error 'node is not ready'. What is the most likely cause?

A.The worker node has a newer version of kubelet than the control plane.

B.The worker node's kube-proxy is outdated.

C.The kubelet on the worker node has not been restarted.

D.The worker node has not been cordoned.

AnswerD

Before upgrading a worker node, it must be cordoned to prevent new Pods; the upgrade command requires the node to be in a maintainable state.

Why this answer

Option D is correct because `kubeadm upgrade node` requires the node to be in a schedulable state to perform the upgrade. If the node is not cordoned first, the upgrade process may fail with a 'node is not ready' error, as the kubeadm workflow expects the node to be drained and marked as unschedulable before proceeding. Cordon ensures the node is marked as unschedulable, preventing new pods from being scheduled during the upgrade.

Exam trap

The trap here is that candidates often assume the 'node is not ready' error refers to the kubelet health status, but in the context of `kubeadm upgrade node`, it specifically indicates that the node has not been cordoned before the upgrade attempt.

How to eliminate wrong answers

Option A is wrong because the kubelet version on a worker node should be equal to or lower than the control plane version during a kubeadm upgrade; a newer kubelet than the control plane is not a standard cause of 'node is not ready' and would typically cause version skew issues, not this specific error. Option B is wrong because an outdated kube-proxy does not directly cause a 'node is not ready' error during `kubeadm upgrade node`; kube-proxy is a DaemonSet managed separately and its version is not checked by the upgrade command. Option C is wrong because the kubelet on the worker node is typically restarted as part of the upgrade process, but not restarting it would not produce a 'node is not ready' error from `kubeadm upgrade node`; instead, the node would remain in a NotReady state due to the kubelet not reporting, but the command itself would not fail with that specific message.

Full explanation →

404

Multi-Selecthard

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

Select 2 answers

A.The node has a taint that prevents scheduling

B.The kubelet process has stopped

C.The container runtime (containerd) is not responding

D.The node has insufficient disk space

E.The node's IP address has changed

AnswersB, C

If the kubelet stops, the node status becomes NotReady.

Why this answer

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

Full explanation →

405

MCQhard

A Pod is stuck in 'Pending' state. You run 'kubectl describe pod my-pod' and see the event: '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient cpu.' The pod has resource requests: cpu: 2, memory: 1Gi. The cluster has 3 nodes: one control-plane with taint node-role.kubernetes.io/master:NoSchedule, and two worker nodes each with 1 CPU. What is the most likely cause?

A.The pod requests more memory than any available node can provide.

B.The pod has a higher priority than other pods and is preempting them.

C.The pod requests more CPU than any available node can provide.

D.The control-plane node has insufficient resources.

AnswerC

The pod requests 2 CPUs, but worker nodes have only 1 CPU each. The control plane node is tainted and not schedulable for this pod.

Why this answer

Option A is correct. The two worker nodes have only 1 CPU each, so they cannot satisfy the request of 2 CPUs. The control plane node is tainted and the pod does not tolerate it.

Option B is incorrect because memory is not the issue. Option C is incorrect because the control plane node is not available due to taint, not because of resource shortage. Option D is incorrect because there is no mention of a PriorityClass.

Full explanation →

406

MCQeasy

Which kube-proxy mode uses iptables rules to handle service traffic?

A.ipvs

B.nftables

C.userspace

D.iptables

AnswerD

Correct mode.

Why this answer

kube-proxy can run in userspace, iptables, or ipvs mode. The iptables mode uses iptables rules to direct traffic to service backends.

Full explanation →

407

MCQhard

A StatefulSet named 'mysql' manages 3 replicas. You need to scale it down to 1 replica. What happens to the PersistentVolumeClaims (PVCs) of the removed pods?

A.The PVCs are retained to preserve data.

B.The PVCs are automatically backed up before deletion.

C.The PVCs are retained only if the pod with the highest ordinal is removed first.

D.The PVCs are automatically deleted along with the pods.

AnswerA

StatefulSet does not delete PVCs when scaling down, to protect data.

Why this answer

When a StatefulSet is scaled down, the PersistentVolumeClaims (PVCs) associated with the removed pods are retained by default. This is because StatefulSets are designed for stateful workloads where data persistence is critical; the PVCs remain to preserve data in case the pod is recreated or the StatefulSet is scaled up again. Kubernetes does not automatically delete PVCs when a StatefulSet pod is removed, as PVC lifecycle is independent of pod lifecycle.

Exam trap

The trap here is that candidates often confuse StatefulSet PVC behavior with that of Deployments or Jobs, where pods and their volumes are ephemeral, leading them to incorrectly assume PVCs are automatically deleted on scale-down.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not have an automatic backup mechanism for PVCs when scaling down a StatefulSet; PVCs are simply retained, not backed up. Option C is wrong because PVCs are retained regardless of which pod (highest ordinal or not) is removed first; the ordinal-based removal order only affects pod naming, not PVC retention. Option D is wrong because PVCs are not automatically deleted when pods are removed; they persist until explicitly deleted by the user or through a configured StorageClass with reclaimPolicy: Delete, which is not the default behavior for StatefulSet PVCs.

Full explanation →

408

MCQhard

You are a Kubernetes administrator overseeing a multi-tier application in a production cluster. The application consists of a front-end web server (Deployment 'frontend') and a backend API (Deployment 'backend'). The frontend needs to communicate with the backend using the DNS name 'backend-service' within the same namespace 'prod'. Users report intermittent 'Connection Refused' errors when accessing the frontend, which then cannot reach the backend. After checking the backend pods, they are all running and ready. The backend Service is defined as a ClusterIP service with no ports specified in the YAML manifest. What is the most likely cause of the failure?

A.The backend Service manifest is missing the 'ports' field, so it has no endpoints.

B.The backend pods are listening on a different port than expected by the frontend.

C.The 'kube-proxy' is not running on the node where the frontend pod is scheduled.

D.A NetworkPolicy in the 'prod' namespace is blocking traffic from the frontend to the backend.

AnswerA

Without ports, the Service does not forward traffic, leading to connection refused.

Why this answer

A ClusterIP Service without a 'ports' field in its manifest will have no port mappings defined, meaning the Service controller cannot create endpoints for it. Even though the backend pods are running and ready, the Service will have no endpoints, so DNS resolution of 'backend-service' will succeed but any connection attempt will result in 'Connection Refused' because there is no target port to forward traffic to.

Exam trap

The trap here is that candidates assume a Service will automatically detect pod ports from the pod template, but Kubernetes requires an explicit 'ports' field in the Service manifest to create endpoints.

How to eliminate wrong answers

Option B is wrong because the question states the backend Service has no ports specified in the YAML manifest, which is the root cause; even if the pods listened on a different port, the Service would still fail to route traffic without any port definition. Option C is wrong because if kube-proxy were not running, the frontend would not be able to reach any ClusterIP Service at all, not just the backend, and the issue would be persistent rather than intermittent. Option D is wrong because a NetworkPolicy blocking traffic would cause a 'Connection Timeout' or 'No Route to Host' error, not 'Connection Refused', and the question does not mention any NetworkPolicy being applied.

Full explanation →

409

MCQmedium

A pod is in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 1 node(s) had taint that the pod didn't tolerate, 2 node(s) didn't match pod's node affinity/selector, 1 node(s) had insufficient memory'. What does this indicate?

A.The pod's image pull failed on all nodes

B.The pod will eventually be scheduled when resources free up

C.The pod is unschedulable due to multiple constraints

D.The pod has a resource limit that prevents it from running

AnswerC

Correct. The pod cannot be scheduled because no node meets all requirements.

Why this answer

The 'Pending' state combined with the scheduler's message '0/4 nodes are available' and the listed reasons (taints, node affinity/selector mismatches, insufficient memory) indicates that the pod cannot be placed on any node due to multiple constraints. The scheduler evaluates all nodes and finds none that satisfy the pod's requirements, making the pod unschedulable. This is not a transient resource issue but a combination of scheduling constraints that must be resolved manually.

Exam trap

CNCF often tests the distinction between resource requests and limits, and candidates mistakenly think limits affect scheduling, when in fact only requests are considered by the scheduler's PodFitsResources predicate.

How to eliminate wrong answers

Option A is wrong because image pull failures produce 'ImagePullBackOff' or 'ErrImagePull' events, not a 'Pending' state with node availability messages. Option B is wrong because the message includes taints and affinity/selector mismatches, which are not resolved by freeing resources; only the 'insufficient memory' issue might clear up, but the other constraints are permanent until the pod or nodes are reconfigured. Option D is wrong because resource limits (spec.containers[].resources.limits) affect runtime behavior (e.g., OOMKill) but do not prevent scheduling; scheduling is blocked by resource requests (spec.containers[].resources.requests) or node capacity, not limits.

Full explanation →

410

MCQeasy

Which component is responsible for managing the lifecycle of pods on a node?

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-proxy

AnswerC

The kubelet manages pods on the node.

Why this answer

The kubelet is the primary node agent that runs on each node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a pod as expected, managing the pod lifecycle by communicating with the container runtime (e.g., containerd or CRI-O) and reporting the node and pod status back to the API server.

Exam trap

The trap here is that candidates often confuse the kube-scheduler (which places pods on nodes) with the kubelet (which actually runs and manages them), or think the kube-controller-manager handles node-level pod operations.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for managing pods on a node. Option B is wrong because the kube-controller-manager runs controllers (e.g., ReplicaSet, Node controller) that regulate the desired state of the cluster, but it does not directly manage pod lifecycles on individual nodes. Option D is wrong because kube-proxy handles network proxying and load balancing for services on each node, not pod lifecycle management.

Full explanation →

411

MCQmedium

You need to check the resource usage of nodes in your cluster. Which command should you run?

A.kubectl top nodes

B.kubectl get nodes -o wide

C.kubectl logs --all-containers

D.kubectl describe nodes

AnswerA

kubectl top nodes shows CPU and memory usage of nodes.

Why this answer

Option A is correct. kubectl top nodes uses the metrics server to display resource usage. Options B and C do not show resource usage. Option D is invalid.

Full explanation →

412

Multi-Selectmedium

Which TWO taint effects can be used to prevent a pod from being scheduled on a node unless it has a matching toleration?

Select 2 answers

A.PreferNoSchedule

B.NoExecute

C.NoSchedule

D.FailSchedule

E.NoAdmit

AnswersB, C

Prevents scheduling and evicts existing pods without toleration.

Why this answer

NoSchedule and NoExecute prevent scheduling without toleration. PreferNoSchedule is a soft preference and does not prevent scheduling. Taint effects are: NoSchedule, PreferNoSchedule, NoExecute.

Full explanation →

413

MCQhard

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?

A.Drain the first node

B.Upgrade the worker nodes

C.Upgrade the remaining control plane nodes

D.Run kubeadm upgrade plan

AnswerC

Control plane nodes are upgraded sequentially.

Why this answer

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.

Exam trap

The trap here is that candidates often think draining the first node is the next step after upgrading it, but draining is actually done before the upgrade to safely evict pods, not after the control plane components have been updated.

How to eliminate wrong answers

Option A is wrong because draining the first node is performed before upgrading it, not after; the node is drained to evict workloads, then upgraded, then uncordoned. Option B is wrong because worker nodes must only be upgraded after all control plane nodes have been upgraded to the target version, as the kubelet on workers must match or be within one minor version of the API server. Option D is wrong because 'kubeadm upgrade plan' is run before any upgrade begins to verify the upgrade path and available versions, not after the first control plane node has already been upgraded.

Full explanation →

414

Multi-Selectmedium

Which of the following are valid methods to debug a failing CoreDNS pod? (Select TWO)

Select 2 answers

A.kubectl logs -n kube-system -l k8s-app=kube-dns

B.kubectl delete pod -n kube-system -l k8s-app=kube-dns

C.kubectl get endpoints -n kube-system kube-dns

D.kubectl scale deployment coredns --replicas=2

E.kubectl run -it --rm test --image=busybox -- nslookup kubernetes.default

AnswersA, C

Why this answer

Option A is correct because `kubectl logs -n kube-system -l k8s-app=kube-dns` retrieves the logs from all CoreDNS pods (which are labeled `k8s-app=kube-dns` in the `kube-system` namespace). This is a direct method to inspect errors, crashes, or misconfigurations in the DNS service. Option C is correct because `kubectl get endpoints -n kube-system kube-dns` shows the IP addresses of the pods backing the `kube-dns` service; if the endpoint list is empty, it indicates that no CoreDNS pods are ready to serve DNS requests, which is a common failure point.

Exam trap

The trap here is that candidates confuse debugging actions (like checking logs or endpoints) with recovery actions (like deleting or scaling pods), and they may also mistake client-side DNS tests (like `nslookup`) for pod-level debugging, which only confirms the symptom, not the cause.

Why the other options are wrong

B

Deleting a pod is a fix, not a debug method.

D

Scaling is a fix, not debugging.

E

This tests DNS resolution, not debugging CoreDNS pod itself.

Full explanation →

415

Multi-Selectmedium

Which THREE are valid steps when upgrading a Kubernetes cluster using kubeadm? (Select 3)

Select 3 answers

A.Upgrade kubelet and kubectl on the node.

B.Upgrade kubeadm on the node to the target version.

C.Upgrade the container runtime to a compatible version.

D.Drain the node before upgrading it.

E.Run 'kubeadm upgrade apply' on the worker node.

AnswersA, B, D

These components must be upgraded manually.

Why this answer

Option A is correct because after upgrading kubeadm on the control plane, you must upgrade kubelet and kubectl on each node to match the target Kubernetes version. The kubelet is the primary node agent that communicates with the control plane, and kubectl is the CLI tool used to interact with the cluster. Without upgrading these components, the node may fail to register or report an incompatible version, causing the node to be in a NotReady state.

Exam trap

The trap here is that candidates often confuse the 'kubeadm upgrade apply' command, thinking it can be run on any node, when in fact it must be executed on the control plane node, while worker nodes require 'kubeadm upgrade node'.

Full explanation →

416

MCQmedium

A node named 'node1' is having issues. You want to prevent any new pods from being scheduled onto it without affecting running pods. Which command should you use?

A.kubectl drain node1

B.kubectl cordon node1

C.kubectl taint nodes node1 key=value:NoSchedule

D.kubectl delete node node1

AnswerB

Correct: cordon marks node unschedulable.

Why this answer

The `kubectl cordon node1` command marks the node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the correct approach when you need to isolate a node for maintenance without disrupting current workloads.

Exam trap

The trap here is that candidates often confuse `cordon` with `drain` or `taint`, thinking that draining is required to prevent scheduling, or that tainting is the only way to achieve this, but `cordon` is the simplest and most direct command for marking a node unschedulable without affecting running pods.

How to eliminate wrong answers

Option A is wrong because `kubectl drain node1` evicts all pods from the node (with graceful termination), which would affect running pods, contrary to the requirement. Option C is wrong because `kubectl taint nodes node1 key=value:NoSchedule` adds a taint that prevents new pods from being scheduled unless they tolerate the taint, but it does not affect existing pods; however, the question asks for a command that prevents new pods without affecting running pods, and while tainting can achieve this, it is not the standard or simplest command for this purpose—cordon is the direct and intended tool. Option D is wrong because `kubectl delete node node1` removes the node object from the cluster, which would cause the kubelet to lose registration and potentially affect running pods (they would be terminated or orphaned), and it is a destructive action not suitable for simple scheduling prevention.

Full explanation →

417

Multi-Selecthard

You have a Pod that is in CrashLoopBackOff. Which TWO of the following commands would be most helpful in diagnosing the issue?

Select 2 answers

A.kubectl get events --all-namespaces

B.kubectl logs <pod-name> --previous

C.kubectl describe pod <pod-name>

D.kubectl logs <pod-name>

E.kubectl top pod <pod-name>

AnswersB, C

Shows logs from the crashed container instance, which often contains the error.

Why this answer

Options A and B are correct. 'kubectl describe pod' shows events and container state, including termination reason. 'kubectl logs --previous' shows logs from the previous container instance. Option C shows current logs, which may be empty if the container crashes quickly. Option D shows resource usage, not crash reasons.

Option E shows general events, but describe already includes them for the specific Pod.

Full explanation →

418

MCQhard

A pod is stuck in Pending with event '0/4 nodes are available: 1 node(s) had taint "node.kubernetes.io/disk-pressure", and 3 node(s) had taint "node.kubernetes.io/memory-pressure", that the pod didn't tolerate'. What is the best approach to schedule the pod?

A.Use 'kubectl taint nodes --all node.kubernetes.io/disk-pressure- node.kubernetes.io/memory-pressure-' to remove the taints

B.Add tolerations for both taints to the pod spec

C.Free up disk space and reduce memory usage on the affected nodes

D.Delete the pod and recreate it with higher resource requests

AnswerC

This resolves the root cause by removing the taints, allowing the pod to schedule normally.

Why this answer

The cluster has nodes with disk-pressure and memory-pressure taints. These are typically added by the node controller when resources are low. The pod does not tolerate these taints.

The best approach is to free resources on the nodes or add tolerations; however, tolerating pressure taints is not recommended as it can cause further instability. Usually, you should resolve the underlying resource issues.

Full explanation →

419

MCQeasy

You need to temporarily access a pod's HTTP endpoint on port 8080 from your local machine on port 8080. Which kubectl command should you use?

A.kubectl expose pod my-pod --port=8080

B.kubectl proxy --port=8080

C.kubectl port-forward service/my-service 8080:8080

D.kubectl port-forward pod/my-pod 8080:8080

AnswerD

This forwards local port 8080 to pod port 8080.

Why this answer

kubectl port-forward forwards local port to pod port. Option A is correct. Option B forwards to a service, not pod.

Option C uses incorrect syntax. Option D uses 'expose' incorrectly.

Full explanation →

420

MCQmedium

You run 'kubectl get pods' and see a pod with status 'Init:CrashLoopBackOff'. What does this indicate?

A.An init container in the pod is failing and restarting

B.The pod's init container ran successfully but the main container has not started yet

C.The pod is still initializing but will eventually run

D.The main container is crashing and the pod is restarting

AnswerA

The 'Init' prefix indicates the issue is with an init container.

Why this answer

Init:CrashLoopBackOff means an init container in the pod is repeatedly crashing. Option A is correct. Option B describes a regular container crash.

Option C is wrong because the pod is not running. Option D is wrong because init containers always run to completion before main containers start.

Full explanation →

421

MCQmedium

Which subcommand of 'kubectl config' is used to switch between different contexts?

A.kubectl config switch-context

B.kubectl config set-context

C.kubectl config current-context

D.kubectl config use-context

AnswerD

This command sets the current context for kubectl.

Why this answer

Option D is correct because 'kubectl config use-context' is the exact subcommand used to switch the current context in a kubeconfig file. This command updates the 'current-context' field in the kubeconfig, directing all subsequent kubectl commands to the specified cluster, namespace, and user combination.

Exam trap

The trap here is that candidates confuse 'set-context' (which modifies context definitions) with 'use-context' (which switches the active context), leading them to choose option B instead of D.

How to eliminate wrong answers

Option A is wrong because 'kubectl config switch-context' is not a valid kubectl subcommand; kubectl does not have a 'switch-context' command. Option B is wrong because 'kubectl config set-context' is used to modify or create a context definition (e.g., setting cluster, user, or namespace), but it does not change the active/current context. Option C is wrong because 'kubectl config current-context' only displays the name of the currently active context, without switching to a different one.

Full explanation →

422

MCQmedium

You run `kubectl port-forward service/my-svc 8080:80`. What does this command do?

A.It forwards local port 8080 to port 80 on the Service's cluster IP.

B.It forwards traffic from port 80 to port 8080 within the cluster.

C.It creates a LoadBalancer Service on port 8080 forwarding to port 80.

D.It exposes the Service on each node's port 8080.

AnswerA

Port-forward maps a local port to a port on a resource (pod or service).

Full explanation →

423

MCQeasy

Which command forwards local port 8080 to port 80 of a pod named 'web-pod'?

A.kubectl exec -it web-pod -- nc -l -p 8080

B.kubectl proxy --port=8080

C.kubectl expose pod web-pod --port=8080 --target-port=80

D.kubectl port-forward pod/web-pod 8080:80

AnswerD

Correct syntax for port forwarding.

Why this answer

kubectl port-forward pod/web-pod 8080:80 forwards local port 8080 to the pod's port 80.

Full explanation →

424

MCQmedium

You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?

A.The kubelet is not installed

B.Network connectivity issue between kubelet and API server

C.The node has been cordoned

D.The API server is down

AnswerB

Why this answer

When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.

Exam trap

The trap here is that candidates confuse 'cordon' (which affects scheduling but not readiness) with 'NotReady' (which indicates a health or connectivity failure), leading them to pick Option C when the node is actually unreachable.

Why the other options are wrong

A

Question states kubelet is running.

C

Cordoning makes node Unschedulable, not NotReady.

D

If API server is down, kubectl get nodes would fail, not show NotReady.

Full explanation →

425

MCQmedium

A developer reports that a Pod named 'web-pod' in namespace 'frontend' is crashing repeatedly. You run 'kubectl logs web-pod -n frontend' but see no output. Which command should you run next to see the logs from the previous, crashed container instance?

A.kubectl get events -n frontend --sort-by=.metadata.creationTimestamp

B.kubectl logs web-pod -n frontend --previous

C.kubectl logs web-pod -n frontend -c web-pod

D.kubectl exec -it web-pod -n frontend -- sh

AnswerB

This retrieves logs from the previous crashed container.

Why this answer

'kubectl logs --previous' retrieves logs from the previous container instance, which is useful for debugging crash loops. Option A shows current logs (empty). Option C shows events.

Option D attempts to exec into a crashed container.

Full explanation →

426

MCQhard

A pod is in CrashLoopBackOff. The YAML for the initContainer is: apiVersion: v1 kind: Pod metadata: name: myapp spec: initContainers: - name: init image: busybox command: ['sh', '-c', 'sleep 5 && exit 1'] containers: - name: app image: nginx What is the most likely reason for the CrashLoopBackOff?

A.The main container image nginx is not pulled successfully

B.The init container command is misspelled

C.The init container exits with non-zero exit code

D.The pod has insufficient memory

AnswerC

Correct. Init container failure causes the pod to restart.

Why this answer

Init containers must complete successfully (exit 0) before the main container starts. An exit code 1 causes the pod to fail and restart.

Full explanation →

427

MCQhard

A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?

A.Use the downward API to inject the token as an environment variable.

B.Set the token in the pod spec using the 'serviceAccountToken' field.

C.Mount the secret directly using a volume.

D.Use a projected service account token with a mount path.

AnswerD

Projected tokens are the recommended way to expose service account tokens in pods.

Why this answer

Option D is correct because the recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.

Exam trap

The trap here is that candidates often think mounting the ServiceAccount's secret directly (Option C) is still the recommended method, but the CKA exam expects knowledge of the newer, more secure projected token approach introduced in Kubernetes 1.20+.

How to eliminate wrong answers

Option A is wrong because the Downward API cannot inject the ServiceAccount token as an environment variable; it only exposes pod metadata (e.g., labels, annotations, namespace) and not secrets or tokens. Option B is wrong because there is no 'serviceAccountToken' field in the pod spec; the token is automatically mounted via the 'serviceAccountName' field, but the token itself is not directly specified in the pod spec. Option C is wrong because mounting the secret directly (e.g., the token secret created by Kubernetes for the ServiceAccount) is deprecated and less secure, as it lacks automatic rotation and audience binding, unlike projected tokens.

Full explanation →

428

MCQmedium

An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?

A.The Service port name does not match the container port name.

B.The Service type is ClusterIP.

C.The Service targetPort is not specified.

D.The pods are not in Ready state (e.g., failing readiness probes).

AnswerD

Only Ready pods are included as endpoints.

Why this answer

The most likely cause is that the pods are not in Ready state, often due to failing readiness probes. Kubernetes endpoints are only populated for pods that pass their readiness checks; if a pod is not Ready, it is removed from the Service's endpoint list, even if it is running and has the correct labels.

Exam trap

The trap here is that candidates often assume label matching alone guarantees endpoint creation, but Kubernetes requires pods to be in the Ready state (determined by readiness probes) before they are added to the Service's endpoints.

How to eliminate wrong answers

Option A is wrong because the Service port name and container port name do not need to match; the Service selects pods by label, and port mapping is done by port number or targetPort, not by name. Option B is wrong because ClusterIP is the default Service type and does not affect endpoint population; endpoints are created regardless of the Service type as long as there are matching Ready pods. Option C is wrong because if targetPort is not specified, it defaults to the same value as the Service's port, which still allows traffic to reach the container port; missing targetPort does not prevent endpoints from being created.

Full explanation →

429

MCQmedium

A cluster administrator wants to expand an existing PersistentVolumeClaim (PVC) that is bound to a PersistentVolume (PV) with reclaim policy Delete and storage class 'fast'. The PV was dynamically provisioned. Which condition is required for the PVC expansion to succeed?

A.The PV must be in Released state.

B.The StorageClass 'fast' must have allowVolumeExpansion: true.

C.The reclaim policy must be changed to Retain before expansion.

D.The PVC must be using access mode ReadWriteOnce.

AnswerB

allowVolumeExpansion must be enabled in the StorageClass to allow resizing of PVCs provisioned by that class.

Why this answer

PVC expansion requires that the StorageClass has allowVolumeExpansion: true. The PV's reclaim policy does not affect expansion. The PVC must also be in Bound state and the access mode supports expansion.

So the correct answer is that the StorageClass 'fast' must have allowVolumeExpansion: true.

Full explanation →

430

MCQmedium

A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?

A.cat /var/log/kubelet/kubelet.log

B.kubectl logs kubelet -n kube-system

C.systemctl restart kubelet

D.journalctl -u kubelet

AnswerD

This command displays the logs of the kubelet service, which is essential for troubleshooting why the node is NotReady.

Why this answer

On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.

Full explanation →

431

Multi-Selectmedium

Which TWO statements are correct regarding DaemonSets?

Select 2 answers

A.DaemonSets do not support rolling updates.

B.DaemonSets can be scaled up and down using kubectl scale.

C.DaemonSets use a replica count to determine how many pods to run.

D.DaemonSets are often used for cluster monitoring or logging agents.

E.DaemonSets ensure that all (or some) nodes run a copy of a pod.

AnswersD, E

Common use cases include node-level services like log collectors and monitoring agents.

Why this answer

Option D is correct because DaemonSets are designed to run a copy of a pod on every node (or a subset of nodes based on node selectors), making them ideal for cluster-wide infrastructure services such as monitoring agents (e.g., Prometheus Node Exporter), logging agents (e.g., Fluentd), and network plugins (e.g., Calico). This pattern ensures that each node has the necessary agent running without manual intervention.

Exam trap

The trap here is that candidates confuse DaemonSets with Deployments or StatefulSets, mistakenly thinking they support scaling via `kubectl scale` or use a replica count, when in fact DaemonSets are node-driven and scale automatically based on node membership.

Full explanation →

432

MCQmedium

You are upgrading a Kubernetes cluster from v1.29.0 to v1.30.0 using kubeadm. What is the correct sequence of operations?

A.Upgrade kubeadm on all nodes, then upgrade kubelet on each node without draining

B.Upgrade all nodes simultaneously

C.Upgrade worker nodes first, then control plane nodes

D.Drain control plane node, upgrade kubeadm, kubelet, kubectl, uncordon, then repeat for worker nodes

AnswerD

This is the correct order: drain control plane, upgrade, uncordon, then workers.

Why this answer

Option D is correct because upgrading a Kubernetes cluster with kubeadm requires a sequential, node-by-node approach starting with the control plane. The control plane node must be drained to evict workloads, then kubeadm, kubelet, and kubectl are upgraded, and the node is uncordoned before moving to worker nodes. This ensures the cluster control plane remains available and worker nodes are upgraded only after the control plane is stable, preventing cluster downtime.

Exam trap

The trap here is that candidates often assume worker nodes can be upgraded first to minimize control plane downtime, but the CKA tests the strict kubeadm upgrade sequence where the control plane must be upgraded before worker nodes to maintain cluster stability and API version compatibility.

How to eliminate wrong answers

Option A is wrong because upgrading kubeadm on all nodes before upgrading kubelet would leave kubelet versions mismatched with the kubeadm version, causing node registration failures; also, draining nodes is required to safely evict pods. Option B is wrong because upgrading all nodes simultaneously would cause a complete cluster outage, as the control plane and kubelet versions would be inconsistent, and kubeadm does not support parallel upgrades. Option C is wrong because worker nodes depend on the control plane for scheduling and API operations; upgrading workers first would break communication if the control plane is still on the old version, and the official kubeadm upgrade process mandates upgrading the control plane first.

Full explanation →

433

MCQhard

A developer runs 'kubectl port-forward service/my-svc 8080:80' and reports that connections to localhost:8080 fail. The service is a ClusterIP service that selects pods with label 'app: my-app'. What is the most likely cause?

A.The service type is ClusterIP, which does not support port forwarding.

B.No pods match the service selector, so the service has no endpoints.

C.kubectl port-forward cannot forward to services, only to pods.

D.The port forward command requires the --address flag to bind to localhost.

AnswerB

Without endpoints, port forwarding to the service fails.

Why this answer

Port forwarding to a service works if the service has endpoints. If no pods match the service selector, the service has no endpoints and the port forward cannot forward traffic.

Full explanation →

434

MCQmedium

Which of the following is the default DNS name for a Service named 'my-svc' in namespace 'my-ns'?

A.my-svc.my-ns.svc.cluster.local

B.my-svc.my-ns.cluster.local

C.my-svc.my-ns.svc

D.my-svc.my-ns.pod.cluster.local

AnswerA

This is the standard DNS name for a Service.

Why this answer

The default DNS name for a Service is `<service>.<namespace>.svc.cluster.local`. CoreDNS resolves names in this format.

Full explanation →

435

MCQmedium

You want to grant a user read-only access to all pods in the 'development' namespace. Which RBAC resource should you create?

A.ClusterRoleBinding with get, list, watch on pods

B.Role in the development namespace with get, list, watch on pods

C.ClusterRole with get, list, watch on pods

D.RoleBinding referencing a ClusterRole that has get, list, watch on pods

AnswerB

Correct: Role scoped to namespace.

Why this answer

A Role in the 'development' namespace with get, list, watch on pods is correct because RBAC Roles are namespace-scoped and grant permissions only within that namespace. Since the requirement is read-only access to pods in a specific namespace, a Role is the appropriate resource to define these permissions.

Exam trap

The trap here is that candidates often confuse Role vs ClusterRole and RoleBinding vs ClusterRoleBinding, thinking a ClusterRole is needed for any pod access, but the namespace scope of the requirement dictates a Role, not a ClusterRole.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding binds a ClusterRole (or Role) cluster-wide, which would grant read-only access to pods in all namespaces, not just 'development'. Option C is wrong because a ClusterRole alone is not bound to a user; it must be referenced by a RoleBinding or ClusterRoleBinding to grant permissions. Option D is wrong because while a RoleBinding referencing a ClusterRole with get, list, watch on pods could work, it is not the resource you should create—the question asks which RBAC resource to create, and the most direct and correct answer is a Role in the namespace, not a RoleBinding.

Full explanation →

436

MCQmedium

You suspect the kubelet on a worker node has stopped. Which two commands should you run to confirm the kubelet status and check its logs?

A.systemctl status docker and tail -f /var/log/syslog

B.kubectl get nodes and kubectl describe node <node>

C.systemctl restart kubelet and journalctl -u containerd

D.systemctl status kubelet and journalctl -u kubelet

AnswerD

These are the standard commands to check kubelet status and logs.

Why this answer

To check if the kubelet is running, use 'systemctl status kubelet'. To view logs, use 'journalctl -u kubelet'. The other options target the wrong service or are not applicable.

Full explanation →

437

MCQmedium

You have a headless service named 'my-headless' with clusterIP: None. A pod in the same namespace queries the DNS name 'my-headless'. What will the DNS response contain?

A.An error because headless services cannot be queried by DNS.

B.A single A record with the service's IP.

C.The ClusterIP of the service (which is None).

D.A list of A records for each pod matching the service selector.

AnswerD

DNS returns the pod IPs directly.

Why this answer

For a headless service, DNS returns the IP addresses of the endpoints (pods) directly, not a single ClusterIP.

Full explanation →

438

MCQeasy

You need to check the current resource usage of nodes in your cluster. Which command should you use?

A.kubectl top pods

B.kubectl get events

C.kubectl get nodes -o wide

D.kubectl top nodes

AnswerD

This shows CPU and memory usage of nodes.

Why this answer

Correct answer is B. 'kubectl top nodes' shows CPU and memory usage of nodes. Option A shows pods. Option C shows events.

Option D shows node status but not resource usage.

Full explanation →

439

MCQeasy

Which command can you run to see the events related to a specific pod?

A.kubectl logs pod-name

B.kubectl get pod pod-name

C.kubectl get events

D.kubectl describe pod pod-name

AnswerD

Describe pod shows events related to that pod.

Why this answer

Correct answer is A. 'kubectl describe pod pod-name' includes events at the bottom. Option B shows all events cluster-wide. Option C is for logs.

Option D shows pod status briefly.

Full explanation →

440

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Delete the namespace and redeploy all workloads

C.Delete and recreate the pod to clear the crash loop

D.Increase the CPU request for the container

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Exam trap

The trap here is that candidates may confuse OOMKilled with a generic crash and choose to delete/recreate the pod (Option C), not realizing that the pod will immediately re-enter CrashLoopBackOff because the underlying memory limit is unchanged.

How to eliminate wrong answers

Option B is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that doesn't address the root cause (memory limit too low) and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod will only temporarily restart it; the pod will crash again with OOMKilled once memory usage exceeds the limit. Option D is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related termination, not CPU-related.

Full explanation →

441

MCQmedium

A Pod has an init container that writes a configuration file, and the main container reads that file. The init container runs successfully, but the main container fails with 'file not found'. What is the most likely cause?

A.The init container wrote the file to a different volume than the one mounted in the main container.

B.The main container restarted and the init container did not rerun.

C.The main container's command is incorrect.

D.The init container did not complete before the main container started.

AnswerA

Without a shared volume, the main container cannot see the init container's files.

Why this answer

Option B is correct. Init containers and main containers must share a volume to exchange data; otherwise, the init container's filesystem is not accessible to the main container. Option A is incorrect because init containers always run to completion before main containers start.

Option C is incorrect because the main container's command is not the issue. Option D is incorrect because restarts do not affect file existence if the init container succeeded.

Full explanation →

442

Multi-Selecthard

You have a multi-node Kubernetes cluster. After upgrading the kubelet on a worker node, the node remains in 'NotReady' state. Which TWO actions should you take to troubleshoot? (Choose TWO.)

Select 2 answers

A.Check the node conditions using 'kubectl describe node <node-name>'

B.Check the pod logs on the node

C.Check the kubelet service status on the node using 'systemctl status kubelet'

D.Check the kube-apiserver logs on the control plane

E.Reboot the node

AnswersA, C

This provides details on node status, including conditions like Ready.

Why this answer

Option A is correct because 'kubectl describe node <node-name>' shows node conditions, including the 'Ready' status and any underlying issues like 'NetworkUnavailable', 'MemoryPressure', or 'KubeletNotReady'. This command provides a high-level view of why the node is NotReady, such as a kubelet version mismatch or resource exhaustion. It is the standard first step in diagnosing node health.

Exam trap

The trap here is that candidates often jump to checking the kube-apiserver logs (Option D) or rebooting (Option E) instead of focusing on the node's local kubelet service, which is the direct source of the NotReady state.

Full explanation →

443

Multi-Selectmedium

You need to check the status of control plane components. Which TWO commands are appropriate?

Select 2 answers

A.kubectl get pods -n kube-system

B.systemctl status kube-apiserver

C.kubectl get componentstatuses

D.top -u kube

E.systemctl list-units --type=service

AnswersA, B

Shows pods for control plane components if running as static pods.

Why this answer

systemctl status kube-apiserver (B) and kubectl get pods -n kube-system (C) are standard methods. 'kubectl get componentstatuses' (A) is deprecated. 'systemctl list-units' (D) lists all units but is not targeted. 'top' (E) shows processes but not component health.

Full explanation →

444

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete and recreate the pod to clear the crash loop

D.Delete the namespace and redeploy all workloads

AnswerA

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

Full explanation →

445

MCQhard

You have a Kubernetes cluster with a single control-plane node and multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0. Which sequence of steps is correct?

A.Upgrade all worker nodes first, then upgrade the control plane

B.Drain all nodes simultaneously, upgrade the control plane, then upgrade worker nodes

C.Upgrade the control plane first, then drain each worker node, upgrade the kubelet and kube-proxy, then uncordon

D.Upgrade the control plane and worker nodes at the same time

AnswerC

This is the correct sequence: control plane first, then worker nodes with drain/upgrade/uncordon.

Why this answer

The upgrade procedure requires upgrading the control plane first, then draining and upgrading each worker node. Draining a node before upgrading ensures that pods are rescheduled gracefully.

Full explanation →

446

MCQmedium

A node shows status NotReady. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active (running). What is the next most likely step to diagnose the issue?

A.Restart the kubelet with systemctl restart kubelet

B.Check the container runtime status

C.Check kubelet logs with journalctl -u kubelet

D.Reboot the node

AnswerC

Logs can show why the kubelet reports NotReady, such as network issues or node pressure.

Why this answer

Even if the kubelet is running, it may be unhealthy. Checking the kubelet logs with 'journalctl -u kubelet' can reveal errors such as network plugin failures or node pressure.

Full explanation →

447

MCQmedium

You run 'kubectl get pods' and see a pod with status 'CrashLoopBackOff'. You check the logs with 'kubectl logs <pod> --previous' and see: 'Error: unable to connect to database at db-svc:5432 (connection refused)'. What is the most likely cause?

A.The pod's liveness probe is misconfigured

B.The pod's container image is missing

C.The database service is not running or is unreachable

D.The pod has a memory limit that is too low

AnswerC

Connection refused indicates the database service is not accepting connections on that port.

Why this answer

Option A is correct. Connection refused means the database service is not listening on port 5432, likely because it is not running or the service endpoint is incorrect. Options B, C, and D cause different errors.

Full explanation →

448

MCQeasy

What is the purpose of the 'kubeadm reset' command?

A.To restart the kubelet service

B.To undo the effects of kubeadm init or kubeadm join on a node

C.To upgrade the cluster to a newer version

D.To add a new node to the cluster

AnswerB

This is the correct description of 'kubeadm reset'.

Why this answer

The 'kubeadm reset' command is designed to revert a node back to its pre-'kubeadm init' or pre-'kubeadm join' state. It cleans up all cluster-related configuration, certificates, and etcd data (if running on the control plane), effectively removing the node from the cluster and allowing it to be re-initialized or re-joined cleanly.

Exam trap

The trap here is that candidates confuse 'kubeadm reset' with a simple service restart or a node addition command, but it is specifically a destructive cleanup that undoes the entire initialization or join process, not a maintenance or upgrade tool.

How to eliminate wrong answers

Option A is wrong because 'kubeadm reset' does not restart the kubelet service; restarting the kubelet is done via 'systemctl restart kubelet' and is unrelated to resetting cluster state. Option C is wrong because upgrading a cluster is performed using 'kubeadm upgrade plan' and 'kubeadm upgrade apply', not 'kubeadm reset', which is destructive and removes cluster data. Option D is wrong because adding a new node is done with 'kubeadm join', while 'kubeadm reset' is used to remove a node from the cluster, not add one.

Full explanation →

449

MCQhard

You have a NetworkPolicy that selects pods with label 'app: db'. The policy has an ingress rule allowing traffic from pods with label 'app: frontend'. A pod with label 'app: frontend' is in a different namespace. No namespaceSelector is specified in the ingress rule. Will traffic from that pod be allowed?

A.Yes, because podSelector selects pods across all namespaces

B.No, because NetworkPolicy only works within the same namespace

C.Yes, because all ingress traffic is allowed by default

D.No, because the frontend pod is in a different namespace and no namespaceSelector is specified

AnswerD

To allow traffic from another namespace, you must include a namespaceSelector.

Why this answer

When no namespaceSelector is specified, the rule applies only to pods in the same namespace as the NetworkPolicy.

Full explanation →

450

Multi-Selectmedium

Which THREE of the following are valid ways to provide storage to a pod in Kubernetes?

Select 3 answers

A.hostPath

B.emptyDir

C.AWS Elastic Block Store (EBS) directly

D.Docker volume

E.PersistentVolumeClaim

AnswersA, B, E

hostPath mounts a file or directory from the host node's filesystem into the pod.

Why this answer

A is correct because `hostPath` mounts a file or directory from the host node's filesystem into a pod, allowing the pod to access persistent data stored on the node. This is a valid Kubernetes volume type defined in the PodSpec, commonly used for accessing host-level logs or configuration files, though it lacks portability across nodes.

Exam trap

The trap here is that candidates may confuse Docker volumes (a legacy container runtime concept) with Kubernetes volumes, or assume cloud provider storage like EBS can be directly specified in a pod definition without a PVC or CSI driver.

Full explanation →

Page 6 of 14

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Practice CKA by domain

Target a specific domain to shore up weak areas.

Cluster Architecture, Installation and Configuration Services and Networking Workloads and Scheduling Storage Troubleshooting Cluster Architecture, Installation & Configuration Workloads & Scheduling Services & Networking

See all domains with question counts →