Certified Kubernetes Administrator CKA CKA Questions 76–150 | Page 2/5

MCQmedium

You run `kubectl get pods` and get an error: 'error: You must be logged in to the server (Unauthorized)'. What is the most likely cause?

A.The kubeconfig file is missing or invalid.

B.The API server is not running.

C.The pod does not exist.

D.The namespace does not exist.

AnswerA

The error "error you must be logged in to the server (Unauthorized)" or similar, which is implied by the truncated prompt, directly indicates an authentication failure. This occurs when kubectl cannot successfully present valid credentials to the Kubernetes API server, most commonly because the kubeconfig file is either missing, corrupted, or contains incorrect cluster addresses, user certificates, or authentication tokens. Without a valid kubeconfig, the client cannot establish an authenticated session.

Why this answer

The error 'You must be logged in to the server (Unauthorized)' indicates that the kubectl client successfully reached the API server, but the request was rejected because the client's credentials (typically from the kubeconfig file) are missing, expired, or invalid. The kubeconfig file contains the cluster, user, and context information required for authentication; if it is misconfigured or not present, kubectl cannot authenticate and returns this specific HTTP 401 Unauthorized error.

Exam trap

The trap here is that candidates confuse authentication errors (401 Unauthorized) with connectivity errors (connection refused) or authorization errors (403 Forbidden), leading them to incorrectly suspect the API server is down or a resource is missing.

How to eliminate wrong answers

Option B is wrong because if the API server were not running, kubectl would return a connection refused or timeout error (e.g., 'Unable to connect to the server'), not an authentication error. Option C is wrong because the error occurs before any pod-specific operation; the client cannot even list pods due to authentication failure, so the existence of a pod is irrelevant. Option D is wrong because the error is about authentication, not authorization to a namespace; a missing namespace would cause a different error like 'namespace not found' or 'the server could not find the requested resource', not an Unauthorized response.

Full explanation →

MCQmedium

An application requires a persistent volume that can be shared across multiple Pods running on different nodes, with read-write access from all Pods simultaneously. Which access mode should be specified in the PersistentVolumeClaim?

A.ReadWriteOncePod

B.ReadOnlyMany

C.ReadWriteOnce

D.ReadWriteMany

AnswerD

ReadWriteMany (RWX) is the access mode that allows the volume to be mounted as read-write on many nodes simultaneously, enabling any number of Pods across the cluster to access it concurrently. This matches the requirement of a persistent volume that can be shared: all replicas can read and write the same data without a single-node limitation. Storage backends like NFS, SMB, or certain cloud volumes support RWX.

Why this answer

The correct access mode is ReadWriteMany (RWX), which allows the volume to be mounted as read-write by multiple Pods across different nodes simultaneously. This matches the requirement for shared concurrent read-write access from all Pods.

Exam trap

The trap here is that candidates often confuse ReadWriteMany with ReadWriteOnce, assuming that 'once' means 'one Pod' rather than 'one node', or they forget that ReadOnlyMany does not grant write access despite allowing multi-Pod mounting.

How to eliminate wrong answers

Option A is wrong because ReadWriteOncePod restricts the volume to a single Pod on a single node, preventing sharing. Option B is wrong because ReadOnlyMany allows multiple Pods to mount the volume but only in read-only mode, not read-write. Option C is wrong because ReadWriteOnce allows only a single node to mount the volume as read-write, blocking multi-node sharing.

Full explanation →

MCQmedium

You want to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates a ClusterIP Service?

A.kubectl expose deployment web --port=80 --type=ClusterIP

B.kubectl create deployment web --image=nginx --port=80

C.kubectl run web --image=nginx --port=80

D.kubectl create service clusterip web --tcp=80:80

AnswerA

`kubectl expose deployment web --port=80 --type=ClusterIP` is the canonical imperative command for exposing a Deployment as a Service. It reads the Deployment's pod selector (e.g., `app=web`), creates a ClusterIP Service named `web` with `port=80`, and sets the Service's targetPort to the same value unless overridden. This automatically gains an Endpoints object pointing at the Deployment's healthy pods, which is exactly what "exposing" a Deployment means on the internal cluster network.

Why this answer

`kubectl expose deployment web --port=80 --type=ClusterIP` creates a ClusterIP Service that exposes the Deployment named 'web' on port 80 internally within the cluster. The `--type=ClusterIP` is the default service type, making this command explicitly create a ClusterIP Service, which is only reachable from inside the Kubernetes cluster.

Exam trap

The trap here is that candidates may think `kubectl create service clusterip` is the correct way to expose an existing Deployment, but it creates an orphaned Service without linking to the Deployment's Pods, whereas `kubectl expose` correctly derives the selector from the Deployment.

How to eliminate wrong answers

Option B is wrong because `kubectl create deployment web --image=nginx --port=80` creates a Deployment, not a Service; it does not expose the Deployment as a ClusterIP Service. Option C is wrong because `kubectl run web --image=nginx --port=80` creates a Pod (or a Deployment in newer versions), not a Service, and does not create a ClusterIP Service. Option D is wrong because `kubectl create service clusterip web --tcp=80:80` creates a ClusterIP Service but it is not linked to the existing Deployment 'web'; it creates a standalone Service without selecting the Pods of that Deployment, so it does not expose the Deployment as intended.

Full explanation →

MCQeasy

Which command shows all events in the cluster, sorted by timestamp?

A.kubectl logs --all-namespaces [wrong]

B.kubectl top events [wrong]

C.kubectl describe events [wrong]

D.kubectl get events -A --sort-by='.metadata.creationTimestamp'

Why this answer

To retrieve all events across the entire cluster, the `-A` or `--all-namespaces` flag must be used. The correct command is `kubectl get events -A --sort-by='.metadata.creationTimestamp'`. The `--sort-by` flag uses a JSONPath expression to order the output based on the creation timestamp of the events.

Exam trap

Candidates often forget that `kubectl get events` is namespace-scoped by default and will only return events for the active namespace unless `-A` or `--all-namespaces` is explicitly provided.

How to eliminate wrong answers

Option A is wrong because `kubectl logs --all-namespaces` retrieves container logs, not cluster events; logs are output from containers, while events are Kubernetes API objects recording state changes. Option B is wrong because `kubectl top events` is not a valid kubectl command; `kubectl top` is used for resource usage metrics (nodes/pods), not events. Option C is wrong because `kubectl describe events` shows detailed information about events but does not sort them by timestamp; it displays events in a default order (often by last timestamp) and is not designed for sorted output.

Full explanation →

Multi-Selectmedium

Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod? (Select TWO.)

Select 2 answers

A.Using envFrom with secretRef

B.Using env field with configMapKeyRef directly

C.Using envFrom with configMapRef

D.Mounting the ConfigMap as a volume, which automatically sets environment variables

E.Using env field with valueFrom and configMapKeyRef

AnswersC, E

Using envFrom with configMapRef is a valid and straightforward way to expose all key-value pairs from a ConfigMap as environment variables. The configMapRef field inside envFrom specifies a source ConfigMap by name, and Kubernetes populates every entry from that ConfigMap into the container's environment. This is ideal when you want to inject multiple variables without listing each key individually, though you may still override specific keys using the env field.

Why this answer

`envFrom` with `configMapRef` allows you to inject all key-value pairs from a ConfigMap as environment variables into a pod, which is a concise way to expose ConfigMap data without specifying each key individually. This is a native Kubernetes feature that automatically creates environment variables for each entry in the ConfigMap.

Exam trap

The trap here is that candidates confuse `envFrom` with `configMapRef` (which injects all keys) with the `env` field using `valueFrom` and `configMapKeyRef` (which injects a single key), and they may also mistakenly think mounting a ConfigMap as a volume sets environment variables, when it actually creates files.

Full explanation →

MCQmedium

A user creates a PersistentVolumeClaim with a storage class 'ssd' that does not exist in the cluster. What will happen when the PVC is created?

A.The PVC will be deleted automatically after a timeout.

B.The PVC will be automatically bound to any available PV.

C.The PVC will remain in Pending state.

D.The cluster will create the storage class automatically.

AnswerC

When a PersistentVolumeClaim (PVC) is created referencing a StorageClass that does not exist within the cluster, the dynamic provisioning mechanism cannot proceed. The Kubernetes control plane is unable to locate a provisioner associated with the specified, non-existent StorageClass to create a new PersistentVolume (PV). Consequently, the PVC will remain in a `Pending` state indefinitely, waiting for a matching PV to become available or for the specified StorageClass to be created.

Why this answer

When a PersistentVolumeClaim (PVC) references a StorageClass that does not exist in the cluster, the PVC cannot be dynamically provisioned because the provisioner associated with that StorageClass is missing. Without a matching StorageClass, the system cannot create a new PersistentVolume (PV) for the PVC, and since no existing PV matches the claim (or the PVC is set to use dynamic provisioning), the PVC will remain in a Pending state indefinitely until the StorageClass is created or the PVC is deleted.

Exam trap

The trap here is that candidates often assume Kubernetes will fall back to a default StorageClass or automatically bind to an existing PV, but the system strictly requires the specified StorageClass to exist for dynamic provisioning and will not bypass this check.

How to eliminate wrong answers

Option A is wrong because PVCs are not automatically deleted after a timeout; they remain in Pending state until the underlying issue (missing StorageClass) is resolved or the PVC is manually deleted. Option B is wrong because a PVC that specifies a non-existent StorageClass cannot be bound to any available PV unless there is a PV that exactly matches the PVC's storage class label (which would require the StorageClass to exist), and the default binding behavior does not override a missing StorageClass. Option D is wrong because Kubernetes does not automatically create StorageClasses; they must be explicitly defined by a cluster administrator, and the system will not generate a StorageClass on the fly.

Full explanation →

MCQhard

You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?

A.Check if the kube-proxy is running on the node hosting pod-b

B.Check if a NetworkPolicy exists that denies ingress traffic to pod-b from namespace 'foo'

C.Check if the container runtime is Docker

D.Check if the DNS resolution for pod-b's service is correct

AnswerB

A NetworkPolicy is a namespaced Kubernetes resource that acts as a pod-level firewall, and if cluster networking is configured with a CNI that enforces it, any ingress rule can explicitly deny traffic from pods in other namespaces. The default behavior is allow-all only when no NetworkPolicy selects the pod; once one exists, the default becomes deny for anything not matched by its rules. If a policy selects pod-b and its ingress list does not include namespace 'foo' or a matching podSelector, it will silently drop the TCP SYN packets from pod-a, making the port 5432 connection time out or refuse while the service IP ping still succeeds.

Why this answer

Since pod-a can reach the Kubernetes service IP, the issue is likely a NetworkPolicy that denies ingress traffic from namespace 'foo' to pod-b on port 5432. NetworkPolicies can restrict cross-namespace traffic. Options A, C, and D are less likely because kube-proxy, container runtime, and DNS are not the primary suspects when connectivity to the service IP works.

Full explanation →

MCQhard

A user reports that they cannot access a Service of type ClusterIP from within the cluster. The Service selects pods that are running and responding. Which of the following is the MOST likely cause?

A.The Service's port does not match the container's containerPort

B.The Service type is NodePort instead of ClusterIP

C.The Service's targetPort does not match the container's containerPort

D.The Service selector does not match any pod labels

AnswerC

The `Service.spec.targetPort` is the critical configuration that directs incoming traffic from the Service to a specific port on the Pod's containers. If this `targetPort` value does not precisely match the port number or named port that the application inside the container is actually listening on, the traffic will be misrouted within the Pod. Consequently, the application will not receive the incoming requests, leading to the user experiencing an inaccessible service.

Why this answer

The Service's `targetPort` must match the `containerPort` defined in the pod's container spec. Even if the pods are running and responding, if the `targetPort` points to a different port than the one the container is listening on, traffic will be forwarded to the wrong port and the connection will fail. The `port` field on the Service is the port the Service itself listens on, while `targetPort` is the port on the pod where traffic is actually sent.

Exam trap

The trap here is that candidates confuse the Service's `port` (the cluster-facing port) with the `targetPort` (the pod-facing port), and incorrectly assume the `port` must match the container's `containerPort`, leading them to choose Option A instead of C.

How to eliminate wrong answers

Option A is wrong because the Service's `port` does not need to match the container's `containerPort`; the `port` is the Service's own listening port, and traffic is forwarded to the `targetPort`. Option B is wrong because a Service of type NodePort still works for internal cluster access (it also gets a ClusterIP), so changing the type to NodePort would not cause a failure to access from within the cluster. Option D is wrong because the question explicitly states that the Service selects pods that are running and responding, meaning the selector matches the pod labels correctly.

Full explanation →

MCQmedium

You want to ensure that a pod only runs on nodes that have a GPU. Nodes with GPUs are labeled with 'gpu=true'. Which scheduling constraint should you use?

A.spec.nodeName: gpu-node

B.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution

C.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

D.spec.nodeSelector: { gpu: "true" }

AnswerD

The nodeSelector field provides a concise key-value map that the scheduler uses as a hard constraint for node selection. When you set nodeSelector to { gpu: "true" }, the scheduler will only place the pod on nodes that have the label gpu with the exact value "true". This is entirely label-driven, so it works across any number of GPU-enabled nodes, unlike nodeName, and it is the simplest declarative mechanism for an equality-based node label requirement, requiring no nested API structures.

Why this answer

`spec.nodeSelector` is the simplest and most direct way to constrain a pod to nodes with a specific label. By setting `gpu: "true"` in the nodeSelector, the scheduler will only place the pod on nodes that have that exact label key-value pair. This is the standard Kubernetes mechanism for node-level selection based on labels.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` or `podAffinity`, thinking the more complex option is always better, but the CKA exam tests your ability to choose the simplest correct solution for a given requirement.

How to eliminate wrong answers

Option A is wrong because `spec.nodeName` forces the pod to run on a specific node by name, not by label, and it bypasses the scheduler entirely, which is not the intended use for selecting nodes with a GPU label. Option B is wrong because `podAffinity` is used to schedule pods relative to other pods (e.g., co-location), not to select nodes based on their labels. Option C is wrong because while `nodeAffinity` can also select nodes by label, it is a more complex and flexible construct; the question asks for a 'scheduling constraint' and the simplest correct answer is `nodeSelector`, not the more verbose affinity syntax.

Full explanation →

MCQmedium

You run 'kubectl get nodes' and see that one node is marked as 'NotReady'. Which component is likely failing on that node?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.container runtime (e.g., containerd)

AnswerC

The kubelet is the primary agent that runs on each worker node and is responsible for registering the node with the API server, ensuring that containers are running in a Pod, and continuously monitoring the node's health and resources. It reports this critical information back to the Kubernetes control plane. If the kubelet itself fails, stops communicating with the API server, or cannot perform its duties (e.g., due to resource exhaustion or internal errors), the control plane will mark that specific node as NotReady because it can no longer receive reliable status updates or manage pods on it.

Why this answer

The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and reporting its status via periodic heartbeats (NodeStatus updates). When a node is marked as 'NotReady', it means the kubelet has failed to send these heartbeats to the control plane (specifically, the node controller) within the --node-monitor-grace-period (default 40s), indicating the kubelet process is likely down, unresponsive, or misconfigured.

Exam trap

The trap here is that candidates often confuse the container runtime (e.g., containerd) as the direct cause of node unreadiness, but the kubelet is the component that reports the node condition, and a runtime failure would manifest as a kubelet-level error (e.g., 'runtime network not ready') rather than a missing heartbeat.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node to manage network rules (e.g., iptables/IPVS) for Services; its failure would cause connectivity issues to pods/services but does not affect the node's readiness status reported by the kubelet. Option B is wrong because kube-scheduler is a control plane component that runs on the master node(s) and is responsible for assigning pods to nodes; it does not run on worker nodes and has no role in reporting node health. Option D is wrong because while a failing container runtime (e.g., containerd, CRI-O) can prevent pods from starting and may eventually cause the kubelet to mark the node as NotReady, the immediate and direct cause of the 'NotReady' status is the kubelet's failure to report its heartbeat; the kubelet itself is the component that detects runtime failures and updates the node condition accordingly.

Full explanation →

MCQmedium

You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?

A.Add nodeAffinity to prefer node1 and node2.

B.Create a PodDisruptionBudget with minAvailable: 1.

C.Assign a high priority class to the database Pod.

D.Increase the resource requests to match the limits.

AnswerC

Assigning a high priority class to the database Pod is the most effective solution for ensuring critical workloads are scheduled promptly. When the scheduler attempts to place a high-priority Pod and cannot find a node with sufficient resources, it will actively preempt (evict) lower-priority Pods from existing nodes to free up the necessary capacity. This mechanism directly addresses resource contention, significantly reducing the scheduling delay for essential applications like a database.

Why this answer

Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.

Exam trap

CNCF often tests the distinction between disruption budgets (which prevent eviction) and priority/preemption (which ensure rescheduling after eviction), leading candidates to mistakenly choose PDB when the real issue is resource contention after eviction.

How to eliminate wrong answers

Option A is wrong because nodeAffinity with a 'prefer' rule is a soft scheduling preference, not a guarantee; during eviction, the scheduler may still place the Pod on a smaller node if node1/node2 are full, leading to scheduling failures. Option B is wrong because a PodDisruptionBudget (PDB) with minAvailable: 1 only protects against voluntary disruptions (e.g., node drains) by preventing eviction if it would violate the budget, but it does not help with resource availability after eviction; the Pod still cannot be scheduled if no node has enough free resources. Option D is wrong because increasing resource requests to match limits (4 CPU, 8Gi memory) would make the Pod even harder to schedule, as it would require more resources than the smaller nodes (node3-node5) can provide, worsening the problem.

Full explanation →

MCQeasy

Which of the following service types exposes a service on a static port on each node's IP address?

A.ExternalName

B.NodePort

C.LoadBalancer

D.ClusterIP

AnswerB

NodePort exposes the service on a static port on each node's IP address.

Why this answer

NodePort is the correct answer because it exposes a service on a static port (in the range 30000-32767) on every node's IP address. When you create a NodePort service, Kubernetes allocates a port from that range and opens that port on all nodes, forwarding traffic to the service's ClusterIP and then to the pods.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking that LoadBalancer also exposes a static port on each node, but LoadBalancer actually relies on a cloud provider's external load balancer and does not automatically open a port on every node's IP.

How to eliminate wrong answers

Option A is wrong because ExternalName maps a service to a DNS name (via CNAME record) and does not expose any port on node IPs. Option C is wrong because LoadBalancer exposes the service via a cloud provider's load balancer (e.g., ELB) and assigns an external IP, not a static port on each node's IP. Option D is wrong because ClusterIP exposes the service only on a cluster-internal IP, reachable only within the cluster, not on node IPs.

Full explanation →

MCQhard

An administrator is setting up RBAC to allow a CI/CD pipeline to create and delete pods only in the 'ci' namespace. Which combination of resources should be created?

A.Role and RoleBinding

B.ClusterRole and RoleBinding

C.ClusterRole and ClusterRoleBinding

D.Role and ClusterRoleBinding

AnswerA

This combination is the correct and most granular approach for granting permissions within a specific namespace. A `Role` defines a set of permissions (e.g., create pods, list deployments) that are strictly confined to the namespace where the `Role` is created. Subsequently, a `RoleBinding` links this namespace-scoped `Role` to a specific subject, such as a service account used by a CI/CD pipeline, thereby granting those defined permissions exclusively within that particular namespace. This adheres to the principle of least privilege by preventing unintended access to other parts of the cluster.

Why this answer

A Role and RoleBinding are the correct combination because the CI/CD pipeline needs to create and delete pods only within the 'ci' namespace. A Role defines permissions scoped to a specific namespace, and a RoleBinding grants those permissions to a user or service account within that same namespace. This ensures the pipeline cannot affect resources in other namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole is always needed for any pipeline or service account, but for namespace-scoped resources, a Role and RoleBinding are sufficient and more secure, and the exam tests understanding of scope versus permissions.

How to eliminate wrong answers

Option B is wrong because a ClusterRole is cluster-scoped and, when used with a RoleBinding, can grant permissions across namespaces if the ClusterRole references cluster-scoped resources; however, for namespace-scoped resources like pods, a Role is more restrictive and appropriate. Option C is wrong because a ClusterRoleBinding grants permissions cluster-wide, which would allow the pipeline to create and delete pods in all namespaces, violating the requirement to restrict access to the 'ci' namespace only. Option D is wrong because a Role cannot be bound with a ClusterRoleBinding; a RoleBinding is required to bind a Role to a subject within a namespace.

Full explanation →

MCQmedium

A StorageClass named 'fast-ssd' uses the provisioner 'kubernetes.io/gce-pd' and has volumeBindingMode: WaitForFirstConsumer. A PVC 'my-pvc' requests 100Gi storage from this StorageClass. A pod using the PVC is scheduled to a node in zone 'us-central1-a'. When is the PV provisioned?

A.When the pod is scheduled to a node

B.Immediately when the PVC is created

C.When the pod starts running

D.The PV is never provisioned automatically; it must be pre-created

AnswerA

With volumeBindingMode: WaitForFirstConsumer, a PVC remains unbound and unprovisioned until the Kubernetes scheduler selects a node for a pod that references the PVC. At that scheduling moment, the scheduler evaluates the pod's storage topology requirements (such as zone or region) as a hard constraint, and only then does the storage backend dynamically provision the PV and bind it to the PVC. This is why the correct answer is 'when the pod is scheduled to a node,' not any earlier or later point in the pod lifecycle.

Why this answer

The StorageClass 'fast-ssd' has volumeBindingMode set to WaitForFirstConsumer. This mode delays volume binding and provisioning until a pod using the PVC is scheduled to a node. When the pod is scheduled to a node in zone 'us-central1-a', the scheduler triggers the provisioning of a PV in that specific zone, ensuring the volume is created in the same zone as the pod.

Exam trap

The trap here is that candidates often confuse 'when the pod starts running' with 'when the pod is scheduled', but the PV provisioning is triggered by the scheduling decision, not by the container runtime starting the pod.

How to eliminate wrong answers

Option B is wrong because with WaitForFirstConsumer, provisioning does not happen immediately when the PVC is created; it is deferred until a pod consumes the PVC. Option C is wrong because provisioning occurs when the pod is scheduled to a node, not when the pod starts running; the PV is bound and provisioned during the scheduling phase, before the pod actually starts. Option D is wrong because the PV is provisioned automatically by the dynamic provisioner (kubernetes.io/gce-pd) when the WaitForFirstConsumer condition is met; it does not need to be pre-created.

Full explanation →

MCQmedium

A pod needs to share data between two containers during their lifecycle, but the data does not need to persist after the pod is deleted. Which volume type is most appropriate?

A.emptyDir

B.PersistentVolumeClaim

C.hostPath

D.configMap

AnswerA

An emptyDir volume is provisioned when a Pod is assigned to a node, initially empty. It provides a temporary, shared directory accessible by all containers within that specific Pod, making it ideal for inter-container communication or temporary data storage. Crucially, its contents are deleted permanently when the Pod terminates, crashes, or is removed from the node, ensuring data isolation and cleanup. This ephemeral nature perfectly suits the requirement for data sharing that only needs to persist for the duration of the pod's existence.

Why this answer

The emptyDir volume type is the correct choice because it creates an empty directory when a pod is assigned to a node, and it exists as long as the pod runs. Containers within the same pod can read and write to this shared volume, making it ideal for temporary data exchange (e.g., sidecar log shipping or file-based IPC). When the pod is deleted, the emptyDir and its contents are permanently removed, matching the requirement that data does not need to persist.

Exam trap

The trap here is that candidates often confuse emptyDir with hostPath, thinking both are ephemeral, but hostPath data persists on the node even after the pod is deleted, which violates the 'no persistence after pod deletion' requirement.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it requests persistent storage that outlives the pod's lifecycle, which contradicts the requirement that data does not persist after pod deletion. Option C (hostPath) is wrong because it mounts a file or directory from the host node's filesystem into the pod, making data persist on the node even after the pod is deleted, and it also introduces node-specific coupling and potential security risks. Option D (configMap) is wrong because it is designed to inject configuration data (e.g., key-value pairs, files) into containers, not to serve as a writable shared volume for runtime data exchange between containers.

Full explanation →

MCQhard

You want to configure NetworkPolicy to allow ingress traffic only from pods with label 'role: frontend' in the same namespace. Which podSelector should be in the ingress rule?

A.podSelector in spec.podSelector

B.podSelector in spec.ingress.from

C.podSelector in spec.egress.to

D.namespaceSelector in spec.ingress.from

AnswerB

Within an ingress rule, the from field accepts one or more sources, and a podSelector there selects the exact source pods whose traffic to the selected destination pods will be permitted. This is the core mechanism for allowing ingress from specific pods, as it matches pods by labels in the same namespace unless combined with a namespaceSelector. Without this field, the ingress rule has an empty from, which means no sources are allowed, aligning with the default-deny behavior.

Why this answer

In a Kubernetes NetworkPolicy, the `spec.ingress.from` field specifies the sources allowed to send ingress traffic. To match pods with a specific label within the same namespace, you use a `podSelector` under `from`. This selects pods based on their labels, and since no `namespaceSelector` is specified, it defaults to the same namespace as the NetworkPolicy.

Exam trap

The trap here is that candidates often confuse `spec.podSelector` (which selects the target pods the policy applies to) with the `podSelector` inside `ingress.from` (which selects the source pods allowed to send traffic), leading them to pick Option A.

How to eliminate wrong answers

Option A is wrong because `spec.podSelector` defines which pods the NetworkPolicy applies to (the target pods), not the source of ingress traffic. Option C is wrong because `spec.egress.to` is used for egress rules, not ingress; it controls outbound traffic destinations. Option D is wrong because a `namespaceSelector` selects entire namespaces, not pods with a specific label within the same namespace; it would allow traffic from any pod in the selected namespace, not just those with label 'role: frontend'.

Full explanation →

MCQeasy

Which of the following Service types exposes a Service on a static port on each node's IP address?

A.LoadBalancer

B.ExternalName

C.NodePort

D.ClusterIP

AnswerC

A NodePort Service allocates a static port from the default range 30000–32767 on every cluster node, binding that port to the Service’s ClusterIP. This directly satisfies the stem’s requirement for a static port exposed on each node’s IP address, distinguishing it from ClusterIP (internal only) and LoadBalancer (cloud‑provisioned external IP).

Why this answer

NodePort is the Service type that exposes a Service on a static port (in the range 30000-32767) on each node's IP address. When a NodePort Service is created, Kubernetes allocates a port from that range and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the pods. This allows external traffic to reach the Service by hitting any node's IP address and the allocated NodePort.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking that LoadBalancer also exposes a static port on each node, but LoadBalancer actually delegates external access to an external load balancer and does not guarantee a static port on every node's IP.

How to eliminate wrong answers

Option A is wrong because a LoadBalancer Service provisions an external load balancer (e.g., from a cloud provider) and assigns a public IP, but it does not expose the Service on a static port on each node's IP address; it relies on the load balancer to distribute traffic to the NodePort or ClusterIP. Option B is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any port or IP address on nodes; it is used for internal DNS aliasing. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP address, which is not reachable from outside the cluster and does not involve a static port on each node's IP.

Full explanation →

Multi-Selecthard

You are troubleshooting a node that is 'NotReady'. Which THREE of the following are possible causes? (Choose three.)

Select 3 answers

A.The kubelet cannot contact the API server

B.The kubelet service is stopped

C.The node has disk pressure

D.A pod on the node is consuming excessive memory

E.The network plugin (e.g., Calico, Flannel) is not running

AnswersA, B, E

The kubelet is responsible for registering the node with the API server and continuously reporting its health and status. If the kubelet loses its ability to communicate with the API server, it cannot send its periodic heartbeats or update the node's conditions. After a default timeout period, the control plane will mark the node as NotReady because it has stopped receiving updates, indicating a potential issue with the node's availability or connectivity.

Why this answer

The kubelet is the primary node agent that communicates with the API server to report node status, heartbeats, and pod lifecycle events. If the kubelet cannot reach the API server (e.g., due to network partition, TLS certificate issues, or API server downtime), it cannot send the periodic NodeStatus updates, and the control plane marks the node as 'NotReady' after the `node-monitor-grace-period` (default 40 seconds) expires.

Exam trap

The trap here is that candidates confuse node conditions like 'DiskPressure' or 'MemoryPressure' with the 'NotReady' status, but these conditions do not change the 'Ready' status unless the kubelet itself fails to report.

Full explanation →

MCQhard

A pod has resource requests: cpu: 250m, memory: 128Mi. The node has 2 CPU cores and 4Gi memory. What is the maximum number of such pods that can fit on this node based solely on CPU requests?

A.32

B.16

C.4

D.8

AnswerD

8 pods each requesting 250m CPU sum to exactly 2000m, matching the node's allocatable CPU. The scheduler can place all 8 because the total request does not exceed capacity, and CPU requests are not burstable at this level—every pod is guaranteed its full 250m. This is the maximum number that can be scheduled based on CPU alone, since adding one more 250m request would require 2250m > 2000m.

Why this answer

The node has 2 CPU cores, which equals 2000m (2000 milliCPU). Each pod requests 250m CPU. Dividing 2000m by 250m gives 8 pods.

This calculation assumes no other pods or system overhead, and only considers CPU requests, not limits or other resources.

Exam trap

The trap here is that candidates may incorrectly convert 2 CPU cores to 2000m (which is correct) but then misapply the division, or confuse milliCPU with memory units (e.g., thinking 128Mi memory limits CPU count), leading to answers like 16 or 32.

How to eliminate wrong answers

Option A is wrong because 32 would require 8000m CPU (32 * 250m), but the node only has 2000m, so this answer incorrectly multiplies by memory or uses a wrong conversion. Option B is wrong because 16 would require 4000m CPU (16 * 250m), which is double the node's capacity, likely confusing 2 cores with 4 cores or misreading the request as 125m. Option C is wrong because 4 would require only 1000m CPU (4 * 250m), which is half the node's capacity, possibly from mistaking 2 cores as 2000m but dividing by 500m or thinking each core can run only one pod.

Full explanation →

MCQhard

You are troubleshooting a pod that cannot start. Running 'kubectl describe pod' shows the event: 'Failed to pull image "myregistry.io/myapp:1.0": rpc error: code = Unknown desc = Error response from daemon: manifest for myregistry.io/myapp:1.0 not found'. What is the MOST likely cause?

A.The registry is unreachable due to network issues

B.The image tag '1.0' does not exist in the registry

C.The image registry requires authentication and the imagePullSecret is missing

D.The image has been deleted from the registry

AnswerB

The 'manifest not found' error explicitly indicates that the container runtime successfully contacted the image registry but could not locate the specific image manifest associated with the requested tag '1.0'. This means the registry confirmed its existence but reported that no image with that precise tag is available. This is the most direct and accurate interpretation of the given error message, signifying the tag itself is absent.

Why this answer

The error message 'manifest for myregistry.io/myapp:1.0 not found' indicates that the registry successfully received the pull request but could not locate the specific image tag '1.0'. This is a manifest lookup failure, not a connectivity or authentication issue. The most likely cause is that the tag '1.0' does not exist in the repository, either because it was never pushed or was removed.

Exam trap

The trap here is that candidates confuse 'manifest not found' with network or authentication errors, but the specific wording of the error message directly points to a missing tag in the registry, not connectivity or credentials.

How to eliminate wrong answers

Option A is wrong because network issues would produce a different error, such as 'dial tcp: lookup myregistry.io: no such host' or 'connection refused', not a manifest-not-found error. Option C is wrong because missing authentication would result in a 'denied: requested access to the resource is denied' or 'unauthorized: authentication required' error, not a manifest-not-found error. Option D is wrong because if the image had been deleted from the registry, the registry would typically still have the manifest metadata and would return a 'not found' for the blob, but the error specifically says 'manifest not found', which means the tag itself is missing—this is functionally the same as the tag never existing, but the phrasing 'deleted' implies the tag existed before, which is less likely given the exact error message; however, the most precise cause is that the tag does not exist in the registry's index.

Full explanation →

MCQmedium

Which of the following volume types provides ephemeral storage that shares the pod's lifecycle and is initially empty?

A.secret

B.emptyDir

C.configMap

D.hostPath

AnswerB

emptyDir is ephemeral and starts empty.

Why this answer

B is correct because an `emptyDir` volume is created empty when a Pod is assigned to a node and exists as long as that Pod is running. It provides ephemeral storage that shares the Pod's lifecycle, meaning it is deleted when the Pod is removed, and it is initially empty, making it ideal for scratch space, caching, or temporary data.

Exam trap

The trap here is that candidates often confuse `emptyDir` with `hostPath` or `configMap`, mistakenly thinking that any volume that is initially empty must be a `configMap` or that `hostPath` provides ephemeral storage, when in fact `emptyDir` is the only volume type that is both ephemeral and initially empty by design.

How to eliminate wrong answers

Option A is wrong because a `secret` volume is used to inject sensitive data (e.g., passwords, tokens) into a Pod, not for ephemeral storage; it is populated from the Kubernetes API and is not initially empty. Option C is wrong because a `configMap` volume provides configuration data from ConfigMap objects, not ephemeral storage; it is also pre-populated with key-value pairs and shares the Pod's lifecycle but is not initially empty. Option D is wrong because a `hostPath` volume mounts a file or directory from the host node's filesystem into the Pod, persisting beyond the Pod's lifecycle and not being initially empty; it is not ephemeral and does not share the Pod's lifecycle.

Full explanation →

MCQmedium

You need to expose multiple HTTP services on a single IP address with path-based routing. Which resource should you use?

A.Service of type ClusterIP

B.NetworkPolicy

C.Service of type NodePort

D.Ingress

AnswerD

Ingress is the standard Kubernetes API object for L7 HTTP routing, allowing you to define host- and path-based rules that direct traffic to multiple backend Services. A single Ingress controller receives external traffic on one IP (often via a load balancer) and routes each request to the appropriate Service based on the URL path. This exactly fulfills the requirement of exposing multiple HTTP services on a single IP address.

Why this answer

Ingress is the correct resource because it provides HTTP/HTTPS layer-7 routing to multiple services based on hostnames or paths, all exposed on a single IP address. Services of type ClusterIP, NodePort, or LoadBalancer operate at layer 4 and cannot perform path-based routing. An Ingress controller (e.g., NGINX, HAProxy) implements the rules defined in the Ingress resource to direct traffic to the appropriate backend services.

Exam trap

The trap here is that candidates confuse Ingress with Service types like NodePort or LoadBalancer, thinking those can handle HTTP routing, but they only provide layer-4 load balancing without any awareness of HTTP paths or hostnames.

How to eliminate wrong answers

Option A is wrong because a Service of type ClusterIP is only reachable within the cluster and does not provide external access or path-based routing. Option B is wrong because NetworkPolicy controls traffic flow between pods at the network layer (layer 3/4) and cannot expose services or perform HTTP path routing. Option C is wrong because a Service of type NodePort exposes a static port on each node's IP at layer 4 (TCP/UDP) and cannot route based on HTTP paths or hostnames.

Full explanation →

MCQmedium

You update a NetworkPolicy to add an egress rule. After applying, pods affected by the policy can no longer reach external IPs. What is the most likely reason?

A.The egress rule has a typo in the IP block

B.The pods are not running

C.NetworkPolicy egress rules deny all traffic by default unless explicitly allowed

D.The CNI plugin does not support egress rules

AnswerC

When a `NetworkPolicy` is applied to pods and includes an `egress` section, the default behavior for those pods' outbound traffic immediately switches from "allow all" to "deny all." Any egress traffic not explicitly matched by one of the `egress` rules within that policy will be dropped. Therefore, if the newly added egress rule does not explicitly permit the necessary external IPs, all external traffic will be blocked by default.

Why this answer

NetworkPolicy in Kubernetes follows a default-deny model for traffic. When any egress rule is added to a NetworkPolicy, it implicitly denies all egress traffic that is not explicitly allowed by that rule. Therefore, if the egress rule does not include a rule allowing traffic to external IPs (e.g., via an IPBlock or a namespace selector), those destinations become unreachable.

This is by design, as NetworkPolicies are additive whitelists.

Exam trap

The trap here is that candidates often assume egress rules are additive (i.e., they only allow traffic without affecting existing connectivity), but Kubernetes NetworkPolicy egress rules are whitelist-only, meaning any egress rule implicitly denies all other egress traffic.

How to eliminate wrong answers

Option A is wrong because a typo in the IP block would cause a mismatch, but the question states the pods can no longer reach external IPs at all, which is a broader symptom consistent with default-deny behavior, not a typo. Option B is wrong because if the pods were not running, they would not be able to reach any IPs at all, and the question implies they were previously able to reach external IPs before the update. Option D is wrong because most CNI plugins (e.g., Calico, Cilium, Weave) support egress rules; the CKA exam assumes a standard CNI that supports NetworkPolicy, and lack of support would typically cause no enforcement, not a sudden block.

Full explanation →

MCQeasy

You are a cluster administrator managing a production Kubernetes cluster that hosts a stateful application using StatefulSets with PersistentVolumeClaims (PVCs) backed by a cloud provider's persistent disk. A developer reports that a new pod in the StatefulSet is stuck in 'Pending' state. You describe the StatefulSet and see that it has 3 replicas. Two pods are Running, but the third pod (pod-2) is Pending. You check the PVC for pod-2 and see it is 'Pending'. The StorageClass uses 'WaitForFirstConsumer' volume binding mode. The node where pod-2 should run has sufficient resources. Other PVCs in the same namespace bound successfully. What is the most likely cause of the pending PVC and pod?

A.The PV that should bind to the PVC has a nodeAffinity that does not match any available node.

B.The CSI driver is not installed on the node where pod-2 is scheduled.

C.The PVC's requested storage size exceeds the available capacity in the cloud provider's quota.

D.The PVC's access mode is ReadWriteOnce, but the pod requires ReadWriteMany.

AnswerA

When a PersistentVolumeClaim (PVC) uses the WaitForFirstConsumer binding mode, the selection or provisioning of a PersistentVolume (PV) is delayed until a pod requiring that PVC is scheduled. If the selected PV has nodeAffinity rules that do not match the node where pod-2 was scheduled, the volume attachment will fail. This mismatch prevents the volume from being mounted, causing pod-2 to remain in a Pending state, unable to start its containers.

Why this answer

With 'WaitForFirstConsumer' volume binding mode, the PVC binding is deferred until a pod using it is scheduled. The PV that should bind to the PVC has a nodeAffinity that does not match any available node, preventing the scheduler from binding the PVC and scheduling the pod. This results in both the PVC and pod remaining in 'Pending' state, even though the node has sufficient resources.

Exam trap

The trap here is that candidates often assume a Pending PVC is always due to insufficient storage capacity or quota, ignoring the impact of volume binding modes and nodeAffinity constraints on scheduling.

How to eliminate wrong answers

Option B is wrong because the CSI driver must be installed on all nodes that can run pods using the CSI driver; if it were missing on the scheduled node, the pod would fail with a different error (e.g., 'FailedMount'), not remain Pending due to an unbounded PVC. Option C is wrong because if the requested storage size exceeded the cloud provider's quota, the PVC would likely fail with a specific error (e.g., 'ProvisioningFailed') rather than remain Pending, and other PVCs in the same namespace bound successfully, indicating quota is not the issue. Option D is wrong because ReadWriteOnce is the default access mode for most cloud persistent disks and is compatible with StatefulSet pods; ReadWriteMany would be required only if multiple pods need to write simultaneously to the same volume, which is not the case here.

Full explanation →

100

Multi-Selecthard

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

Select 2 answers

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

B.Apply a NetworkPolicy with empty podSelector and ingress rule allowing all

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

D.Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, ingress: [ { from: [ { podSelector: { matchLabels: { role: monitoring } } } ] } ]

E.Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, policyTypes: [Ingress], and no ingress rules

AnswersD, E

This allows ingress from monitoring pods.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse `namespaceSelector` with `podSelector` and think a namespace-level rule is sufficient to isolate traffic to specific pods, but without a `podSelector` in the ingress rule, all pods in the monitoring namespace are allowed, breaking isolation.

Full explanation →

101

MCQeasy

Which command creates a Job that runs a single pod to execute the command 'echo Hello'?

A.kubectl create job hello --image=busybox -- echo Hello

B.kubectl create cronjob hello --image=busybox -- echo Hello

C.kubectl create deployment hello --image=busybox -- echo Hello

D.kubectl run job hello --image=busybox -- echo Hello

AnswerA

The `kubectl create job` command is the correct imperative way to create a Kubernetes Job object named `hello`. It uses the busybox image and passes `echo Hello` as the container's command, and since a Job's default completion count is 1, the Job controller schedules one Pod that runs to successful exit. This Job-managed Pod is automatically restarted or recreated if it fails, fulfilling the requirement of a single Pod execution to completion.

Why this answer

`kubectl create job` is the dedicated command to create a Kubernetes Job object, which runs a pod to completion. The `--image=busybox` specifies the container image, and the `-- echo Hello` passes the command and its arguments to the container's entrypoint. This creates a non-repeating Job that executes the command once.

Exam trap

The trap here is that candidates confuse `kubectl create job` with `kubectl run` or `kubectl create cronjob`, mistakenly thinking a one-time task can be created with a deployment or cronjob syntax, or that `kubectl run` supports a 'job' subcommand.

How to eliminate wrong answers

Option B is wrong because `kubectl create cronjob` creates a CronJob, which schedules Jobs on a recurring basis, not a one-time Job. Option C is wrong because `kubectl create deployment` creates a Deployment, which manages a ReplicaSet to ensure a specified number of pods run continuously, not a single-run Job. Option D is wrong because `kubectl run job` is not a valid command; `kubectl run` can create a pod or deployment, but not a Job directly, and the syntax `kubectl run job` is incorrect.

Full explanation →

102

MCQhard

A pod cannot resolve a service DNS name. The cluster uses CoreDNS. Which of the following is the most likely cause if the pod's /etc/resolv.conf contains 'nameserver 10.96.0.10' and the CoreDNS pod is running?

A.The CoreDNS ConfigMap does not have the correct cluster domain.

B.The pod's DNS policy is set to 'Default'.

C.The CoreDNS pod is in CrashLoopBackOff.

D.The service's DNS name is misspelled.

AnswerA

CoreDNS's kubernetes plugin reads a ConfigMap (typically named 'coredns' in the kube-system namespace) to determine the cluster domain, usually 'cluster.local.' If the 'kubernetes' block in that ConfigMap specifies a mismatched or missing domain, CoreDNS will not append the correct search domain, so fully qualified service names like 'my-svc.my-ns.svc.cluster.local' will fail to resolve. Since the pod is running, a static misconfiguration in the ConfigMap is a primary suspect and directly explains the symptom.

Why this answer

If the CoreDNS ConfigMap does not specify the correct cluster domain (e.g., `cluster.local`), CoreDNS will not respond to queries for service DNS names within that domain. The pod's `resolv.conf` shows the correct ClusterIP of the CoreDNS service (10.96.0.10), and the CoreDNS pod is running, so the issue is likely a misconfiguration in the CoreDNS plugin settings, specifically the `kubernetes` plugin's `clusterDomain` parameter.

Exam trap

The trap here is that candidates assume a running CoreDNS pod and correct `nameserver` IP guarantee DNS resolution, overlooking that CoreDNS must be configured with the correct cluster domain to handle service DNS names.

How to eliminate wrong answers

Option B is wrong because setting the pod's DNS policy to 'Default' means the pod inherits the node's `/etc/resolv.conf`, which typically points to the cluster's DNS service (10.96.0.10) anyway, so it would not prevent DNS resolution. Option C is wrong because the question explicitly states the CoreDNS pod is running, so CrashLoopBackOff is not the cause. Option D is wrong because while a misspelled DNS name would cause resolution failure, the question asks for the most likely cause given the pod's resolv.conf is correct and CoreDNS is running; a configuration error in CoreDNS is a more systematic issue than a simple typo.

Full explanation →

103

MCQmedium

A user needs to deploy a pod that requires access to the Kubernetes API server from within the pod. Which resource should be used to provide authentication credentials automatically?

A.ServiceAccount

B.Secret

C.ConfigMap

D.ClusterRoleBinding

AnswerA

ServiceAccounts are automatically mounted as volumes in pods, providing a token for API authentication.

Why this answer

A ServiceAccount is the correct resource because Kubernetes automatically mounts a projected volume containing a JWT token into pods that use the default or a specified ServiceAccount. This token is used by the pod to authenticate against the Kubernetes API server, enabling secure in-cluster communication without manual credential management.

Exam trap

The trap here is that candidates often confuse authorization resources like ClusterRoleBinding with authentication mechanisms, or think that a generic Secret or ConfigMap can serve as an automatic credential provider, when in fact only a ServiceAccount provides the automated token injection and rotation required for in-cluster API access.

How to eliminate wrong answers

Option B is wrong because a Secret is a generic resource for storing sensitive data like passwords or tokens, but it does not automatically provide authentication credentials to a pod; you must explicitly mount or reference it, and it lacks the automatic token rotation and API server integration of a ServiceAccount. Option C is wrong because a ConfigMap is designed for non-sensitive configuration data (e.g., environment variables or config files) and cannot store or provide authentication credentials. Option D is wrong because a ClusterRoleBinding grants RBAC permissions to a subject (like a ServiceAccount or user) but does not itself provide authentication credentials; it is an authorization resource, not an authentication mechanism.

Full explanation →

104

MCQeasy

A node in your cluster is reporting 'NotReady' status. You log into the node and run 'systemctl status kubelet'. The kubelet service is not running. Which command should you use to start the kubelet and enable it to start on boot?

A.systemctl start --enable kubelet

B.systemctl enable kubelet

C.systemctl enable --now kubelet

D.systemctl start kubelet

AnswerC

This is the correct command to resolve the `NotReady` status and ensure future stability. The `systemctl enable --now kubelet` command not only configures the `kubelet` service to start automatically during subsequent system boots but also immediately starts the service in the current session. This dual action ensures the `kubelet` is running right away, allowing the node to quickly transition to a `Ready` state without requiring a manual reboot.

Why this answer

`systemctl enable --now kubelet` both starts the kubelet service immediately and creates the necessary symlinks to enable it to start automatically on boot. This is the most efficient way to handle a stopped service that needs to be persistent across reboots, which is critical for a Kubernetes node to rejoin the cluster after a reboot.

Exam trap

The trap here is that candidates often confuse `systemctl start` with `systemctl enable`, or assume that `systemctl start` alone is sufficient, overlooking the requirement to persist the service across reboots, which is a common cause of nodes failing to rejoin after a reboot in production.

How to eliminate wrong answers

Option A is wrong because `systemctl start --enable` is not a valid systemctl syntax; the correct flag for simultaneous start and enable is `--now`. Option B is wrong because `systemctl enable kubelet` only creates the boot-time symlinks but does not start the service immediately, leaving the node in a NotReady state until a manual start or reboot. Option D is wrong because `systemctl start kubelet` starts the service only for the current session; after a reboot, the kubelet will not start automatically, and the node will again report NotReady.

Full explanation →

105

MCQmedium

A node in the cluster has been cordoned. Which of the following is true about the node?

A.The node is removed from the cluster.

B.kubectl drain is automatically performed on the node.

C.The node is marked as unschedulable, but existing pods continue to run.

D.Existing pods on the node are immediately evicted.

AnswerC

Cordoning sets the node status to unschedulable, so no new pods are placed, but existing pods remain.

Why this answer

When a node is cordoned using `kubectl cordon`, it is marked as unschedulable by setting the `node.Spec.Unschedulable` field to true. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The node remains part of the cluster and is not removed or drained automatically.

Exam trap

The trap here is that candidates confuse cordoning with draining, assuming cordoning also evicts existing pods or removes the node, when in fact it only prevents new scheduling and leaves running pods untouched.

How to eliminate wrong answers

Option A is wrong because cordoning does not remove the node from the cluster; the node remains a member and can be uncordoned later. Option B is wrong because `kubectl drain` is not automatically performed; draining is a separate, explicit operation that evicts pods, whereas cordon only prevents new scheduling. Option D is wrong because existing pods are not immediately evicted; they continue running until they are terminated or the node is drained manually.

Full explanation →

106

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 kube-scheduler assigns Pods to Nodes by continuously watching the API server for unscheduled Pods (those with an empty spec.nodeName), then filtering Nodes based on constraints like resource requests, taints and tolerations, node selectors, affinity rules, and data locality, and finally scoring the remaining candidates to pick the best fit. Once a Node is chosen, it creates a Binding object that commits the Pod to that Node, after which the kubelet on the selected Node takes over to actually start its containers.

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 →

107

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

The "Delete" reclaim policy is the correct choice because it ensures that when a PersistentVolumeClaim (PVC) is deleted, Kubernetes automatically de-provisions both the PersistentVolume (PV) object and the actual underlying storage resource. This automation removes the storage asset, such as an AWS EBS volume or a GCP Persistent Disk, from the external infrastructure, preventing orphaned resources and incurring unnecessary costs.

Why this answer

The Delete reclaim policy instructs the system to remove the underlying storage asset (e.g., an AWS EBS volume, GCE Persistent Disk, or NFS export) when the PersistentVolume is released from a PersistentVolumeClaim. This is the only policy that automatically cleans up the physical storage, ensuring no orphaned resources remain.

Exam trap

The trap here is that candidates may confuse 'Recycle' with 'Delete' because both involve automatic cleanup, but Recycle only scrubs data without removing the storage asset, and it is no longer supported in modern Kubernetes versions.

How to eliminate wrong answers

Option B (Recycle) is wrong because Recycle was a legacy policy that performed a basic scrub (e.g., 'rm -rf /thevolume') and made the volume available again, but it did not delete the underlying storage; it was deprecated in Kubernetes 1.15 and removed in 1.20. Option C (Retain) is wrong because Retain leaves the PersistentVolume and its underlying storage intact after the PVC is released, requiring manual administrator intervention to reclaim or delete the storage. Option D (Archive) is wrong because Archive is not a valid Kubernetes PersistentVolume reclaim policy; the only three defined policies are Retain, Recycle (deprecated), and Delete.

Full explanation →

108

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

IPVS (IP Virtual Server) is a kernel-level transport-layer load balancer that kube-proxy uses to implement Kubernetes Services with a virtual server table. Unlike iptables' random chaining, IPVS supports multiple scheduling algorithms, including least connection (lc), which routes new connections to the backend with the fewest active connections. It also offers better scalability and O(1) lookups by using hash tables, making it the correct choice for advanced load-balancing needs.

Why this answer

(ipvs) is correct because kube-proxy in IPVS mode uses the Linux kernel's IP Virtual Server (IPVS) to implement Layer 4 load balancing, which supports sophisticated scheduling algorithms such as 'least connection' (lc), round-robin, and others. IPVS operates in kernel space with a hash table structure, providing better performance and scalability compared to iptables, especially in clusters with thousands of services.

Exam trap

The trap here is that candidates often assume iptables is the default and most performant mode, but the CKA exam expects you to know that IPVS is the only mode that supports advanced scheduling algorithms like 'least connection' and offers better performance at scale.

How to eliminate wrong answers

Option B is wrong because iptables mode uses a linear chain of iptables rules for each service, which becomes slow and inefficient as the number of services grows, and it only supports random or round-robin selection via DNAT rules, not sophisticated algorithms like 'least connection'. Option C is wrong because 'kernelnet' is not a valid kube-proxy mode; the recognized modes are userspace, iptables, IPVS, and (in newer versions) nftables. Option D is wrong because userspace mode runs in user space and proxies traffic via a userspace proxy, which introduces higher latency and lower performance due to context switching, and it does not support advanced load balancing algorithms like 'least connection'.

Full explanation →

109

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

etcdctl snapshot restore is the correct command because it takes a previously captured snapshot file and reconstructs a new etcd data directory. The --data-dir flag points to the location where the restored database files should be written, and the etcd server must later be configured to use that directory; this is the canonical procedure for restoring etcd in Kubernetes control-plane recovery.

Why this answer

`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 →

110

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 kubectl describe pod output lists Events from the scheduler. In this case, the events directly report two distinct issues: three nodes have insufficient CPU to satisfy the pod's resource request, and one node has a taint for which the pod has no matching toleration. Since these are the exact messages shown, this option correctly captures the full diagnosis.

Why this answer

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.

Exam trap

The trap here is that candidates may misinterpret '0/4 nodes are available' as all nodes having the same issue, but the event message lists distinct reasons per node, requiring careful reading to identify the combination of taint and resource insufficiency.

How to eliminate wrong answers

Option B is wrong because the event shows only 3 nodes have insufficient CPU, not all 4; one node has a taint issue, not a CPU shortage. Option C is wrong because the event indicates only 1 node has a taint, not all nodes; the other 3 nodes have insufficient CPU, not taints. Option D is wrong because the event does not mention any node being cordoned; it specifically cites taint and insufficient CPU as the reasons.

Full explanation →

111

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 persistent-volume-claims

AnswerB

Correct. `kubectl get pvc` is the standard shorthand command to list all PersistentVolumeClaims.

Why this answer

`kubectl get pvc` is the correct command to list PersistentVolumeClaims using the official short name. Option A lists PersistentVolumes (`pv`). Option C (`claims`) and Option D (`persistent-volume-claims` with hyphens) are invalid resource names and will result in an error.

Exam trap

Candidates often confuse the shorthand `pv` for PersistentVolume with `pvc` for PersistentVolumeClaim, or mistakenly believe that `kubectl get claims` is valid.

How to eliminate wrong answers

Option A is wrong because `kubectl get pv` lists PersistentVolumes, not PersistentVolumeClaims; these are distinct resources where PVs represent actual storage volumes and PVCs represent requests for storage. Option C is wrong because `kubectl get claims` is not a valid kubectl command; Kubernetes does not recognize 'claims' as a resource abbreviation, and this will result in an error.

Full explanation →

112

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 valid Container Network Interface (CNI) plugin that provides networking and network policy for Kubernetes clusters. It implements the CNI specification by configuring routes, assigning IP addresses (via IPAM), and enforcing policy using iptables or eBPF dataplanes, making it one of the most widely adopted CNI plugins in production.

Why this answer

Calico is a valid CNI plugin that implements the Container Network Interface specification to provide networking and network policy for Kubernetes clusters. It uses BGP (Border Gateway Protocol) to route packets between nodes and supports overlay or non-overlay networking modes, making it a widely adopted choice for production environments.

Exam trap

The trap here is that candidates confuse cluster infrastructure components (etcd, kubelet) or container runtimes (Docker) with CNI plugins, because they are all part of the Kubernetes ecosystem but serve fundamentally different roles.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used to store Kubernetes cluster state and configuration, not a CNI plugin for networking. Option C (Docker) is wrong because Docker is a container runtime that can be used with Kubernetes but is not a CNI plugin; CNI plugins handle network interface setup, not container execution. Option D (Kubelet) is wrong because Kubelet is the primary node agent that manages pods and containers on a node, and while it invokes CNI plugins, it is not itself a CNI plugin.

Full explanation →

113

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 kubelet on the worker node communicates with the container runtime through the Container Runtime Interface (CRI), typically over a Unix socket such as /run/containerd/containerd.sock. If containerd is not installed, the service is stopped, or the socket is missing, kubelet will fail with a CRI connection error and never start pods. Run `systemctl status containerd` and check the socket path configured in kubelet (--container-runtime-endpoint) to confirm the runtime is active.

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 →

114

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 essential agent running on each worker node, responsible for registering the node with the control plane and continuously reporting its health and status to the API server via heartbeats. If the kubelet process fails, crashes, or loses network connectivity on a specific worker node, it stops sending these crucial heartbeats. Consequently, the Node Controller on the control plane will eventually mark that particular node as 'NotReady' because it is no longer receiving status updates from its designated agent.

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 →

115

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 `kubectl port-forward service/<name> 8080:80` correctly creates a local listener on port 8080 and forwards traffic through the Kubernetes API server to a pod that backs the specified Service, reaching that pod on its port 80. The format is always <local>:<remote>, so the left side of the colon is the port that appears on your workstation (localhost:8080) and the right side is the intended destination port inside the cluster (the Service's port 80). This lets you reach a cluster-internal Service endpoint without exposing it publicly, which is useful for debugging, accessing a private web UI, or testing a preview of an application running inside the cluster.

Why this answer

`kubectl port-forward` creates a tunnel from a local port to a pod (or service) in the cluster. When targeting a Service, it selects one of the Service's endpoints (a pod) and forwards traffic from localhost:8080 to port 80 on that pod. This allows direct access to the Service without exposing it externally.

Exam trap

The trap here is confusing the direction of the port mapping: candidates often think the first port is the remote port and the second is the local port, but `kubectl port-forward` always uses the format `local_port:remote_port`.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` does not create or modify any Kubernetes resources; it only establishes a temporary network tunnel from the local machine. Option B is wrong because it reverses the direction: the command forwards the local port 8080 to the Service's port 80, not the Service's port 8080 to the local machine. Option C is wrong because it incorrectly states that the local machine's port 80 is forwarded to the Service's port 8080, which is the opposite of the actual mapping (local 8080 → Service 80).

Full explanation →

116

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, which exceeds the capacity of any individual worker node, as each worker node only provides 1 CPU. Furthermore, the control-plane node, which might have sufficient CPU, is typically tainted with `node-role.kubernetes.io/control-plane:NoSchedule` or similar, preventing the scheduler from placing this pod on it unless the pod explicitly tolerates this taint. Consequently, no suitable node exists in the cluster to satisfy the pod's CPU request, leading to its Pending status.

Why this answer

The pod requests 2 CPU, but each worker node has only 1 CPU, making them insufficient. The control-plane node has the taint `node-role.kubernetes.io/master:NoSchedule` which the pod does not tolerate, so it is also unavailable. The event explicitly states '2 Insufficient cpu', confirming that the CPU request cannot be satisfied by any node.

Exam trap

The trap here is that candidates may focus on the taint message and assume the control-plane node's resources are the issue (Option D), or misinterpret the 'Insufficient cpu' as a memory problem (Option A), rather than recognizing that the CPU request exceeds the capacity of the only schedulable nodes (the workers).

How to eliminate wrong answers

Option A is wrong because the pod requests 1Gi memory, which is well within the capacity of any node (worker nodes typically have more than 1Gi memory), and the event does not mention memory insufficiency. Option B is wrong because priority and preemption are unrelated to the 'Pending' state caused by resource shortages; the event shows no preemption activity, and preemption would involve evicting lower-priority pods, not failing to schedule. Option D is wrong because the control-plane node is tainted with NoSchedule, making it unschedulable for this pod regardless of its resources; the issue is the taint, not insufficient resources on that node.

Full explanation →

117

MCQeasy

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

A.ipvs

B.nftables

C.userspace

D.iptables

AnswerD

iptables is the correct mode because kube-proxy in this mode programs the kernel's iptables NAT table with rules that translate a service's ClusterIP or NodePort to a selected pod IP. These rules use statistics to randomly choose among healthy endpoints, so packet forwarding and load balancing are entirely implemented with iptables rules. As a result, the service handling is performed by iptables in the kernel, not by a userspace process.

Why this answer

Kube-proxy's iptables mode uses Linux iptables rules to handle service traffic. In this mode, kube-proxy watches the Kubernetes API server for Service and Endpoint changes and programs iptables rules in the NAT table (specifically the PREROUTING and OUTPUT chains) to redirect traffic destined for a Service's ClusterIP to the backend Pod IPs via DNAT. This is the default mode in most Kubernetes distributions due to its reliability and moderate performance.

Exam trap

The trap here is that candidates often confuse the iptables mode with the ipvs mode, assuming ipvs also uses iptables rules, but ipvs operates at a different layer (kernel-level load balancing) and does not rely on iptables for service traffic handling.

How to eliminate wrong answers

Option A is wrong because ipvs mode uses the IPVS (IP Virtual Server) kernel module to handle service traffic, not iptables; it offers better scalability and performance for large clusters by using a hash table instead of a linear rule chain. Option B is wrong because nftables is a modern replacement for iptables, but kube-proxy does not have a native nftables mode; the iptables mode uses legacy iptables, not nftables. Option C is wrong because userspace mode is an older, deprecated mode where kube-proxy runs in userspace and proxies traffic through a userspace process, not using iptables rules for packet forwarding.

Full explanation →

118

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 '0/N' node count in kubectl describe means the scheduler evaluated all nodes and none satisfied the pod's combined requirements, such as nodeSelector, node affinity, required tolerations, or disk/resource requests. The pod's PodScheduled condition is False with a reason of Unschedulable, and events show failedScheduling. Multiple simultaneous constraints each eliminate different nodes, leaving no feasible candidate.

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 →

119

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

The "kubectl top nodes" command queries the Metrics Server API to retrieve and display the current, real-time CPU and memory utilization of all nodes in the cluster. This is the standard, built-in command used by administrators to quickly identify resource-constrained nodes. It requires the Metrics Server to be properly installed and running in the cluster to function.

Why this answer

`kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster. This command relies on the metrics server being deployed and functioning, which aggregates resource usage data from kubelet’s cAdvisor endpoint. It is the standard Kubernetes command for checking node-level resource consumption.

Exam trap

The trap here is that candidates often confuse `kubectl describe nodes` (which shows static capacity and allocatable resources) with `kubectl top nodes` (which shows dynamic, real-time usage), leading them to choose option D when they need actual consumption data.

How to eliminate wrong answers

Option B is wrong because `kubectl get nodes -o wide` shows additional node information such as internal IP, external IP, and OS image, but does not display resource usage metrics. Option C is wrong because `kubectl logs --all-containers` retrieves container logs from a pod, not node-level resource usage. Option D is wrong because `kubectl describe nodes` provides detailed node status, conditions, and capacity/allocatable resources, but does not show current real-time resource consumption like `kubectl top nodes` does.

Full explanation →

120

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

kubelet and kubectl are not automatically upgraded by kubeadm; you must manually update these binaries on each node using your package manager (e.g., apt-get upgrade kubelet kubectl) or by replacing them in /usr/bin. This manual step is required because kubeadm upgrade node only handles the static pod manifests and kubeadm configuration, not the kubelet or kubectl client versions.

Why this answer

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 →

121

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

When a pod's status displays Init:CrashLoopBackOff, it indicates that one of its defined init containers has exited with a non-zero status code and is repeatedly failing during startup. Kubernetes will continuously attempt to restart this failing init container before it can proceed to the main application containers, blocking the pod from reaching the Running state.

Why this answer

The status 'Init:CrashLoopBackOff' indicates that an init container within the pod is failing and being repeatedly restarted by Kubernetes. Init containers run sequentially before any main containers start, and if one exits with a non-zero exit code, Kubernetes retries it with an exponential backoff delay, leading to the CrashLoopBackOff state. This is distinct from a main container crash, which would show 'CrashLoopBackOff' without the 'Init:' prefix.

Exam trap

The CKA exam often tests the distinction between init container failures and main container failures by using the 'Init:' prefix in the status, so candidates who overlook this prefix may mistakenly choose the main container crash option.

How to eliminate wrong answers

Option B is wrong because if an init container ran successfully, the pod would proceed to start the main container, not remain in an 'Init:' status; the 'Init:' prefix specifically indicates an init container is still running or failing. Option C is wrong because 'Init:CrashLoopBackOff' is not a transient initialization state—it signals a persistent failure with restarts, not eventual success without intervention. Option D is wrong because a crashing main container would show 'CrashLoopBackOff' (without 'Init:'), not 'Init:CrashLoopBackOff', which explicitly points to an init container issue.

Full explanation →

122

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

'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 →

123

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 a Pod selected by the Service, bypassing the Service's ClusterIP.

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).

Why this answer

The `kubectl port-forward` command forwards connections from a local port to a port on a Pod. When you specify a Service (e.g., `service/my-svc`), kubectl automatically selects an active Pod matching the Service's selector and forwards the traffic directly to that Pod. It completely bypasses the Service's ClusterIP and kube-proxy routing.

Exam trap

Candidates often mistakenly believe that `kubectl port-forward` routes traffic through the Service's ClusterIP. In reality, it resolves the Service's selector, picks a backing Pod, and establishes a direct tunnel to that Pod via the API server and the node's kubelet.

How to eliminate wrong answers

Option B is wrong because it describes the direction of traffic backwards: port-forward forwards from a local port to a remote port, not from port 80 to port 8080 within the cluster. Option C is wrong because port-forward does not create or modify any Service object; it is a temporary client-side tunnel, not a LoadBalancer Service creation. Option D is wrong because port-forward does not expose the Service on each node's port; that would be achieved by a NodePort Service, not by kubectl port-forward.

Full explanation →

124

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

kubectl port-forward pod/web-pod 8080:80 creates a direct TCP tunnel from your localhost:8080 to port 80 inside web-pod via the Kubernetes API server. The pod/<name> resource identifier and the local:remote port pair are the correct port-forward syntax, and this is the intended command for one-off debugging access. It keeps running until interrupted.

Why this answer

`kubectl port-forward` creates a direct tunnel from a local port to a specified port on a pod, allowing access to the pod's service without exposing it externally. The syntax `pod/web-pod 8080:80` forwards localhost:8080 to port 80 of the pod named 'web-pod'.

Exam trap

The trap here is that candidates confuse `kubectl port-forward` with `kubectl expose` or `kubectl proxy`, mistakenly thinking that creating a Service or a proxy is the correct way to forward a local port to a specific pod, when in fact `port-forward` is the only command that creates a direct local-to-pod tunnel.

How to eliminate wrong answers

Option A is wrong because `kubectl exec -it web-pod -- nc -l -p 8080` starts a netcat listener inside the pod on port 8080, which does not forward a local port to the pod's port 80; it listens on a different port inside the container. Option B is wrong because `kubectl proxy --port=8080` creates a proxy server that forwards traffic to the Kubernetes API server, not to a specific pod's port 80. Option C is wrong because `kubectl expose pod web-pod --port=8080 --target-port=80` creates a Service object that exposes the pod within the cluster, but it does not forward a local port to the pod; it requires additional steps like `kubectl get svc` and accessing via the service IP or node port.

Full explanation →

125

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 command is the correct approach because the --previous (or -p) flag instructs the kubelet to retrieve the stdout and stderr logs from the most recently terminated instance of the container. This is essential for diagnosing CrashLoopBackOff states where the current container has restarted and its active log buffer is empty or irrelevant.

Why this answer

The `kubectl logs --previous` flag retrieves logs from the previous instance of a container in a Pod, which is exactly what you need when the current container has crashed and restarted, leaving no logs from the current instance. Since `kubectl logs web-pod -n frontend` returned no output, the current container likely started fresh after a crash, and the logs from the crashed container are stored in the terminated container's log file. This flag accesses those logs without needing to specify a container name explicitly when there is only one container in the Pod.

Exam trap

The trap here is that candidates may think `kubectl logs` without flags is sufficient, or they may confuse `--previous` with `-c` (container name), not realizing that `--previous` is specifically designed to access logs from a terminated container instance, while `-c` only selects a container within a multi-container Pod.

How to eliminate wrong answers

Option A is wrong because `kubectl get events` shows cluster events (e.g., scheduling, pulling images) but does not provide container logs, which are needed to debug the crash. Option C is wrong because `-c web-pod` specifies a container name, but if the Pod has only one container (named 'web-pod'), this command is redundant and still fetches logs from the current (possibly empty) container, not the previous crashed instance. Option D is wrong because `kubectl exec` opens an interactive shell into the running container, but if the container is crashing repeatedly, it may not be running, and even if it were, this would not retrieve logs from the previous terminated instance.

Full explanation →

126

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

Use a projected volume with a serviceAccountToken source and set a mountPath—such as /var/run/secrets/kubernetes.io/serviceaccount—to expose a TokenRequest-based token file in the pod. The kubelet requests the token with a configurable audience and expirationSeconds, writes it to the specified path, and automatically rewrites it as expiry approaches, enabling client libraries to reload the credential. This is the recommended approach because it minimizes token lifetime, allows audience restriction, and avoids the security drawbacks of environment variables or unmanaged, long-lived secrets.

Why this answer

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 →

127

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

Readiness probes determine whether a pod is included in the Service's EndpointSlices. The endpoint controller monitors pod readiness and only adds pods whose readiness probe is currently passing; pods failing readiness (or running a container that never becomes ready) are excluded. If all matching pods fail their readiness probe, the endpoint list is empty, and traffic to the Service's ClusterIP or DNS name is dropped. This directly explains why traffic is not reaching the application when the selector matches but no endpoints exist.

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 →

128

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

This statement is correct because volume expansion is a feature that must be explicitly enabled at the StorageClass level. The `allowVolumeExpansion: true` parameter within the StorageClass definition signals to Kubernetes and the underlying storage provisioner that volumes provisioned by this class are capable of being resized. Without this setting, any attempt to expand a PersistentVolumeClaim (PVC) will be rejected by the API server, regardless of the underlying storage system's capabilities.

Why this answer

For PVC expansion to succeed with a dynamically provisioned PV, the StorageClass must have the `allowVolumeExpansion: true` field set. This field explicitly enables volume expansion for all PVCs using that StorageClass. Without it, the PVC expansion request will be rejected even if other conditions are met.

Exam trap

The trap here is that candidates often confuse PV reclaim policy (Delete/Retain) with expansion capabilities, or assume the PV must be in a specific state like Released, when in fact the StorageClass setting is the sole gatekeeper for volume expansion.

How to eliminate wrong answers

Option A is wrong because the PV must be in Bound state (not Released) to allow PVC expansion; a Released PV indicates the PVC was deleted, and expansion is not possible. Option C is wrong because the reclaim policy (Delete/Retain) does not affect the ability to expand a PVC; expansion is controlled by the StorageClass setting, not the reclaim policy. Option D is wrong because PVC expansion is supported for all access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) as long as the underlying volume plugin supports it; ReadWriteOnce is not a requirement.

Full explanation →

129

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

DaemonSets are the standard workload type for node-level agents because they guarantee coverage on every node. Common use cases include log shippers like Fluentd or Filebeat, which must run locally to forward each node's logs, and monitoring agents such as Prometheus Node Exporter or Datadog, which collect per-node metrics. Running such agents as a DaemonSet ensures they automatically appear on newly added nodes and are removed when nodes are deleted.

Why this answer

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 →

130

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

This is the correct explanation. For a Service, kubectl port-forward requires at least one ready endpoint, which is created automatically when pod labels match the service's selector. When no pods match, the Endpoints object is empty, causing the API server to fail with an error such as 'Unable to connect to a frontend pod'. The developer must verify the selector against existing pod labels or manually define endpoints for selector-less services.

Why this answer

B is correct because if no pods match the service selector 'app: my-app', the service will have no endpoints. Without endpoints, the service cannot route traffic, and kubectl port-forward will fail to establish a connection to localhost:8080. The port-forward command relies on the service having at least one endpoint to forward traffic to.

Exam trap

The trap here is that candidates may assume port forwarding only works with pods, but Kubernetes actually supports port forwarding to services by automatically selecting a pod from the service's endpoints.

How to eliminate wrong answers

Option A is wrong because ClusterIP services do support port forwarding; the service type does not affect the ability to use kubectl port-forward. Option C is wrong because kubectl port-forward can forward to services (as well as pods) by resolving the service to its endpoints. Option D is wrong because the --address flag is optional and defaults to localhost; the failure is not due to missing the --address flag.

Full explanation →

131

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

A headless Service with a selector creates Endpoints (or EndpointSlices) from the ready pods that match the labels. When a client looks up this Service name, CoreDNS returns one A record for each such pod IP, allowing direct pod discovery. This behavior is fundamental to StatefulSets, where each pod gets its own DNS name from this list.

Why this answer

A headless service (clusterIP: None) does not have a ClusterIP or load-balance traffic. Instead, DNS queries for the service name return A records for the individual pod IPs that match the service's selector. This allows direct pod-to-pod communication without a proxy, as defined by Kubernetes DNS specification.

Exam trap

The trap here is that candidates confuse headless services with normal ClusterIP services, assuming DNS will return a single virtual IP or an error, rather than understanding that headless services return multiple pod IPs for direct pod-to-pod resolution.

How to eliminate wrong answers

Option A is wrong because headless services are specifically designed to be queried by DNS, returning pod IPs rather than an error. Option B is wrong because a headless service does not have a single service IP; it returns multiple A records for each matching pod. Option C is wrong because the ClusterIP is explicitly set to 'None', and the DNS response does not return this value; it returns pod IPs instead.

Full explanation →

132

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

kubectl top nodes is the correct command because it queries the metrics.k8s.io API provided by metrics-server to return each node’s current total CPU and memory usage, along with the percentage relative to allocatable capacity. It aggregates pod usage plus node-level system reservations from cAdvisor and presents a concise per-node snapshot, making it the standard built-in way to assess current node resource consumption.

Why this answer

`kubectl top nodes` retrieves and displays real-time CPU and memory usage metrics for all nodes in the cluster, directly answering the question about current resource usage. This command relies on the metrics server being deployed in the cluster to collect resource utilization data from kubelets via the Summary API.

Exam trap

The trap here is that candidates confuse `kubectl top nodes` with `kubectl get nodes -o wide`, mistakenly thinking the latter shows resource usage when it only shows network and OS details, not utilization metrics.

How to eliminate wrong answers

Option A is wrong because `kubectl top pods` shows resource usage for pods, not nodes, so it does not meet the requirement to check node-level resource usage. Option B is wrong because `kubectl get events` lists cluster events (e.g., scheduling failures, pod lifecycle changes) and does not provide any resource utilization metrics. Option C is wrong because `kubectl get nodes -o wide` displays node metadata such as internal IP, external IP, and OS image, but not real-time CPU or memory usage.

Full explanation →

133

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

kubectl describe pod pod-name retrieves the Pod's full configuration along with a dedicated 'Events' section that records timestamped, sequential notifications from the kubelet and controller-manager about that Pod. These events describe actions like scheduling decisions, container creation, image pulling, probe failures, and restarts, which are exactly what you need when debugging why a Pod is stuck or repeatedly crashing. The describe command aggregates just the events for that specific Pod, making it the direct answer to the question.

Why this answer

`kubectl describe pod pod-name` includes a dedicated 'Events' section that lists all lifecycle events for that specific pod, such as scheduling, container pulls, and restarts. This command filters events to only those relevant to the pod, making it the most direct way to view pod-specific events without needing to parse all cluster events.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (application output) with `kubectl describe` (cluster events), or assume `kubectl get events` is the only way to view events, missing that `kubectl describe` automatically filters events for the specified resource.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod-name` retrieves the container's stdout/stderr logs, not Kubernetes events; logs show application output, not cluster-level scheduling or lifecycle events. Option B is wrong because `kubectl get pod pod-name` only displays the pod's current status and metadata in a summary table, omitting the detailed event history. Option C is wrong because `kubectl get events` lists all events across the entire namespace or cluster, requiring manual filtering to find those related to a specific pod, which is less efficient and not targeted.

Full explanation →

134

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 →

135

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

Kubernetes containers within a pod, including init and main containers, have isolated filesystems by default. For an init container to share data, such as a configuration file, with a main container, they must both mount the same shared volume, like an `emptyDir`. If the init container wrote the file to its own ephemeral filesystem or a volume not also mounted by the main container, the main container would correctly report "file not found" as it cannot access that location.

Why this answer

The most likely cause is that the init container wrote the configuration file to a volume that is not shared with the main container. In Kubernetes, init containers and main containers in the same Pod share the same filesystem only if they mount the same Volume. If the init container writes to a volume that is not mounted in the main container, or writes to a different path within the same volume, the main container will not see the file.

This is a common misconfiguration when using emptyDir or hostPath volumes.

Exam trap

The trap here is that candidates assume init containers and main containers automatically share the same filesystem, but Kubernetes isolates container filesystems by default unless volumes are explicitly shared.

How to eliminate wrong answers

Option B is wrong because if the main container restarts, init containers do not rerun by design — they run to completion before any main container starts, and their output persists in shared volumes, so a restart of the main container would still see the file if it was written to a shared volume. Option C is wrong because an incorrect command in the main container would typically cause a different error (e.g., command not found, exit code 127) or a crash loop, not a 'file not found' error, unless the command explicitly references a missing file. Option D is wrong because Kubernetes guarantees that init containers complete successfully before any main container starts; the Pod's lifecycle ensures the init container's status is 'Completed' before the main container's status moves to 'Running'.

Full explanation →

136

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

Running `kubectl describe node <node-name>` surfaces the node's status object, including the `Conditions` section with entries like `Ready`, `MemoryPressure`, and `PIDPressure`. Each condition carries a `LastHeartbeatTime` and a `Reason`/`Message` that explains why the node might be `NotReady` after an upgrade. This is the fastest control-plane-level check because it reflects the kubelet's last successful status update and any taints, capacity, or allocatable changes that could affect scheduling.

Why this answer

'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 →

137

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, C

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

Why this answer

To check the status of control plane components in a kubeadm-established cluster, use 'kubectl get pods -n kube-system' to inspect the static pods. 'kubectl get componentstatuses' (deprecated but still a valid status check) reports health of the control plane components. 'systemctl status kube-apiserver' is not appropriate because the API server runs as a static pod, not a systemd service.

Exam trap

The CKA exam environment is built using kubeadm. Do not look for systemd services for the apiserver, controller-manager, or scheduler, as they run as static pods. Only the kubelet and the container runtime (e.g., containerd) run as systemd services on the nodes.

Full explanation →

138

MCQmedium

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

A CrashLoopBackOff status frequently indicates that a container is repeatedly crashing and being restarted by Kubernetes. When the underlying cause is an OOMKilled event, it means the container attempted to consume more memory than specified by its configured `resources.limits.memory`. Increasing this memory limit directly addresses the root cause by providing the container with sufficient memory resources, thereby preventing the operating system from terminating the process due to out-of-memory conditions and allowing the pod to stabilize.

Why this answer

The OOMKilled status indicates the container was terminated by the Linux Out-of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Exam trap

The trap here is that candidates may confuse OOMKilled with a general crash loop and choose to delete/recreate the pod, not realizing that the pod will simply crash again with the same memory limit.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory constraints; CPU throttling or limits are unrelated to OOM kills. Option C is wrong because deleting and recreating the pod only restarts the same container with the same memory limit, so it will likely be OOMKilled again immediately. Option D is wrong because deleting the entire namespace and all workloads is an extreme, unnecessary action that disrupts all services and does not fix the underlying memory limit issue.

Full explanation →

139

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 sequence is the recommended and correct procedure for a Kubernetes cluster upgrade. Upgrading the control plane first ensures that the central kube-apiserver can support newer worker node components and API versions. Subsequently, draining each worker node individually allows pods to gracefully migrate, minimizing downtime, before upgrading its kubelet and kube-proxy, and finally uncordoning it to rejoin the cluster.

Why this answer

Kubernetes requires the control plane to be upgraded first, as it is the source of truth for the cluster state and API version compatibility. After the control plane is upgraded, each worker node must be drained (to evict pods gracefully), upgraded (kubelet and kube-proxy), and then uncordoned to resume scheduling. This sequential process ensures that the cluster remains functional and that kubelet versions never exceed the kube-apiserver version, which is a strict compatibility requirement.

Exam trap

The trap here is that candidates often think worker nodes can be upgraded first to minimize control-plane downtime, but the CKA exam tests the strict version skew policy that requires the control plane to be upgraded first, and that draining all nodes simultaneously is a common misconception that would cause complete cluster unavailability.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before the control plane violates the Kubernetes version skew policy, which requires the kube-apiserver to be at the highest version; if worker nodes are upgraded first, their kubelet may attempt to use API features not yet available on the older control plane, causing failures. Option B is wrong because draining all nodes simultaneously would make the cluster completely unavailable, and upgrading the control plane after draining all nodes is not the correct order; the control plane must be upgraded first while worker nodes are still running to maintain cluster operations. Option D is wrong because upgrading control plane and worker nodes at the same time is not supported; the control plane must be upgraded first to ensure API compatibility, and simultaneous upgrades can lead to version mismatches and cluster instability.

Full explanation →

140

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

A connection refused error—specifically ECONNREFUSED—indicates that the application's TCP handshake reached the target host but nothing was listening on that port, or the service endpoints are empty because the backing database pods are not ready. This commonly occurs when the database Deployment has zero ready replicas, the Service selector does not match any pods, or the pod is using an incorrect service name or port. The container's main process exits after failing to initialize its database connection, and the kubelet restarts it, cycling into CrashLoopBackOff.

Why this answer

The error message 'connection refused' indicates that the pod is attempting to connect to the database at 'db-svc:5432' but the target service is not accepting TCP connections on port 5432. This typically means the database pod or service is not running, or a network policy is blocking the connection. The 'CrashLoopBackOff' status confirms the application container repeatedly fails due to this startup dependency.

Exam trap

The CKA exam often tests the distinction between application-level errors (like 'connection refused') and infrastructure-level errors (like OOM or image pull failures), so candidates must read the exact error message in the logs rather than assuming a generic pod failure cause.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe would cause the pod to be restarted after it had started, not produce a 'connection refused' error in the application logs; liveness probes check container health after startup, not database connectivity. Option B is wrong because a missing container image would result in an 'ImagePullBackOff' or 'ErrImagePull' status, not a 'CrashLoopBackOff' with a database connection error in the logs. Option D is wrong because a memory limit that is too low would cause an 'OOMKilled' status or 'OutOfMemory' error in the logs, not a TCP connection refused error.

Full explanation →

141

MCQhard

You create a PriorityClass named 'high-priority' with value 1000000 (one million). A pod uses this PriorityClass. The cluster has limited resources. What scheduling behavior is most likely?

A.The pod will never be preempted by other pods

B.The pod will be scheduled only after all lower-priority pods have been scheduled

C.The pod may preempt lower-priority pods to be scheduled

D.The pod will be assigned a higher CPU priority in the kernel

AnswerC

Correct. When a pod carries a high-priority PriorityClass, the scheduler treats it as eligible for preemption: if the pod cannot be placed on any node because of insufficient resources, the scheduler identifies nodes running pods with lower priorities and evicts those lower-priority pods to free capacity for the pending high-priority pod. This is governed by the preemptionPolicy field in the PriorityClass, which defaults to PreemptLowerPriority, and the actual eviction is performed through the PodDisruptionBudget-aware API, though critical pods may be protected if they have higher priority or are in terminating state.

Why this answer

PriorityClass with value 1000000 is extremely high (the default max is 1 billion). When a pod with this PriorityClass is submitted and the cluster has limited resources, the Kubernetes scheduler may preempt (evict) lower-priority pods to free resources and schedule this high-priority pod. This is the core behavior of PriorityClass and preemption in Kubernetes.

Exam trap

CNCF often tests the misconception that PriorityClass affects kernel-level CPU priority or that a high-priority pod is scheduled before all lower-priority pods, when in reality it only enables preemption and does not guarantee scheduling order.

How to eliminate wrong answers

Option A is wrong because even a pod with a very high priority can be preempted by a pod with an even higher priority (up to 1 billion), so it is not immune to preemption. Option B is wrong because scheduling order is not strictly based on priority; lower-priority pods can be scheduled first if resources are available, and high-priority pods may preempt them later. Option D is wrong because Kubernetes PriorityClass does not affect the kernel's CPU priority (nice value); it only controls scheduling and preemption within the Kubernetes scheduler.

Full explanation →

142

MCQmedium

After deploying a new Deployment, you notice that the pods are stuck in ImagePullBackOff. What is the most common cause?

A.The liveness probe is misconfigured

B.The node has insufficient resources

C.The container image name or tag is incorrect

D.The container command fails on startup

AnswerC

Providing an invalid image name or an unavailable tag causes the container registry to return a 404 error to the kubelet. Consequently, the pod transitions into `ErrImagePull` and then `ImagePullBackOff` because the container runtime cannot locate or download the specified image layers.

Why this answer

The ImagePullBackOff status indicates that the kubelet is unable to pull the container image from the registry. The most common cause is an incorrect image name or tag, which results in a manifest not found error. This triggers an exponential backoff retry loop, leading to the ImagePullBackOff state.

Exam trap

The trap here is that candidates confuse ImagePullBackOff with CrashLoopBackOff, but ImagePullBackOff specifically relates to image retrieval failures, not container runtime errors.

How to eliminate wrong answers

Option A is wrong because a misconfigured liveness probe causes the container to be restarted or killed (CrashLoopBackOff), not an image pull failure. Option B is wrong because insufficient node resources result in a PodPending state with events like 'FailedScheduling' or 'OutOfMemory', not ImagePullBackOff. Option D is wrong because a container command that fails on startup leads to a CrashLoopBackOff state, as the container exits immediately after starting, not an image pull issue.

Full explanation →

143

MCQmedium

What is the DNS name for a Service named 'api' in the 'default' namespace?

A.api.default.svc.cluster.local

B.default.api.svc.cluster.local

C.api.svc.default.cluster.local

D.api.default.cluster.local

AnswerA

The Kubernetes DNS schema for a Service is <service-name>.<namespace>.svc.cluster.local. Since the Service is named 'api' and created in the default namespace, the fully qualified domain name becomes api.default.svc.cluster.local. This FQDN resolves to the Service's ClusterIP and enables reliable cluster-wide service discovery.

Why this answer

The correct DNS name for a Service in Kubernetes follows the pattern `<service-name>.<namespace>.svc.cluster.local`. For a Service named 'api' in the 'default' namespace, this resolves to `api.default.svc.cluster.local`. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix configured in kubelet and CoreDNS.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or reverse the service/namespace order, because they may confuse the DNS format with other Kubernetes naming conventions (e.g., pod DNS or headless service records) or assume the namespace comes first.

How to eliminate wrong answers

Option B is wrong because it reverses the order of service name and namespace, which would be `default.api.svc.cluster.local` — this is not a valid Kubernetes DNS format. Option C is wrong because it places `svc` after the namespace, resulting in `api.svc.default.cluster.local` — the `svc` component must come after the namespace, not before it. Option D is wrong because it omits the `svc` subdomain entirely, giving `api.default.cluster.local` — this would not be resolved by CoreDNS for a Service, as the `svc` label is required in the DNS search path.

Full explanation →

144

MCQmedium

A pod is in Pending state. You see the event: '0/2 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate'. What should you do to schedule the pod on one of the control-plane nodes?

A.Increase the pod's resource requests

B.Remove the taint from the control-plane node

C.Use a different namespace

D.Add a toleration to the pod spec matching the taint

AnswerD

Adding a toleration to the pod spec that matches the node's taint is the correct solution because tolerations explicitly opt a pod into scheduling on tainted nodes. The taint on the node uses key, value, and effect (e.g., node-role.kubernetes.io/control-plane:NoSchedule), and the toleration must mirror that key, value, and effect before the scheduler will place the pod there. This is the standard, least-privilege way to run a specific workload on a dedicated or control-plane node without weakening cluster-wide policies.

Why this answer

The pod is in Pending state because the control-plane nodes have a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate. By default, pods are not scheduled on control-plane nodes unless they explicitly tolerate that taint. Adding a toleration to the pod spec that matches the taint's key, effect, and optionally value allows the scheduler to place the pod on a control-plane node.

Exam trap

The trap here is that candidates may think removing the taint (Option B) is the correct fix, but the CKA exam expects you to use tolerations to selectively schedule pods on tainted nodes without altering node configuration.

How to eliminate wrong answers

Option A is wrong because increasing resource requests does not address taints or tolerations; it may even make scheduling harder by requiring more resources. Option B is wrong because removing the taint from the control-plane node would allow all pods to schedule there, which is not the intended solution for a specific pod and could compromise node isolation. Option C is wrong because namespaces are a logical isolation boundary and have no effect on taint/toleration mechanics or scheduling decisions.

Full explanation →

145

MCQeasy

Which kubectl command is used to drain a node before performing maintenance?

A.kubectl cordon node01

B.kubectl drain node01

C.kubectl taint node node01 key=value:NoExecute

D.kubectl delete node node01

AnswerB

The `kubectl drain node01` command is the proper way to prepare a node for maintenance. It cordons the node to make it unschedulable and then evicts all pods on the node (except DaemonSet-managed pods and mirror pods by default) gracefully, respecting PodDisruptionBudgets and terminating containers with proper pre-stop hooks. After the drain completes, the node is both unschedulable and free of workloads, allowing safe maintenance or shutdown. Use flags like --ignore-daemonsets or --delete-emptydir-data when needed, but the base command is the correct starting point.

Why this answer

The `kubectl drain` command is the correct tool for safely evicting all pods from a node before maintenance. It marks the node as unschedulable (similar to `cordon`) and then gracefully terminates pods, respecting PodDisruptionBudgets, ensuring workloads are rescheduled to other nodes without disruption.

Exam trap

CNCF often tests the distinction between `cordon` (only prevents new pods) and `drain` (evicts existing pods), leading candidates to mistakenly choose `cordon` when the question explicitly requires draining for maintenance.

How to eliminate wrong answers

Option A is wrong because `kubectl cordon` only marks the node as unschedulable (SchedulingDisabled) but does not evict existing pods, so maintenance would still leave running workloads on the node. Option C is wrong because `kubectl taint` with `NoExecute` evicts pods that do not tolerate the taint, but it does not gracefully drain all pods or respect PodDisruptionBudgets, and it is not the standard command for node maintenance preparation. Option D is wrong because `kubectl delete node` removes the node object from the cluster entirely, which is destructive and not intended for maintenance; it does not evict pods or cordon the node first, potentially causing workload disruption.

Full explanation →

146

MCQeasy

What is the purpose of a PriorityClass in Kubernetes?

A.To define which nodes a pod can be scheduled on based on priority

B.To set the order in which pods are started

C.To ensure that high-priority pods can preempt lower-priority pods

D.To give a pod a higher share of CPU cycles

AnswerC

The primary function of a PriorityClass is to assign a priority value to a pod, enabling the Kubernetes scheduler to make preemption decisions. When a higher-priority pod is pending due to insufficient resources on any node, the scheduler can evict one or more lower-priority pods from a suitable node to free up the necessary capacity. This mechanism ensures that critical workloads can always find space to run, even in a resource-constrained environment.

Why this answer

PriorityClass in Kubernetes is used to assign a priority value to pods, which the scheduler uses to determine scheduling order and, critically, to enable preemption. When the cluster is under resource pressure, the scheduler can preempt (evict) lower-priority pods to make room for higher-priority pods that cannot be scheduled. This ensures that critical workloads can run even when resources are scarce, which is the core purpose of PriorityClass.

Exam trap

CNCF often tests the misconception that PriorityClass controls CPU or memory resource allocation (like QoS classes), whereas it strictly controls scheduling priority and preemption behavior, not runtime resource guarantees.

How to eliminate wrong answers

Option A is wrong because node selection based on priority is handled by node affinity, node selectors, or taints/tolerations, not by PriorityClass. Option B is wrong because the order in which pods are started is influenced by PriorityClass only in the context of scheduling and preemption, but there is no guaranteed startup order; Kubernetes does not provide a sequential startup mechanism. Option D is wrong because CPU cycles are allocated based on resource requests and limits, not priority; priority does not affect CPU shares or scheduling fairness within the node's cgroups.

Full explanation →

147

MCQmedium

A pod is in ImagePullBackOff state. Which command can you run to get more details about the underlying error?

A.kubectl logs pod

B.kubectl get events --field-selector involvedObject.name=pod

C.kubectl describe pod

D.kubectl top pod

AnswerC

Events in the pod description include the reason for ImagePullBackOff.

Why this answer

The `kubectl describe pod` command provides detailed information about the pod, including its status, conditions, events, and container states. For an `ImagePullBackOff` error, the output will include the exact error message from the container runtime (e.g., 'Failed to pull image', 'manifest not found', or 'unauthorized'), which is essential for diagnosing the root cause.

Exam trap

The trap here is that candidates often confuse `kubectl logs` (which shows application output) with `kubectl describe` (which shows pod lifecycle events and container runtime errors), leading them to choose A when the container never started to produce logs.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` retrieves container logs, which are generated by the application inside the container; if the container never started due to ImagePullBackOff, there are no logs to fetch. Option B is wrong because `kubectl get events` with a field selector filters events by the pod's name, but the output may not include the detailed pull error from the kubelet or container runtime; `kubectl describe pod` consolidates those events alongside other critical status fields. Option D is wrong because `kubectl top pod` shows resource usage (CPU/memory) of running pods, which is irrelevant when the pod is in a non-running state like ImagePullBackOff.

Full explanation →

148

Multi-Selectmedium

A pod is in 'Pending' state. Which TWO of the following are possible causes? (Select 2)

Select 2 answers

A.Node has insufficient CPU or memory resources

B.Container exited with non-zero exit code

C.PersistentVolumeClaim is not bound

D.Container was killed due to OOM

E.Image name is misspelled

AnswersA, C

A Pod can only stay Pending when the scheduler is unable to place it on a node. If every node lacks sufficient allocatable CPU and/or memory to satisfy the Pod's `resources.requests`, kube-scheduler marks the Pod unschedulable and leaves it in Pending while continuously retrying scheduling. This is purely a pre-scheduling condition, so it remains until a node is scaled up or the requests are reduced.

Why this answer

Options A and C are correct. A pod remains in 'Pending' state when it cannot be scheduled or when required resources are not available. Insufficient CPU or memory resources (A) prevent the scheduler from placing the pod.

An unbound PersistentVolumeClaim (C) causes the pod to wait until the claim is bound. Option B: container exited with non-zero exit code would result in a CrashLoopBackOff or error state, not Pending. Option D: container killed due to OOM would cause the container to restart and enter CrashLoopBackOff.

Option E: misspelled image name leads to ImagePullBackOff, not Pending.

Full explanation →

149

MCQmedium

You apply the following NetworkPolicy: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress What effect does this policy have?

A.Ingress traffic from pods with label 'app: allowed' is allowed.

B.All ingress and egress traffic to/from pods in the namespace is denied.

C.The policy has no effect because no rules are specified.

D.All ingress traffic to any pod in the namespace is denied.

AnswerD

Correct. The policy selects all pods and denies ingress by default.

Why this answer

This NetworkPolicy uses a `podSelector: {}` which selects all pods in the namespace, and specifies `policyTypes: [Ingress]` with no ingress rules. According to Kubernetes NetworkPolicy semantics, when no ingress rules are defined, all ingress traffic is denied. This effectively creates a default-deny ingress policy for all pods in the namespace, making option D correct.

Exam trap

The trap here is that candidates often think a NetworkPolicy with no rules is ineffective or that `podSelector: {}` alone does nothing, but in Kubernetes, specifying `policyTypes` without corresponding rules triggers a default-deny for that traffic direction.

How to eliminate wrong answers

Option A is wrong because the policy has no ingress rules, so no ingress traffic is allowed based on labels; the `podSelector: {}` selects all pods, but without an `ingress` field, no traffic is permitted. Option B is wrong because the policy only specifies `Ingress` in `policyTypes`, not `Egress`, so egress traffic is not affected; a separate `Egress` policy would be needed to deny egress. Option C is wrong because the policy does have an effect: by specifying `policyTypes: [Ingress]` with no ingress rules, it defaults to denying all ingress traffic; this is a valid and intentional configuration.

Full explanation →

150

MCQmedium

A pod has been in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate, 2 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

A.The pod's image is incorrect

B.The kubelet on each node is not running

C.The pod has resource requests that exceed node capacity

D.The nodes are all cordoned

AnswerB

When kubelet is not running on a node, the node's heartbeat to the control plane is absent; after the node-monitor-grace-period, the Node controller marks the node NotReady and applies the node.kubernetes.io/not-ready:NoSchedule taint. Since no nodes are schedulable, the kube-scheduler cannot find a match for the pod, leaving it in Pending indefinitely. This is often the systemic cause when all nodes are unreachable or their kubelets have crashed.

Why this answer

The taints `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` are automatically added by the node controller when a node's kubelet stops reporting its status (the `node-monitor-grace-period`, default 40s, is exceeded). Since all three nodes exhibit these taints, the kubelet is not running on any of them, preventing the node from being marked `Ready` and causing the scheduler to find no suitable node for the pod.

Exam trap

A common trap is confusing taints added automatically by the node controller (like `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`) with taints added manually by an administrator (like `node.kubernetes.io/unschedulable` from `kubectl cordon`). In this scenario, the presence of these automatic taints on all nodes indicates that the kubelet is not running, not that nodes are cordoned.

How to eliminate wrong answers

Option A is wrong because an incorrect image would cause a `ErrImagePull` or `ImagePullBackOff` event, not a `Pending` state with taint-based scheduling failures. Option C is wrong because resource requests exceeding node capacity would produce events like `Insufficient cpu` or `Insufficient memory`, not taints related to node readiness or reachability. Option D is wrong because cordoned nodes have the `node.kubernetes.io/unschedulable:NoSchedule` taint (added by `kubectl cordon`), not the `not-ready` or `unreachable` taints; additionally, cordoning does not affect all nodes simultaneously unless explicitly done.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 76–150