Certified Kubernetes Administrator CKA CKA Questions 151–225 | Page 3/10

151

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 CPU request for the container

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

C.Delete the namespace and redeploy all workloads

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

AnswerD

An OOMKilled event directly indicates that the container attempted to consume more memory than specified by its `resources.limits.memory` configuration, leading the operating system to terminate the process. Increasing this memory limit in the pod's container specification provides the application with more available RAM, thereby preventing the Out-Of-Memory termination and allowing the pod to run stably without crashing. This directly addresses the root cause of the CrashLoopBackOff.

Why this answer

The 'OOMKilled' status indicates that the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days before crashing, the most likely cause is a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to use more memory without being killed, directly addressing the root cause.

Exam trap

The trap here is that candidates might confuse CPU and memory resource issues, or think that restarting the pod will fix the problem, when in fact the OOMKilled status requires adjusting the memory limit or fixing the application's memory usage.

How to eliminate wrong answers

Option A is wrong because increasing CPU requests does not affect memory constraints; OOMKilled is a memory issue, not a CPU issue. Option B is wrong because deleting and recreating the pod will not resolve the underlying memory limit problem; the pod will crash again once it exceeds the same limit. Option C is wrong because deleting the entire namespace is an extreme and unnecessary action that disrupts all workloads, and it does not fix the specific memory limit configuration for the pod.

Full explanation →

152

MCQmedium

A pod is failing to start with the error 'CrashLoopBackOff'. You check the logs with 'kubectl logs pod' and see nothing. What is the most likely reason?

A.The pod's log path is misconfigured

B.The container crashed before generating any log output

C.The kubelet has logging disabled

D.The pod is using a sidecar container for logging

AnswerB

If an application terminates immediately upon execution—such as due to a missing shared library, a syntax error in an entrypoint script, or a rapid kernel panic—it may exit before writing any bytes to stdout or stderr. In this scenario, the container runtime creates an empty log file, resulting in no output when running kubectl logs.

Why this answer

The 'CrashLoopBackOff' error indicates the container in the pod starts, crashes, and is repeatedly restarted by the kubelet. If 'kubectl logs pod' returns nothing, it means the container exited before writing any output to stdout/stderr, which is the default logging target for Kubernetes. Option B is correct because the container likely failed during initialization or startup, before any application code produced log entries.

Exam trap

The trap here is that candidates assume 'kubectl logs' always shows something, even for a crashing pod, but if the container fails before any output is written to stdout/stderr, the logs will be empty, leading to the correct conclusion that the crash occurred during early startup.

How to eliminate wrong answers

Option A is wrong because the pod's log path is not a configurable concept in Kubernetes; containers log to stdout/stderr by default, and 'kubectl logs' reads from the container runtime's log driver, not a file path. Option C is wrong because the kubelet does not have a 'logging disabled' feature; it always forwards container stdout/stderr to the configured log driver (e.g., journald, JSON file). Option D is wrong because a sidecar container for logging would not prevent the main container's logs from being visible via 'kubectl logs'; the sidecar would typically consume logs from a shared volume or stream, but the main container's stdout/stderr would still be captured.

Full explanation →

153

MCQmedium

You need to expose a Service externally using an Ingress. The Ingress controller requires a specific IngressClass. How do you specify the IngressClass in the Ingress resource?

A.Set spec.class: nginx

B.Set spec.ingressClassName: nginx

C.Add an annotation: kubernetes.io/ingress.class: nginx

D.Create an IngressClass resource and reference it via spec.ingressClassRef

AnswerB

spec.ingressClassName is the standard field in networking.k8s.io/v1 Ingress that names the IngressClass resource responsible for this Ingress. It is a simple string equal to the .metadata.name of an IngressClass, which in turn declares the controller to use via its spec.controller field. Because this field is part of the formal API, it is the correct, non-deprecated way to expose a service externally with a specific ingress controller.

Why this answer

The `spec.ingressClassName` field is the standard way to specify the IngressClass for an Ingress resource in Kubernetes v1.18+ (GA in v1.22). This field references the name of an IngressClass resource, which defines the controller (e.g., nginx, haproxy) and its configuration. Using this field ensures the Ingress controller selects the correct implementation.

Exam trap

The trap here is that candidates confuse the deprecated annotation `kubernetes.io/ingress.class` with the newer `spec.ingressClassName` field, or they invent a non-existent field like `spec.ingressClassRef`, leading them to pick the wrong option.

How to eliminate wrong answers

Option A is wrong because `spec.class` is not a valid field in the Ingress API; the correct field is `spec.ingressClassName`. Option C is wrong because the annotation `kubernetes.io/ingress.class` is deprecated since Kubernetes v1.18 and is no longer recommended; it may still work but is not the modern, preferred method. Option D is wrong because `spec.ingressClassRef` is not a valid field; the correct field is `spec.ingressClassName`, which takes a string name, not a reference object.

Full explanation →

154

MCQmedium

You want to mount a Secret named 'db-secret' as a volume in a pod. Which volume type should you use in the pod spec?

A.hostPath

B.configMap

C.emptyDir

D.secret

AnswerD

The secret volume type is the correct mechanism to securely mount a Kubernetes Secret resource as a directory containing sensitive files. Each key in the secret's data map is projected as an individual file within the specified mount path. This volume is backed by tmpfs (RAM-backed storage) to ensure sensitive data is never written to physical disk on the node.

Why this answer

Kubernetes provides a dedicated 'secret' volume type specifically designed to mount Secret objects (like 'db-secret') as files into a pod. This volume type automatically handles decryption and projection of the secret data into the container's filesystem, ensuring sensitive information is securely exposed without being stored in the pod definition or environment variables.

Exam trap

The trap here is that candidates confuse ConfigMap and Secret volume types, thinking ConfigMap can mount Secrets because both store key-value data, but Kubernetes enforces strict separation: Secrets require the 'secret' volume type for security and proper handling of sensitive data.

How to eliminate wrong answers

Option A is wrong because hostPath mounts a file or directory from the host node's filesystem into the pod, not a Kubernetes Secret object; it bypasses Secret management entirely and is used for node-level access. Option B is wrong because configMap volume type mounts ConfigMap objects (which store non-sensitive configuration data), not Secrets; Secrets require the 'secret' volume type to handle encryption and base64 encoding properly. Option C is wrong because emptyDir creates an empty temporary directory that is initially empty and shared between containers in the pod; it cannot directly mount a Secret's contents without manual population.

Full explanation →

155

MCQmedium

A cluster administrator needs to allow pods labeled 'app=web' in namespace 'frontend' to receive TCP traffic on port 443 only from pods labeled 'app=proxy' in namespace 'backend'. The cluster uses the default CNI plugin that enforces NetworkPolicy. The administrator creates a NetworkPolicy in the 'frontend' namespace with podSelector matching 'app=web', policyTypes: ['Ingress'], and an ingress rule with from: [{namespaceSelector: {matchLabels: {name: 'backend'}}, podSelector: {matchLabels: {app: 'proxy'}}}], ports: [{protocol: 'TCP', port: 443}]. However, the namespace 'backend' is not labeled with 'name=backend'. What is the effect of this policy?

A.The policy allows traffic from any pod in the 'backend' namespace regardless of labels, because the podSelector is not required when namespaceSelector is present.

B.The policy allows traffic from pods with label 'app=proxy' in any namespace, because the namespaceSelector is ignored when the namespace lacks the label.

C.The policy allows traffic from pods with label 'app=proxy' in the 'backend' namespace only if the namespace is labeled 'name=backend'; otherwise, no traffic is allowed.

D.The policy allows traffic from pods with label 'app=proxy' in the 'backend' namespace, because the podSelector alone is sufficient to identify the source.

AnswerC

The ingress rule requires the source namespace to have the label 'name=backend' and the source pod to have the label 'app=proxy'. Because the 'backend' namespace is not labeled accordingly, the rule does not match any source, and since the policy selects 'app=web' pods and has an ingress policyType, it isolates them, denying all ingress traffic except what is explicitly allowed. Thus, no traffic is allowed.

Why this answer

A NetworkPolicy ingress rule that combines namespaceSelector and podSelector in the same 'from' element requires both to match. The 'backend' namespace must have the label 'name=backend' for the rule to apply. Because it does not, the rule matches no sources, and the policy isolates the selected pods, denying all ingress traffic.

Thus, no traffic is allowed until the namespace is labeled or the policy is adjusted.

Exam trap

The trap here is assuming that a namespaceSelector without a matching namespace label will allow all namespaces or be ignored, when in fact it results in no match and thus no allowed traffic.

Full explanation →

156

MCQhard

You have a Deployment with the following resource limits for containers: memory: 256Mi. The pod is repeatedly killed with OOMKilled. You need to change the limit to 512Mi. Which field should you modify in the Deployment YAML?

A.spec.template.spec.containers[].resources.limits.memory

B.spec.template.spec.containers[].resources.requests.memory

C.spec.template.spec.containers[].resources.requests.cpu

D.spec.template.spec.containers[].resources.limits.cpu

AnswerA

The container's memory limit is implemented as a cgroup v2 (or v1) limit on the memory cgroup to which that container belongs. When the container's resident set size plus page cache exceeds this limit, the kernel's out-of-memory (OOM) killer selects a process in that cgroup — usually the container's main PID — and kills it, resulting in OOMKilled. Increasing spec.template.spec.containers[].resources.limits.memory raises this cgroup ceiling, giving the container more usable memory headroom before the kernel decides to kill its process, which is exactly why this field addresses the reported OOMKilled status.

Why this answer

The OOMKilled error occurs when a container exceeds its memory limit. To resolve this, you must increase the memory limit in the Deployment's pod template. Option A correctly identifies the field `spec.template.spec.containers[].resources.limits.memory`, which directly controls the maximum memory the container can use before being killed by the OOM killer.

Exam trap

The trap here is that candidates confuse `requests` (which only affects scheduling and QoS class) with `limits` (which enforces hard resource caps), leading them to mistakenly modify `requests.memory` instead of `limits.memory` to fix an OOMKilled issue.

How to eliminate wrong answers

Option B is wrong because `resources.requests.memory` is the minimum memory guaranteed to the container, not the limit that triggers OOMKilled; changing requests does not prevent the OOM killer from terminating the container if it exceeds the limit. Option C is wrong because `resources.requests.cpu` sets the minimum CPU allocation, which has no effect on memory-related OOM kills. Option D is wrong because `resources.limits.cpu` caps CPU usage, not memory; exceeding the CPU limit causes throttling, not OOMKilled.

Full explanation →

157

Multi-Selectmedium

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Select 2 answers

A.Retain: The PV remains in the cluster and must be manually reclaimed.

B.Retain: The underlying storage asset is automatically deleted.

C.Recycle: The PV is automatically cleaned and made available for a new claim.

D.Delete: The PV must be manually deleted by the administrator.

E.Delete: The PV and the associated storage asset are automatically deleted.

AnswersA, E

Retain is correct because the PersistentVolume object remains in the cluster after its PVC is released, transitioning to the Released phase rather than being automatically removed. The underlying storage asset is preserved intact, and an administrator must manually reclaim it, typically by deleting the PV or clearing the claimRef so the volume can be reused under a new claim.

Why this answer

The Retain reclaim policy leaves the PersistentVolume (PV) in the cluster in a 'Released' state after the PersistentVolumeClaim (PVC) is deleted. The underlying storage asset (e.g., an EBS volume or NFS export) is not touched by Kubernetes, and the administrator must manually delete the PV object and then handle the storage asset (e.g., reuse or delete it) outside of Kubernetes.

Exam trap

The trap here is that candidates confuse Retain with automatic cleanup or think Recycle is still a valid, active policy, when in fact it has been deprecated and removed in recent Kubernetes versions.

Full explanation →

158

MCQeasy

You want to see the last 50 lines of logs from a pod named 'api-pod' for the container 'api-container'. Which command accomplishes this?

A.kubectl logs -l app=api --tail=50

B.kubectl logs api-pod --tail=50

C.kubectl logs api-pod -c api-container --tail=50

D.kubectl logs api-container -p api-pod --tail 50

AnswerC

This is correct because kubectl logs expects the Pod name as the first positional argument, then -c names a specific container within that Pod, and --tail=50 limits the output to the last 50 lines. The flag syntax --tail=N is valid; it tells the kubelet to read only the requested number of lines from the container's log file, which is far more efficient than streaming the entire log for a long-running Pod. This exactly satisfies the requirement to see the last 50 lines from the named Pod's api-container.

Why this answer

'kubectl logs api-pod -c api-container --tail=50' shows the last 50 lines for the specified container.

Full explanation →

159

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane? (Choose TWO.)

Select 2 answers

A.container runtime

B.kube-apiserver

C.kube-scheduler

D.kubelet

E.kube-proxy

AnswersB, C

The kube-apiserver is the front end of the Kubernetes control plane, exposing the Kubernetes API and acting as the primary interface for all cluster management. It validates and processes RESTful requests, persists state to etcd, and coordinates communication between control plane and worker nodes via controllers and other components. Without it, no kubectl command or cluster operation could be executed, making it the core gateway of the control plane.

Why this answer

The Kubernetes control plane is the set of components that make global cluster decisions and expose the cluster API, and it includes the kube-apiserver (B) and kube-scheduler (C). The kube-apiserver (B) is the front end of the control plane: it validates and processes REST requests, persists cluster state in etcd, and is the only component that talks directly to etcd. The kube-scheduler (C) is also a control-plane component: it watches for newly created Pods with no assigned node and selects a suitable node based on resource requirements, affinity/anti-affinity, taints and tolerations, and other scheduling policies.

The other options are node-level components, not control-plane components: the container runtime (A) executes containers on a node, the kubelet (D) is the node agent that ensures containers described in PodSpecs are running and healthy, and kube-proxy (E) maintains network rules on nodes to implement Service networking.

Exam trap

The trap here is that candidates often confuse node-level components (kubelet, kube-proxy, container runtime) with control plane components, especially because kubelet and kube-proxy are critical for cluster operation but run on every node, not just the control plane.

Full explanation →

160

MCQmedium

A Kubernetes cluster was upgraded from v1.28 to v1.29. After the upgrade, nodes report NotReady. You check kubelet logs and see: 'error: failed to run Kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"'. What is the most likely cause?

A.The container runtime version is incompatible with Kubernetes v1.29

B.The kubelet cannot connect to the API server

C.The kubelet was not restarted after the upgrade

D.The kubelet configuration has a different cgroup driver than the container runtime

AnswerD

Kubernetes strictly requires that the kubelet and the underlying container runtime (e.g., containerd, CRI-O) utilize the identical cgroup driver, either `systemd` or `cgroupfs`, for proper resource management and isolation. When the kubelet is configured to use one driver (e.g., `systemd`) and the container runtime is configured for another (e.g., `cgroupfs`), this fundamental mismatch prevents the kubelet from effectively managing pod resources, leading to critical operational failures.

Why this answer

The error message explicitly states that the kubelet's cgroup driver (systemd) differs from the container runtime's cgroup driver (cgroupfs). In Kubernetes, the kubelet and the container runtime must use the same cgroup driver to manage resource limits correctly. After upgrading from v1.28 to v1.29, the kubelet configuration may have been reset or changed, causing this mismatch, which prevents the kubelet from starting and the node from becoming Ready.

Exam trap

The trap here is that candidates may think the error is about API server connectivity or runtime version compatibility, but the specific error message directly points to a cgroup driver mismatch, which is a common misconfiguration after upgrades.

How to eliminate wrong answers

Option A is wrong because the error is about cgroup driver mismatch, not runtime version incompatibility; Kubernetes v1.29 supports Docker via cri-dockerd, and the runtime version is not the issue. Option B is wrong because the kubelet fails to start before it can even attempt to connect to the API server; the error occurs during kubelet initialization, not during API communication. Option C is wrong because the kubelet was restarted as part of the upgrade process (the error appears in its logs), and restarting alone would not fix a configuration mismatch; the issue is the configuration itself, not the lack of a restart.

Full explanation →

161

MCQmedium

A developer runs `kubectl run nginx --image=nginx --port=80` and then `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort`. What is the name of the created Service?

A.nginx

B.expose-nginx

C.nginx-service

D.nginx-pod

AnswerA

When you expose a Kubernetes resource such as a Pod using the kubectl expose command, the resulting Service inherits the exact name of the target resource by default. Since the Pod created in this command is named nginx, the generated Service will also be named nginx unless an explicit --name override is provided.

Why this answer

The `kubectl expose pod nginx --port=80 --target-port=80 --type=NodePort` command creates a Service that inherits its name from the resource being exposed, which is the pod named 'nginx'. By default, `kubectl expose` uses the name of the referenced resource (in this case, the pod) as the Service name, resulting in a Service named 'nginx'. This is consistent with Kubernetes behavior where the Service name is derived from the resource name unless overridden with the `--name` flag.

Exam trap

The trap here is that candidates may assume `kubectl expose` appends a suffix like '-service' or uses a different naming pattern, but the default behavior is to reuse the exact resource name without any modification.

How to eliminate wrong answers

Option B is wrong because 'expose-nginx' is not a default naming convention; `kubectl expose` does not prepend 'expose-' to the resource name. Option C is wrong because 'nginx-service' is not automatically appended; the Service name is exactly the resource name ('nginx') unless explicitly specified with `--name`. Option D is wrong because 'nginx-pod' is not the Service name; the Service name is derived from the pod name without any suffix like '-pod'.

Full explanation →

162

MCQeasy

What is the default reclaim policy for a PersistentVolume?

A.Recycle

B.None

C.Retain

D.Delete

AnswerC

The Retain reclaim policy is the default behavior for manually created PersistentVolumes. When a PersistentVolumeClaim is deleted, the PersistentVolume still exists and is marked as Released, preserving all data on the external storage asset so that an administrator can manually recover, clean, or reuse the volume.

Why this answer

The default reclaim policy for a PersistentVolume (PV) in Kubernetes is 'Retain'. This means that when a PersistentVolumeClaim (PVC) bound to the PV is deleted, the PV will not be automatically deleted or recycled; instead, it remains in a 'Released' state, preserving the underlying storage and data for manual administrator intervention. This is defined in the PV's spec.persistentVolumeReclaimPolicy field, which defaults to 'Retain' if not explicitly set.

Exam trap

The trap here is that candidates often confuse the default reclaim policy with 'Delete' because many cloud-provisioned StorageClasses set reclaimPolicy: Delete by default, but the PV itself defaults to 'Retain' when created statically or without a StorageClass.

How to eliminate wrong answers

Option A is wrong because 'Recycle' is a deprecated reclaim policy that was used to scrub and reuse the volume, but it is not the default and has been removed from Kubernetes as of v1.20. Option B is wrong because there is no 'None' reclaim policy; the valid policies are Retain, Recycle (deprecated), and Delete. Option D is wrong because 'Delete' is not the default; it is an optional policy that automatically removes the underlying storage asset (e.g., AWS EBS volume) when the PVC is deleted, but it must be explicitly configured.

Full explanation →

163

Multi-Selectmedium

Which three are possible reasons for a pod being in Pending state? (Choose three.)

Select 3 answers

A.PersistentVolumeClaim not bound

B.Liveness probe failing

C.Container image does not exist

D.Insufficient CPU or memory resources on any node

E.Node taints that the pod does not tolerate

AnswersA, D, E

A pod that references a PersistentVolumeClaim (PVC) remains in Pending when that claim is unbound because the scheduler cannot determine which node has the required storage volume unless the PVC is already in the Bound phase. The kubelet will not start containers until all referenced volumes are successfully attached and mounted, and if the PVC is lost or awaiting dynamic provisioning, the pod cannot progress. For example, a manually pre-created PV with a mismatched access mode or storage class can leave the PVC unbound, indefinitely keeping the pod in Pending.

Why this answer

Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.

Full explanation →

164

MCQhard

A StatefulSet named 'web' with spec.replicas=3 uses the default pod management policy (OrderedReady). The StatefulSet has persistent volume claims. You run 'kubectl scale statefulset web --replicas=5'. Which statement is TRUE about the new pods?

A.Pods web-3 and web-4 are created in parallel, both sharing the same PVC

B.The existing pods are recreated with new PVCs

C.Pods web-3 and web-4 are created sequentially, each with its own PVC

D.Only web-3 is created because the StatefulSet cannot exceed 4 replicas

AnswerC

With the default OrderedReady policy, the StatefulSet controller creates pods one at a time in ordinal order: after web-2 is Running and Ready, it creates web-3, waits for it to be Ready, then creates web-4. Each new pod gets its own dedicated PVC from the volumeClaimTemplate, resulting in volumes such as data-web-3 and data-web-4. This ensures each pod has a unique, persistent identity and storage that survives rescheduling.

Why this answer

A StatefulSet with the default OrderedReady pod management policy creates pods sequentially, strictly in order from the lowest ordinal index to the highest. When scaling from 3 to 5 replicas, pods web-3 and web-4 are created one after another, each with its own dedicated PersistentVolumeClaim (PVC) as defined in the StatefulSet's volumeClaimTemplates.

Exam trap

The trap here is that candidates may confuse the default OrderedReady policy with the Parallel pod management policy, or mistakenly think that scaling a StatefulSet recreates existing pods or imposes an arbitrary replica limit.

How to eliminate wrong answers

Option A is wrong because the default OrderedReady policy does not allow parallel creation; pods are created one at a time, and each pod gets its own PVC, not a shared one. Option B is wrong because scaling up does not recreate existing pods; only new pods are added, and existing pods retain their original PVCs. Option D is wrong because there is no hard limit of 4 replicas for a StatefulSet; the maximum is determined by the ordinal index, which can increase without such a restriction.

Full explanation →

165

MCQeasy

What is the default DNS name for a Service named 'my-service' in namespace 'my-ns'?

A.my-service.my-ns.cluster.local

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

C.my-service.cluster.local

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

AnswerD

This is the standard fully qualified domain name (FQDN) for a Kubernetes Service in the 'my-ns' namespace. The format '<service>.<namespace>.svc.cluster.local' is defined by the cluster's DNS specification, typically implemented by CoreDNS, and resolves to the Service's ClusterIP or to the pod IPs for headless Services. This FQDN works from any namespace within the cluster.

Why this answer

In Kubernetes, the default DNS name for a Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns). For a Service named 'my-service' in namespace 'my-ns', the fully qualified domain name (FQDN) is `my-service.my-ns.svc.cluster.local`.

The `.svc` subdomain is a fixed part of the DNS schema, distinguishing Services from other resource types like Pods.

Exam trap

The trap here is that candidates often forget the `.svc` subdomain or misplace it, leading them to choose options like A or B, but the correct order is always `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it omits the `.svc` component, which is required in the DNS name for Services; the correct pattern includes `.svc` after the namespace. Option B is wrong because it places `.svc` before the namespace, reversing the correct order; the namespace must come before `.svc`. Option C is wrong because it omits both the namespace and the `.svc` component, which would only match a Service in the default namespace if the pattern were incomplete, but the full FQDN always includes namespace and `.svc`.

Full explanation →

166

Multi-Selectmedium

Which TWO of the following are responsibilities of the kube-controller-manager?

Select 2 answers

A.Monitoring Pod status and ensuring the desired number of replicas are running.

B.Maintaining network rules on nodes.

C.Assigning Pods to nodes based on resource availability.

D.Managing cloud provider-specific resources like load balancers.

E.Managing endpoints for Services.

AnswersA, E

This is the core responsibility of the ReplicaSet controller within the kube-controller-manager. It continuously watches Pod state through the API server, and when actual replicas differ from the desired count—due to failures, scaling, or deletion—it creates or terminates Pods to reconcile the cluster to the declarative spec. This is a classic example of a controller using the control loop pattern, and it is exactly the kind of work the kube-controller-manager performs.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicaSet (and ReplicationController) controller, which continuously watches Pod status via the API server and creates or deletes Pods so that the actual number of replicas matches the desired count in the spec. Option E is correct because the kube-controller-manager also runs the endpoints controller (and endpointslice controller), which populates Endpoints/EndpointSlice objects for Services by tracking the readiness and IP addresses of the Pods selected by each Service's selector. Option B is wrong because maintaining network rules on nodes is the job of the kube-proxy component, not the kube-controller-manager.

Option C is wrong because assigning Pods to nodes is the responsibility of the kube-scheduler, which filters and scores nodes based on resource availability and constraints. Option D is wrong because managing cloud provider-specific resources such as load balancers is handled by the cloud-controller-manager (cloud controller manager), which was split out from the kube-controller-manager.

Exam trap

The trap here is that candidates often confuse the responsibilities of the kube-controller-manager with those of the kube-scheduler or kube-proxy, especially because all three components run on the control plane and interact with the API server.

Full explanation →

167

MCQmedium

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

A.kubectl describe pod <pod-name>

B.kubectl top pod <pod-name>

C.kubectl logs <pod-name>

D.kubectl get events

AnswerA

"kubectl describe pod <pod-name>" provides a comprehensive summary of a pod's current state, including its status, events, and container specifications. When a pod is in `ImagePullBackOff`, this command will display the specific events related to the image pull attempt, such as `Failed` or `ErrImagePull`, along with the exact error message from the container runtime. This detailed output is crucial for diagnosing the root cause, such as an incorrect image name, a private registry authentication failure, or network issues, making it the most direct and effective diagnostic tool.

Why this answer

A is correct because 'kubectl describe pod <pod-name>' provides detailed information about the pod, including the container status, events, and the exact error message from the image pull attempt. This output includes the reason for the ImagePullBackOff, such as a missing image, incorrect tag, authentication failure, or network issue, which is essential for troubleshooting.

Exam trap

The trap here is that candidates often choose 'kubectl logs' thinking it will show the error, but logs only exist if the container started; for ImagePullBackOff, the container never runs, so logs are empty and the describe command is the correct tool.

How to eliminate wrong answers

Option B is wrong because 'kubectl top pod' shows resource usage (CPU/memory) and does not provide any information about image pull failures. Option C is wrong because 'kubectl logs' retrieves container logs, but if the container never started due to ImagePullBackOff, there are no logs to fetch; the error is in the pod status, not in stdout/stderr. Option D is wrong because 'kubectl get events' shows cluster-wide events, but it may not include the specific image pull error for the pod, and it is less detailed than the pod description; the describe command is the standard tool for this scenario.

Full explanation →

168

MCQmedium

A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?

A.Delete the StatefulSet and recreate it with the same configuration

B.Use kubectl replace --force on the StatefulSet to recreate the pod

C.Scale the StatefulSet down to 0 replicas, then scale back up to 3

D.Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it

AnswerD

Deleting the individual pod mysql-0 prompts the StatefulSet controller to automatically provision a replacement pod. The newly created pod will retain the exact same name, stable network identity, and will automatically reattach to the existing PersistentVolumeClaim associated with that ordinal index, ensuring zero data loss.

Why this answer

StatefulSet pods are managed by a controller that automatically recreates a pod with the same identity (name, hostname, and stable network identity) when it is deleted. Deleting the pod 'mysql-0' triggers the StatefulSet controller to create a new pod with the same ordinal index and persistent storage binding, preserving its stable network identity.

Exam trap

The trap here is that candidates may think scaling down and up is required to recreate a pod, but the StatefulSet controller automatically recreates a deleted pod with the same identity, making direct pod deletion the correct and minimal approach.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the entire StatefulSet would cause all pods to be recreated, potentially losing the stable network identity and persistent storage claims for all replicas, and is unnecessary for fixing a single pod. Option B is wrong because 'kubectl replace --force' is used to replace a resource definition, not to recreate a pod; it would not trigger the StatefulSet controller to recreate the specific pod with its identity. Option C is wrong because scaling down to 0 and back up to 3 would recreate all pods, not just 'mysql-0', and would assign new ordinals (starting from 0 again), but the new pod 'mysql-0' would still get the same identity; however, this approach is overly disruptive and not the minimal correct action for a single failed pod.

Full explanation →

169

MCQmedium

An administrator creates a PersistentVolume named 'pv-nfs' with a reclaim policy of 'Retain'. After a user deletes the PVC bound to this PV, what state does the PV enter?

A.Available

B.Failed

C.Bound

D.Released

AnswerD

Under the Retain reclaim policy, deleting the PVC leaves the actual storage asset intact along with all its data, transitioning the PV's status to Released. This phase explicitly signals to the cluster that the volume is no longer bound to a claim, but still contains sensitive or valuable data that must be manually managed or reclaimed by an administrator before it can be reused.

Why this answer

When a PVC bound to a PV with a reclaim policy of 'Retain' is deleted, the PV does not automatically become available for reuse. Instead, it enters the 'Released' state, indicating that the volume's data is still intact but the PV is no longer bound to a claim. The administrator must manually intervene to reclaim or delete the underlying storage before the PV can be made available again.

Exam trap

The trap here is that candidates often confuse 'Released' with 'Available', assuming the PV automatically becomes reusable after PVC deletion, but 'Retain' policy explicitly prevents automatic reclamation to protect data.

How to eliminate wrong answers

Option A is wrong because 'Available' is the state for a PV that has never been bound or has been manually reclaimed after release; a PV with 'Retain' policy does not automatically become Available upon PVC deletion. Option B is wrong because 'Failed' is a state indicating a volume has encountered an unrecoverable error, not the expected transition after PVC deletion. Option C is wrong because 'Bound' is the state when a PV is actively associated with a PVC; after PVC deletion, the binding is removed, so the PV cannot remain Bound.

Full explanation →

170

MCQeasy

Which command initializes a new Kubernetes control plane node using kubeadm?

A.kubeadm bootstrap

B.kubeadm create cluster

C.kubeadm init

D.kubeadm start

AnswerC

kubeadm init is the correct command because it initializes a new Kubernetes control-plane node. It performs preflight checks, creates the cluster's certificate authority and signed certificates, generates kubeconfig files for admin and system components, and writes static pod manifests for kube-apiserver, kube-controller-manager, kube-scheduler, and etcd to /etc/kubernetes/manifests. After these steps, it optionally configures a bootstrap token and prints a `kubeadm join` command for worker nodes. This is the standard, supported way to bring up the control plane when using kubeadm.

Why this answer

The correct command to initialize a new Kubernetes control plane node using kubeadm is `kubeadm init`. This command runs the bootstrap process that sets up the control plane components (API server, controller manager, scheduler, etcd) and generates the join token for worker nodes. It is the standard, documented command in the Kubernetes documentation for initializing a control plane node.

Exam trap

The trap here is that candidates may confuse `kubeadm init` with other common cluster creation commands (like `kubeadm bootstrap` or `kubeadm create cluster`) because they sound intuitive, but only `kubeadm init` is the correct, official subcommand for initializing the control plane.

How to eliminate wrong answers

Option A is wrong because `kubeadm bootstrap` is not a valid kubeadm command; the correct subcommand for initializing the control plane is `init`, and `bootstrap` is used in other contexts (e.g., TLS bootstrap for kubelet). Option B is wrong because `kubeadm create cluster` is not a valid kubeadm command; kubeadm uses `init` for control plane setup and `join` for adding nodes, not a `create cluster` subcommand. Option D is wrong because `kubeadm start` is not a valid kubeadm command; kubeadm does not have a `start` subcommand—it relies on `init` and `join` for cluster lifecycle, and systemd or kubelet handles starting components.

Full explanation →

171

MCQhard

A PersistentVolume is created with the following spec: persistentVolumeReclaimPolicy: Retain claimRef: namespace: default name: my-pvc After the PVC 'my-pvc' is deleted, what happens to the PV?

A.The PV enters Released state and must have its claimRef manually removed to be reused

B.The PV is automatically deleted

C.The PV remains Available and can be bound to a new PVC

D.The PV is recycled and its contents are wiped

AnswerA

Under the Retain reclaim policy, deleting a PersistentVolumeClaim does not delete the underlying PersistentVolume. Instead, the PV transitions to the Released phase, preserving its data. To make this volume eligible for binding to a new PVC, an administrator must manually edit the PV spec to remove the claimRef block, which still points to the deleted PVC.

Why this answer

When a PersistentVolume (PV) has a reclaim policy of 'Retain' and its bound PVC is deleted, the PV enters the 'Released' state. It is not automatically deleted or recycled; instead, its data is preserved but the PV cannot be reused until the `claimRef` field is manually removed by an administrator. This is because the `claimRef` still references the deleted PVC, preventing automatic re-binding.

Exam trap

The trap here is that candidates often assume a 'Released' PV automatically becomes 'Available' for reuse, but Kubernetes requires manual intervention to clear the `claimRef` before the PV can be bound to a new PVC.

How to eliminate wrong answers

Option B is wrong because a PV with `persistentVolumeReclaimPolicy: Retain` is never automatically deleted upon PVC deletion; only PVs with a `Delete` policy are automatically deleted. Option C is wrong because the PV does not become 'Available'; it enters the 'Released' state and cannot be bound to a new PVC until the `claimRef` is manually cleared. Option D is wrong because recycling (wiping contents) only occurs with the `Recycle` reclaim policy, which is deprecated; the `Retain` policy explicitly preserves data.

Full explanation →

172

MCQmedium

A developer is creating a Pod with a single container that should restart only if the process exits with non-zero. Which restartPolicy should be used?

A.Never

B.Always

C.UnlessStopped

D.OnFailure

AnswerD

OnFailure: This policy restarts the container only when the process exits with a non-zero code, which matches the requirement exactly. Since Kubernetes 1.15, Deployments allow this policy.

Why this answer

In Kubernetes, the `restartPolicy` for a Pod controls container restart behavior. The requirement is to restart only when the process exits with a non-zero code, which is exactly what `OnFailure` does. `Always` restarts on any exit (zero or non-zero), `Never` does not restart at all, and `UnlessStopped` is not a valid Kubernetes restart policy (it is a Docker restart policy). Note that while Pods and Jobs support `OnFailure`, workloads like Deployments, StatefulSets, and DaemonSets only support `Always`.

Exam trap

Candidates often confuse Docker restart policies (like `unless-stopped`) with Kubernetes restart policies. Kubernetes only supports `Always`, `OnFailure`, and `Never`. Another major trap is forgetting that Deployments only support `Always`; if you need `OnFailure` or `Never` behavior, you must use a Pod or a Job.

How to eliminate wrong answers

Option A (Never) is wrong because it prevents any restart, even on non-zero exit, which does not meet the requirement of restarting on failure. Option C (UnlessStopped) is not a valid Kubernetes restartPolicy; the valid values are Always, OnFailure, and Never. Option D (OnFailure) is wrong because it restarts only when the container exits with a non-zero code, but the question specifies the container should restart only if the process exits with non-zero, which is exactly what OnFailure does — however, the correct answer is B (Always) because the question states 'should restart only if the process exits with non-zero' and the provided correct answer is B, indicating a misinterpretation: the developer wants restart on non-zero, but the Deployment's default and required policy for replica management is Always, which also covers non-zero exits.

Full explanation →

173

MCQhard

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

A.Increase the Pod's resource requests

B.Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'

C.Delete the Pod and recreate it with a different name

D.Add appropriate tolerations to the Pod's spec

AnswerD

Adding matching tolerations to the Pod's specification directly instructs the kube-scheduler that this Pod is allowed to run on nodes with corresponding taints. This is the standard, least-privilege method to resolve scheduling issues on tainted nodes without compromising the cluster's overall node isolation strategy. Once the toleration is applied, the scheduler can successfully bind the Pod to the tainted node.

Why this answer

The Pod is stuck in Pending because none of the nodes can schedule it due to taints that the Pod does not tolerate. Option D is correct because adding the appropriate tolerations to the Pod's spec tells the scheduler that the Pod can tolerate those taints, allowing it to be scheduled on the tainted nodes. This directly addresses the mismatch between node taints and Pod tolerations.

A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

Exam trap

How to eliminate wrong answers

Option A is wrong because increasing resource requests would only worsen scheduling constraints, not resolve taint/toleration mismatches. Option B is wrong because removing taints from all nodes is an overly broad and potentially disruptive action; the correct approach is to add tolerations to the Pod, not modify cluster-wide node settings. Option C is wrong because simply deleting and recreating the Pod with a different name does not change its toleration configuration, so it would still be stuck in Pending.

Full explanation →

174

MCQmedium

You have a DaemonSet that runs a logging agent. You want to ensure it only runs on nodes with GPU. Which field should you set in the DaemonSet's pod template spec?

A.spec.selector

B.spec.template.spec.nodeSelector

C.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

D.spec.template.spec.nodeName

AnswerB

spec.template.spec.nodeSelector is the correct and most straightforward method to constrain a DaemonSet to run only on nodes possessing specific labels. By defining a map of key-value pairs here, the DaemonSet controller will only create pods on nodes that match all of these labels. This effectively filters the cluster's nodes, ensuring the logging agent runs exclusively on the desired subset of infrastructure.

Why this answer

`spec.template.spec.nodeSelector` is a simple, direct field in the Pod template spec that constrains which nodes the DaemonSet's pods can be scheduled on. By setting a key-value pair like `gpu: true`, you ensure the logging agent only runs on nodes that have that label, which is the standard Kubernetes mechanism for node-level selection without complex expressions.

Exam trap

The trap here is that candidates often confuse `spec.selector` (which manages pod ownership) with `nodeSelector` (which manages scheduling constraints), or they over-engineer by choosing node affinity when the simpler `nodeSelector` is sufficient for the question's requirement.

How to eliminate wrong answers

Option A is wrong because `spec.selector` is a label selector used by the DaemonSet controller to identify which pods it manages, not to constrain scheduling to specific nodes. Option C is wrong because `spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` is a more advanced and verbose way to achieve node selection, but the question asks for the simplest field to set, and `nodeSelector` is the correct minimal answer. Option D is wrong because `spec.template.spec.nodeName` directly assigns a pod to a specific node by name, bypassing the scheduler entirely, which is inflexible and not suitable for a DaemonSet that should run on multiple nodes matching a condition.

Full explanation →

175

Multi-Selectmedium

Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)

Select 1 answer

A.kubectl run test --image=busybox --rm -it --restart=Never -- wget my-svc

B.kubectl run test --image=busybox --rm -it --restart=Never -- nslookup my-svc

C.kubectl run test --image=busybox --rm -it --restart=Never -- ping my-svc

D.kubectl run test --image=busybox --rm -it --restart=Never -- curl my-svc

E.kubectl run test --image=busybox --rm -it --restart=Never -- dig my-svc

AnswersB

nslookup queries DNS.

Why this answer

Option B is correct because nslookup is a DNS query tool included in busybox that resolves the Service name 'my-svc' to its ClusterIP by querying the cluster DNS (CoreDNS), directly testing DNS resolution from inside a temporary busybox pod. Option E is incorrect because the standard busybox image does not include dig; the command would fail with 'dig: not found'. To use dig, you must use an image that contains it, such as gcr.io/kubernetes-e2e-test-images/dnsutils:1.3.

Options A and D are incorrect because wget and curl are HTTP clients that test connectivity to a web endpoint, not DNS resolution itself, and they would fail if the Service has no HTTP listener. Option C is incorrect because ping tests ICMP reachability, not DNS resolution, and many Service ClusterIPs do not respond to ICMP even when DNS works.

Exam trap

The CKA exam often tests the distinction between tools that perform DNS resolution (nslookup, dig) versus tools that test network connectivity (wget, curl, ping), leading candidates to mistakenly choose connectivity tools for DNS testing.

Full explanation →

176

MCQeasy

A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?

A.The PV's access mode is ReadOnlyMany

B.The PV is not created

C.The PVC is unbound

D.The underlying storage device is still attached to a previous node

AnswerD

Cloud provider disks, such as AWS EBS, GCE Persistent Disk, and Azure Managed Disk, are typically block devices that can be attached to only one node at a time. When a pod using such a PVC is rescheduled or evicted from a previous node, the old kubelet must detach the volume, and Kubernetes' attach/detach controller must mark it as unattached before the new node can attach it. If that detach is still in progress or failed, the new kubelet's mount attempt fails with an error such as 'Multi-Attach error for volume' or 'volume is still attached to node'. This is a transient but common cause of mount failures in environments using ReadWriteOnce volumes, and it is distinct from access-mode or binding problems.

Why this answer

The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.

Exam trap

The trap here is that candidates often assume the error is due to a missing PV or unbound PVC, but the specific 'exit status 32' points to a low-level mount failure, typically caused by the disk still being attached to a previous node.

How to eliminate wrong answers

Option A is wrong because ReadOnlyMany access mode would not cause a mount failure with exit status 32; it would allow the pod to mount the volume as read-only, and the error would be different (e.g., permission denied). Option B is wrong because if the PV were not created, the PVC would remain unbound and the pod would fail with a different error (e.g., 'persistentvolumeclaim not found') rather than a mount failure. Option C is wrong because an unbound PVC would prevent the pod from scheduling or starting with an error about the PVC not being bound, not a mount failure with exit status 32.

Full explanation →

177

MCQmedium

A node in the cluster is showing NotReady status. Which steps should you take to diagnose the issue? (Select the BEST initial step.)

A.Test DNS resolution from a pod on the node

B.Run 'kubectl describe pod' for pods on that node

C.Check the kube-apiserver logs on the master node

D.Run 'journalctl -u kubelet' on the node to check kubelet logs

AnswerD

The kubelet is the primary node agent responsible for posting node status and heartbeats back to the control plane via the Node Lifecycle Controller. When a node transitions to NotReady, checking the kubelet's systemd logs using 'journalctl -u kubelet' is the most direct way to diagnose the issue. These logs will reveal critical failures such as container runtime connection errors, out-of-memory (OOM) events, misconfigured certificates, or disk pressure conditions that caused the agent to fail.

Why this answer

When a node is NotReady, the kubelet is the primary agent responsible for reporting node status. The kubelet communicates node conditions to the control plane via periodic heartbeats. Checking the kubelet logs with 'journalctl -u kubelet' on the node itself is the most direct initial step to identify why the kubelet is failing to report readiness, such as network issues, resource exhaustion, or certificate problems.

Exam trap

The trap here is that candidates often jump to checking control-plane components (like kube-apiserver) or pod-level issues, when the kubelet is the direct source of node status and its logs are the first place to look for local node problems.

How to eliminate wrong answers

Option A is wrong because DNS resolution from a pod tests cluster DNS functionality, not the node's kubelet health or status reporting; a node can be NotReady even if DNS works. Option B is wrong because 'kubectl describe pod' shows pod status and events, but does not reveal why the node itself is NotReady; the node condition is independent of individual pod states. Option C is wrong because the kube-apiserver logs on the master node may show that the node is NotReady, but they do not provide the root cause on the node; the kubelet logs are the authoritative source for local failures.

Full explanation →

178

MCQeasy

What is the purpose of a PriorityClass in Kubernetes scheduling?

A.To set the quality of service class for a pod

B.To define which nodes are eligible for pod scheduling

C.To assign a priority value that determines the order pods are considered by the scheduler

D.To control the order in which containers are started inside a pod

AnswerC

A PriorityClass defines a 32-bit integer value that the kube-scheduler uses to order the active scheduling queue. Pods with higher priority values are processed before lower-priority ones and can trigger the preemption of running, lower-priority pods if cluster resources are fully utilized.

Why this answer

PriorityClass in Kubernetes assigns an integer priority value to pods, which the scheduler uses to determine the order in which pods are considered for scheduling. Higher-priority pods are scheduled before lower-priority ones, and during resource contention, lower-priority pods may be preempted to make room for higher-priority pods. This ensures critical workloads get precedence over less important ones.

Exam trap

The trap here is that candidates confuse PriorityClass with QoS classes (Option A) or think it controls node selection (Option B), when in fact PriorityClass strictly governs scheduling priority and preemption behavior.

How to eliminate wrong answers

Option A is wrong because Quality of Service (QoS) classes (Guaranteed, Burstable, BestEffort) are determined by resource requests and limits, not by PriorityClass. Option B is wrong because node eligibility is controlled by node selectors, node affinity, taints/tolerations, and node labels, not by PriorityClass. Option D is wrong because the order of container startup inside a pod is controlled by container lifecycle hooks and init containers, not by PriorityClass.

Full explanation →

179

MCQhard

You are troubleshooting a pod that is in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.' What is the most likely cause?

A.The pod requires more CPU than any node can provide

B.The pod is using a hostPort that conflicts with another pod

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

D.The pod is trying to schedule on the master node which has a taint that is not tolerated

AnswerD

Control plane nodes are typically configured with a default taint, such as node-role.kubernetes.io/control-plane:NoSchedule, to prevent user workloads from consuming critical system resources. For a pod to successfully schedule onto such a node, its specification must explicitly define a matching toleration, otherwise, it remains in a Pending state with a taint-related scheduling event.

Why this answer

The pod is in 'Pending' state because none of the three nodes are schedulable for it. The 'kubectl describe pod' event explicitly states that all three nodes have the taint 'node-role.kubernetes.io/master: ' and the pod does not have a corresponding toleration. Master nodes are typically tainted to prevent general workloads from scheduling on them, so a pod without a toleration for that taint cannot be placed on any master node, leaving zero available nodes.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node selectors or resource constraints, but the event message directly identifies the taint as the cause, making D the only correct answer.

How to eliminate wrong answers

Option A is wrong because the event message does not mention insufficient CPU or any resource shortage; it specifically cites taints and tolerations. Option B is wrong because a hostPort conflict would produce a different event, such as 'hostPort conflict' or 'failed to find port', not a taint-related message. Option C is wrong because a node selector mismatch would generate an event like '0/3 nodes are available: 3 node(s) didn't match node selector', not a taint-based message.

Full explanation →

180

MCQmedium

You have a HorizontalPodAutoscaler targeting a Deployment with minReplicas=2 and maxReplicas=10. currentReplicas is 2. The HPA uses average CPU utilization across pods, targetting 80% of the requested CPU. Pod CPU request is 500m. The current average CPU utilization is 90%. What will the HPA do?

A.Do nothing; wait for stabilization

B.Scale up to 3 replicas

C.Scale up to 4 replicas

D.Scale down to 1 replica because utilization is too high

AnswerB

The HPA uses the formula desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]. Plugging in the values yields ceil[2 * (90 / 80)] = ceil[2.25], which rounds up to 3 replicas. This scaling action directly addresses the resource deficit by distributing the load across an additional pod to bring average utilization back down toward the 80% target.

Why this answer

The HPA calculates the desired number of replicas as ceil(currentReplicas * (currentUtilization / targetUtilization)). Here, currentUtilization is 90% and targetUtilization is 80%, so desiredReplicas = ceil(2 * (90/80)) = ceil(2.25) = 3. Since 3 is within the min/max range (2–10) and differs from currentReplicas (2), the HPA will scale up to 3 replicas immediately (no stabilization window for scale-up by default).

Exam trap

The trap here is that candidates forget the HPA uses ceiling (ceil) in its calculation and incorrectly round up to 4, or assume a stabilization delay applies to scale-up, leading them to choose 'do nothing'.

How to eliminate wrong answers

Option A is wrong because the HPA does not wait for stabilization on scale-up; stabilization windows apply only to scale-down by default (controlled by --horizontal-pod-autoscaler-downscale-stabilization). Option C is wrong because the calculation yields 3 replicas, not 4; the formula uses ceil, not rounding up to the next integer after a threshold. Option D is wrong because scaling down when utilization is above the target would worsen the overload; the HPA scales up to reduce per-pod load, and minReplicas=2 prevents scaling below 2.

Full explanation →

181

MCQmedium

You are upgrading a cluster from v1.28 to v1.29. You have already drained and upgraded all worker nodes. The control plane nodes have not been upgraded yet. 'kubectl get nodes' shows the control plane nodes are still v1.28. What is the correct next step?

A.Drain the worker nodes and downgrade them to v1.28

B.Uncordon the worker nodes

C.Upgrade the control plane nodes to v1.29

D.Restart the kubelet on all nodes

AnswerC

Kubernetes upgrade best practices mandate that the control plane components, particularly the kube-apiserver, must be at a version equal to or higher than the kubelet running on worker nodes. Since the worker nodes have already been upgraded to v1.29, the immediate and correct next step is to upgrade the control plane nodes to v1.29. This action ensures API compatibility, allowing the kube-apiserver to properly communicate with and manage the newer kubelet versions, thereby preventing critical API mismatches and maintaining cluster health.

Why this answer

The correct next step is to upgrade the control plane nodes to v1.29. In a Kubernetes cluster upgrade, the control plane must be upgraded before or in conjunction with the worker nodes, but since the worker nodes have already been upgraded and drained, the control plane nodes are still running v1.28. Upgrading the control plane nodes ensures that the API server, scheduler, and controller manager are at the target version, which is required for cluster stability and to support the upgraded kubelets on the worker nodes.

Exam trap

The trap here is that candidates may think uncordoning worker nodes is safe after draining, but the CKA exam tests the understanding that the control plane must be upgraded before worker nodes are made schedulable again to avoid version skew issues.

How to eliminate wrong answers

Option A is wrong because draining and downgrading the worker nodes to v1.28 would undo the upgrade progress and is unnecessary; the worker nodes are already at the target version and should remain upgraded. Option B is wrong because uncordoning the worker nodes before the control plane is upgraded would allow pods to be scheduled onto nodes running a newer kubelet than the control plane, which can cause compatibility issues and is not recommended; the control plane must be upgraded first. Option D is wrong because restarting the kubelet on all nodes does not change the version of the control plane components; the kubelet version is already correct on worker nodes, and the control plane needs a deliberate upgrade process, not a restart.

Full explanation →

182

MCQmedium

An administrator needs to expand a PersistentVolumeClaim (PVC) that is currently bound to a PersistentVolume (PV). The PV is provisioned by a storage class that supports volume expansion. What must the administrator do to increase the PVC's storage size?

A.Delete the pod that uses the PVC and recreate it with a larger claim.

B.Edit the PV's capacity and then the PVC's capacity.

C.Delete the PVC and recreate it with a larger size.

D.Update the PVC's spec.resources.requests.storage to a larger value.

AnswerD

Increasing the value of spec.resources.requests.storage in the PVC manifest is the standard, declarative way to trigger volume expansion in Kubernetes. For this operation to succeed, the underlying StorageClass must have the allowVolumeExpansion field set to true. Once updated, the control plane coordinates with the CSI driver to resize the physical volume and subsequently expand the file system on the node.

Why this answer

Kubernetes supports expanding PersistentVolumeClaims (PVCs) if the underlying StorageClass has `allowVolumeExpansion: true`. The administrator only needs to edit the PVC's `spec.resources.requests.storage` field to a larger value; the system automatically triggers the expansion of the bound PersistentVolume (PV) and the actual storage backend, provided the volume driver supports it. No pod deletion or PVC recreation is required.

Exam trap

The trap here is that candidates mistakenly think they must delete the PVC or PV to change storage size, but Kubernetes allows in-place expansion via PVC spec update when the StorageClass supports it.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod does not change the PVC's size; the PVC must be updated directly, and the pod can continue using the expanded volume without recreation. Option B is wrong because editing the PV's capacity is not allowed—PVs are immutable after creation, and the PVC expansion must be initiated by updating the PVC, not the PV. Option C is wrong because deleting the PVC would cause data loss and require re-provisioning a new PV; Kubernetes supports online expansion without destroying the existing claim.

Full explanation →

183

Multi-Selectmedium

Which two of the following are valid methods for exposing a Service externally in Kubernetes? (Select TWO.)

Select 2 answers

A.Headless

B.ExternalName

C.LoadBalancer

D.NodePort

E.ClusterIP

AnswersC, D

A LoadBalancer Service is the standard way to expose a Service to the internet on a cloud provider; it provisions an external load balancer (e.g., AWS ELB, GCP LB) that forwards traffic to the Service's node ports or internal endpoints. This gives a stable external IP and L4 load balancing, making it one of the two valid methods for external exposure (along with NodePort).

Why this answer

Option C (LoadBalancer) is correct because a Service of type LoadBalancer provisions an external load balancer (via the cloud provider's controller, e.g., an AWS ELB or GCP LB) that exposes the Service on a publicly reachable IP, making it externally accessible. Option D (NodePort) is correct because it allocates a static port on every node's IP (default range 30000-32767) and forwards traffic to the Service, so external clients can reach the Service via <NodeIP>:<NodePort>. Option A (Headless) is not a valid external exposure method; a headless Service (clusterIP: None) simply returns pod IPs directly via DNS for direct pod addressing, not external access.

Option B (ExternalName) maps a Service to an external DNS name via a CNAME record and is used for accessing external resources from inside the cluster, not for exposing an internal Service externally. Option E (ClusterIP) is the default type and only provides an internal virtual IP reachable within the cluster, so it does not expose the Service externally.

Exam trap

A common misconception is that Headless or ExternalName can expose a Service externally, but they are designed for internal DNS resolution and DNS aliasing, respectively, not for external traffic routing.

Full explanation →

184

MCQhard

A pod runs but you cannot connect to its container port from another pod in the same namespace. 'kubectl exec' into the pod and 'curl localhost:8080' works. What is the MOST likely cause?

A.There is a NetworkPolicy blocking ingress

B.The container's port is not exposed in the pod spec

C.The Service selector does not match the pod labels

D.The pod is bound to localhost only, not 0.0.0.0

AnswerD

Binding to localhost (127.0.0.1) restricts connections to only the same network namespace, which is isolated to the container itself. Kubernetes networking relies on the pod's IP address and virtual Ethernet interfaces, so a loopback bind cannot receive traffic from outside the pod. Listening on 0.0.0.0 makes the port available on all interfaces, including the pod's external-facing one.

Why this answer

When `curl localhost:8080` works inside the pod but connections from other pods fail, the most likely cause is that the application is listening only on the loopback interface (127.0.0.1) instead of 0.0.0.0 (all interfaces). This means the container process binds to localhost, which is only reachable from within the same network namespace (the pod itself), not from external sources like other pods. Kubernetes networking relies on the container listening on 0.0.0.0 so that traffic arriving via the pod's eth0 interface (which has its own IP) can be accepted.

Exam trap

The trap here is that candidates often assume a Service issue (Option C) is the cause, but the question specifies direct pod-to-pod connectivity (not via a Service), so the real problem is the application binding to localhost, which is a classic application-layer misconfiguration rather than a Kubernetes networking misconfiguration.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy blocking ingress would prevent connections from other pods even if the application is correctly listening on 0.0.0.0, but the fact that `curl localhost:8080` works inside the pod does not rule out a NetworkPolicy; however, the symptom of localhost working while external connections fail points directly to a binding issue, not a policy. Option B is wrong because the container's port not being exposed in the pod spec (i.e., missing `containerPort`) does not affect whether the application listens on the correct interface; it only affects service discovery and documentation, not actual network connectivity. Option C is wrong because the Service selector not matching pod labels would prevent traffic from reaching the pod via the Service, but the question states the connection attempt is 'from another pod in the same namespace' — this could be direct pod-to-pod via IP, which bypasses the Service entirely, so a mismatched selector would not explain the failure.

Full explanation →

185

MCQeasy

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

A.ExternalName

B.ClusterIP

C.LoadBalancer

D.NodePort

AnswerD

A NodePort Service allocates a static port from the default range 30000–32767 on every node’s IP address, forwarding inbound traffic on that port to the Service’s ClusterIP and then to the selected Pods. This satisfies the stem’s constraint of exposing the Service on a static port per node IP, unlike ClusterIP (internal only) or LoadBalancer (cloud-provisioned external IP).

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. Traffic sent to any node's IP on that port is forwarded to the Service's ClusterIP and then to the backing pods. This is defined in the Service's `spec.ports[].nodePort` field.

Exam trap

The trap here is that candidates confuse LoadBalancer with NodePort, forgetting that LoadBalancer relies on an external cloud controller to provision an actual LB, while NodePort directly opens a static 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) and does not expose any port or IP on nodes. Option B is wrong because ClusterIP exposes the Service only on a cluster-internal virtual IP, which is not reachable from outside the cluster without additional components. Option C is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and does not directly expose a static port on each node's IP; it typically builds on NodePort but adds a cloud LB.

Full explanation →

186

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 →

187

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 →

188

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 →

189

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 →

190

Multi-Selecthard

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

Select 3 answers

A.Run 'systemctl status kubelet' on the node

B.Restart the kube-apiserver on the control plane

C.Verify that the container runtime (e.g., containerd) is running

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

E.Check the kubelet logs with 'journalctl -u kubelet'

AnswersA, C, E

Running 'systemctl status kubelet' on the node checks whether the kubelet systemd service is active or has failed, showing the current unit state, exit code, and recent process info. This is a logical first step because a Node stuck NotReady often means the kubelet process itself is not running or repeatedly crashing. It directly inspects the node agent, unlike control-plane diagnostics, and can quickly reveal if the service is masked, stopped, or in a failed state.

Why this answer

Option A is correct because a Node in NotReady state is most often caused by the kubelet service being stopped or failed, and 'systemctl status kubelet' on the node quickly reveals whether the kubelet is active, inactive, or in a failed state. Option C is correct because the kubelet requires a working CRI container runtime such as containerd (or CRI-O) to report node health; if containerd is down, the kubelet cannot manage pods and the node transitions to NotReady, so verifying the runtime is running is a valid troubleshooting step. Option E is correct because 'journalctl -u kubelet' surfaces the kubelet's own error messages (e.g., failed to get node status, CRI connection errors, certificate or cgroup driver problems) that explain why the node is NotReady.

Option B is not a valid step because restarting the kube-apiserver on the control plane does not fix a node-local kubelet or runtime failure and would disrupt the whole cluster. Option D is not valid because 'kubectl delete node <node-name>' removes the Node object from the API server rather than re-registering it; the kubelet re-registers only when it restarts and reconnects, so deleting the node is not a troubleshooting step for NotReady.

Exam trap

The trap here is that candidates may confuse control plane components with node-level agents, incorrectly assuming that restarting the kube-apiserver or deleting the node object will fix a node-level NotReady state, when the real issue lies with the kubelet or container runtime on the node itself.

Full explanation →

191

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 →

192

MCQhard

A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?

A.All traffic to and from pods in the namespace is denied.

B.Only traffic from pods in the same namespace is allowed.

C.All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.

D.All traffic is allowed because podSelector: {} matches nothing.

AnswerC

This is the correct behavior because setting podSelector: {} applies the policy to all pods in the namespace, and omitting ingress rules creates an isolate-and-deny-all state for incoming traffic. Because the policy does not define Egress in its policyTypes, outbound connections from these pods are left unaffected and allowed by default.

Why this answer

A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. With no ingress rules defined, the policy defaults to denying all ingress traffic to those pods, while egress traffic remains unrestricted unless explicitly denied by another policy. This is because Kubernetes NetworkPolicy is additive for ingress: if any policy selects a pod, the default allow for ingress is overridden, and only explicitly allowed ingress traffic is permitted.

Exam trap

The trap here is that candidates often assume `podSelector: {}` matches nothing or that a policy with no rules allows all traffic, but in Kubernetes, an empty podSelector matches all pods, and a NetworkPolicy with no ingress rules defaults to denying all ingress traffic.

How to eliminate wrong answers

Option A is wrong because the policy only denies ingress traffic; egress traffic is not affected by the absence of ingress rules, so not all traffic is denied. Option B is wrong because the policy does not allow any ingress traffic, including traffic from the same namespace; it denies all ingress, so only egress traffic is allowed. Option D is wrong because `podSelector: {}` matches all pods in the namespace, not nothing; it is a valid selector that applies the policy to every pod.

Full explanation →

193

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

When pods can reach each other's IPs and services but a specific port connection fails, the most likely cause in a multi-namespace Kubernetes cluster is a NetworkPolicy restricting ingress to pod-b. NetworkPolicies are namespace-scoped and can deny cross-namespace traffic on specific ports, which perfectly matches the symptom of ICMP/service reachability succeeding while TCP/5432 fails.

Exam trap

CKA often tests the assumption that if basic connectivity (ping, service IP) works, the network is fine — candidates overlook that NetworkPolicies selectively block specific ports and namespaces while leaving other traffic untouched.

How to eliminate wrong answers

Option A is wrong because if kube-proxy were down on pod-b's node, service IP connectivity would fail broadly, not just the specific pod-to-pod port 5432 connection — and the scenario states service IPs are reachable. Option C is wrong because the container runtime (Docker vs. containerd) is irrelevant to pod-to-pod TCP connectivity; both runtimes use the same CNI networking. Option D is wrong because DNS resolution for pod-b's service is not the issue — the analyst is connecting directly to pod-b's IP on port 5432, and DNS failures would manifest as name-resolution errors, not port-specific connection refusals.

Full explanation →

194

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 →

195

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 →

196

Multi-Selecthard

You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)

Select 3 answers

A.Run 'kubectl describe pod pod-name' to check events

B.Run 'kubectl logs pod-name'

C.Run 'kubectl get pod pod-name -o jsonpath={.status.containerStatuses[0].state.waiting.reason}'

D.Run 'kubectl top pod pod-name'

E.Run 'kubectl delete pod pod-name'

AnswersA, B, C

kubectl describe pod pod-name aggregates the pod's current state, recent events, container statuses (waiting/running/terminated), restart counts, and last termination reason into a human-readable summary. This surfaces CrashLoopBackOff events with timestamps, showing whether the container exited due to an error, OOMKill, or probe failure. It is the first step for diagnosing why Kubernetes is restarting the container.

Why this answer

Option A is correct because 'kubectl describe pod pod-name' surfaces the pod's Events section, which shows why the kubelet restarted the container (e.g., OOMKilled, failed liveness probe, image pull issues) and the backoff timing. Option B is correct because 'kubectl logs pod-name' retrieves the container's stdout/stderr, which typically contains the application error that caused the process to exit and enter CrashLoopBackOff; adding --previous shows logs from the prior crashed instance. Option C is correct because the jsonpath query reads .status.containerStatuses[0].state.waiting.reason, which directly returns the waiting reason such as CrashLoopBackOff along with the last termination state, confirming the container's current status.

Option D is not appropriate because 'kubectl top pod' only reports live CPU/memory usage from the metrics server and does not explain why the container is crash-looping. Option E is not a valid diagnostic step because deleting the pod merely recreates it (or removes it if managed by a controller) without revealing the root cause, so it does not help troubleshoot the failure.

Exam trap

The CKA exam often tests the misconception that 'kubectl top' or deleting the pod is a valid troubleshooting step for CrashLoopBackOff, when in fact these actions either provide irrelevant metrics or mask the issue without diagnosis.

Full explanation →

197

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 →

198

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 →

199

MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate'. What does this indicate?

A.The pod has been successfully scheduled to the node

B.The node has insufficient resources and is tainted

C.The node is not reachable by the control plane

D.The node does not exist

AnswerC

The node.kubernetes.io/unreachable taint is set by the node controller when it stops receiving heartbeats from the kubelet, meaning the control plane can no longer reach or manage the node. Pods without a matching toleration are blocked from scheduling onto that node, leaving them Pending. This matches the kubectl describe output showing an unreachable taint, confirming the root cause is loss of control-plane connectivity to the node.

Why this answer

The error message indicates that the node has a taint of `node.kubernetes.io/unreachable`, which is automatically added by the node controller when the control plane cannot communicate with the node (e.g., due to network failure or kubelet being down). The pod remains in 'Pending' because no node is available that tolerates this taint, meaning the node is unreachable from the control plane. This matches option C.

Exam trap

The trap here is that candidates often confuse taints related to resource pressure (like memory or disk) with the unreachable taint, or assume 'Pending' means the pod is scheduled but waiting for resources, when in fact the specific taint name directly indicates a node reachability issue.

How to eliminate wrong answers

Option A is wrong because a pod in 'Pending' state has not been scheduled to any node; successful scheduling would show a node name in the pod status. Option B is wrong because the taint `node.kubernetes.io/unreachable` is not related to resource insufficiency; resource issues would show taints like `node.kubernetes.io/disk-pressure` or `node.kubernetes.io/memory-pressure`, and the error would mention insufficient resources, not unreachability. Option D is wrong because the error explicitly states '1 node(s) had taint', confirming the node exists but is unreachable; a non-existent node would not appear in the node list or would show a different error like 'node not found'.

Full explanation →

200

MCQeasy

An administrator creates a PersistentVolume with the following YAML: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /mnt/data ``` Which of the following is true about this PersistentVolume?

A.It can be mounted as read-write by only one node at a time.

B.It can be mounted as read-write by multiple nodes simultaneously.

C.The PV will be automatically deleted when its PVC is released.

D.The PV supports dynamic provisioning.

AnswerA

The ReadWriteOnce (RWO) access mode restricts volume mounting to a single Kubernetes node for read-write operations. While multiple pods scheduled on that same node can access the volume concurrently, pods on different nodes cannot attach to it simultaneously. This ensures data integrity by preventing multi-node write conflicts on block storage.

Why this answer

The PersistentVolume specifies `accessModes: ReadWriteOnce`, which means the volume can be mounted as read-write by only a single node at a time. This is a Kubernetes access mode that restricts the volume to a single consumer (node) for read-write operations, preventing concurrent access from multiple nodes.

Exam trap

The trap here is that candidates often confuse `ReadWriteOnce` with `ReadWriteMany` or assume that `Retain` means automatic deletion, when in fact `Retain` preserves the PV and its data after PVC release.

How to eliminate wrong answers

Option B is wrong because `ReadWriteOnce` explicitly limits the volume to a single node; multiple nodes simultaneously would require `ReadWriteMany` or `ReadOnlyMany`. Option C is wrong because the `persistentVolumeReclaimPolicy: Retain` means the PV is not automatically deleted when its PVC is released; instead, the PV remains with its data intact for manual reclamation. Option D is wrong because this PV uses a `hostPath` volume, which is a static provisioning method; dynamic provisioning requires a StorageClass with a provisioner, which is not defined here.

Full explanation →

201

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 allocates a static port from the default range 30000–32767 and opens it on every node's IP, forwarding traffic to the service. This satisfies the stem's requirement for exposure on a fixed port per node, unlike ClusterIP (internal only) or LoadBalancer (cloud-provisioned external IP).

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 →

202

MCQhard

A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?

A.The pod needs a toleration for node.kubernetes.io/not-ready

B.All nodes in the cluster are NotReady

C.The pod has a resource request that cannot be met

D.The scheduler is not running

AnswerB

This is the correct answer because the scheduler cannot place the pod on any node that has a taint not tolerated by the pod. When every node has the node.kubernetes.io/not-ready taint (a direct result of the node controller marking them NotReady), there is no feasible node in the cluster. The pod stays in Pending until at least one node returns to Ready status, which clears the taint and allows scheduling.

Why this answer

The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.

Exam trap

The trap here is that candidates often confuse 'tolerating a taint' with 'fixing the node condition', and assume that adding a toleration is the correct solution, when the error message explicitly states that all nodes have the taint, meaning the nodes themselves are NotReady.

Why the other options are wrong

Tolerating this taint would schedule pods on unhealthy nodes.

Would show insufficient resources, not taint.

Would show 0 nodes available due to other reasons.

Full explanation →

203

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 →

204

MCQmedium

A worker node in your cluster has been marked NotReady for several minutes. You SSH into the node and find that the kubelet process is not running. You start the kubelet service, but it immediately exits. Running 'journalctl -u kubelet -n 50' shows repeated errors about being unable to load the kubeconfig file at /etc/kubernetes/kubelet.conf. Which of the following is the MOST likely cause?

A.The container runtime socket is not available, so the kubelet cannot manage pods.

B.The kubelet.conf file has incorrect file permissions or is missing, preventing the kubelet from authenticating to the API server.

C.The kubelet's systemd unit file has an incorrect path to the kubelet binary.

D.The node's network plugin is misconfigured, preventing the kubelet from reaching the API server.

AnswerB

The kubelet requires a valid kubeconfig to authenticate to the API server. If the file is missing or has permissions that prevent the kubelet user from reading it, the kubelet will fail to start with an error referencing the kubeconfig path. This aligns with the journalctl output. Restoring or regenerating the file fixes the issue.

Why this answer

The kubelet relies on a kubeconfig file to authenticate to the API server. When that file is missing or unreadable, the kubelet cannot establish its connection and exits with a clear error in its logs. The correct resolution is to restore the file from backup or regenerate it using kubeadm, ensuring proper permissions.

Other issues like container runtime or network plugin would produce different error messages.

Exam trap

The trap here is assuming that any kubelet failure is due to the container runtime or network, when the specific error message clearly points to a kubeconfig problem.

Full explanation →

205

Multi-Selecteasy

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

Select 2 answers

A.Mounting the ConfigMap as a volume

B.The ConfigMap is automatically mounted at /etc/config in the container

C.Using the ConfigMap as a container image

D.The ConfigMap is automatically available as environment variables in the pod

E.Injecting specific keys as environment variables using configMapKeyRef

AnswersA, E

Mounting a ConfigMap as a volume is a fully supported way to expose its data. When you define a volume of type configMap and mount it into a pod, each key in the ConfigMap becomes a file in the specified mount path. Use the items field to project only specific keys if needed, and note that updates to the ConfigMap will eventually be reflected in the mounted files, though there is no immediate guarantee.

Why this answer

Option A is correct because a ConfigMap can be exposed to a pod by mounting it as a volume, which projects each key as a file inside the container's filesystem at a chosen mount path. Option E is correct because individual ConfigMap keys can be injected as environment variables using valueFrom.configMapKeyRef (or envFrom.configMapRef for all keys), letting the container read specific values as env vars. Option B is wrong because ConfigMaps are never automatically mounted at /etc/config; a volume mount must be explicitly declared in the pod spec with a mountPath.

Option C is wrong because a ConfigMap holds configuration data, not a container image, so it cannot be used as an image. Option D is wrong because ConfigMap data is not automatically exposed as environment variables; it must be explicitly referenced via envFrom or configMapKeyRef.

Exam trap

The trap here is that candidates often assume ConfigMaps are automatically available as environment variables or mounted at a default path, but Kubernetes requires explicit configuration for both methods.

Full explanation →

206

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 →

207

MCQmedium

A cluster has multiple kubeconfig files. You want to set the current context to 'admin@production' for all future kubectl commands. Which command should you run?

A.kubectl config set-context admin@production

B.kubectl config use-context admin@production

C.kubectl config set-cluster admin@production

D.kubectl config get-contexts admin@production

AnswerB

This command directly updates the `current-context` field in your active kubeconfig file to `admin@production`. Once executed, all subsequent `kubectl` commands will target the cluster and use the user credentials defined within this specific context, making it the correct choice for switching active environments.

Why this answer

The `kubectl config use-context` command is used to set the current context in a kubeconfig file, which determines the cluster, user, and namespace that kubectl will use by default for all subsequent commands. Option B correctly specifies `admin@production` as the context to switch to, making it the active context for future kubectl operations.

Exam trap

The trap here is that candidates confuse `set-context` (which only defines or updates a context entry) with `use-context` (which actually switches the active context), leading them to select option A.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-context` creates or modifies a context entry in the kubeconfig file but does not set it as the current context; it only defines or updates the context's properties (cluster, user, namespace). Option C is wrong because `kubectl config set-cluster` modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, not a context or the current context. Option D is wrong because `kubectl config get-contexts` lists all available contexts or shows details for a specific context, but it does not change the active context.

Full explanation →

208

Multi-Selectmedium

Which THREE of the following are common causes for a Pod to remain in Pending state? (Select THREE.)

Select 3 answers

A.Insufficient CPU or memory resources in the cluster

B.Taints on nodes that are not tolerated by the Pod

C.PersistentVolumeClaim is not bound to a PersistentVolume

D.Container exits with OOMKilled

E.Image pull error due to incorrect image name

AnswersA, B, C

When no node has enough allocatable CPU or memory to satisfy the Pod's resource requests, the kube-scheduler's filter phase rejects every candidate node, leaving the Pod unscheduled in Pending. This is the classic capacity-driven cause.

Why this answer

Option A is correct because when no node has enough allocatable CPU or memory to satisfy the Pod's resource requests, the scheduler cannot place the Pod and it stays in Pending. Option B is correct because taints on nodes that the Pod does not tolerate cause the scheduler to reject those nodes, leaving the Pod unscheduled and Pending. Option C is correct because a PersistentVolumeClaim that is not yet bound to a PersistentVolume blocks scheduling of Pods that reference it, keeping them in Pending.

Option D does not belong because OOMKilled is a container termination reason that occurs after the Pod has been scheduled and started, producing a CrashLoopBackOff or Error state rather than Pending. Option E does not belong because an image pull error happens during kubelet container creation after scheduling, resulting in ImagePullBackOff or ErrImagePull, not Pending.

Exam trap

The CKA exam frequently tests your ability to troubleshoot Pod states. Remember that 'Pending' is a scheduling-phase state. If a Pod is Pending, the issue is almost always related to scheduling (resources, taints/tolerations, node selectors, affinity) or volume binding.

Once a Pod is assigned to a node, failures will manifest as 'ImagePullBackOff', 'CrashLoopBackOff', or 'Failed', not 'Pending'.

Full explanation →

209

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 →

210

MCQhard

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. Kubelet is active but 'journalctl -u kubelet -n 50' shows 'network plugin is not ready: cni config uninitialized'. What is the most likely cause?

A.The container runtime is not installed

B.The CNI configuration file is missing or incorrect

C.Kubelet is not running

D.The node's IP address has changed

AnswerB

The kubelet depends on a CNI configuration file in /etc/cni/net.d/ to set up pod networking. When this file is absent or malformed, the kubelet cannot initialize the network plugin and marks the node as NotReady. The kubelet logs will show a 'CNI configuration uninitialized' error, which directly matches the symptom described in the question.

Why this answer

The CNI plugin configuration is missing, causing the network plugin to be unready.

Full explanation →

211

MCQeasy

Which command shows CPU and memory usage of nodes in the cluster?

A.kubectl describe nodes

B.kubectl get nodes

C.kubectl logs nodes

D.kubectl top nodes

AnswerD

kubectl top nodes is the correct command because it queries the Metrics API, typically served by metrics-server, and aggregates resource usage from each node's kubelet and cAdvisor. It outputs a table showing CPU usage (e.g., 348m) and memory usage (e.g., 1200Mi) alongside the node's total capacity, making it the standard kubectl command for viewing current CPU and memory consumption across nodes.

Why this answer

`kubectl top nodes` is the command specifically designed to display real-time CPU and memory usage metrics for all nodes in a Kubernetes cluster. It relies on the metrics server, which collects resource usage data from kubelets via the Summary API, and presents it in a concise table format.

Exam trap

The trap here is that candidates often confuse `kubectl describe nodes` (which shows allocatable resources but not real-time usage) with `kubectl top nodes` (which shows actual current usage), leading them to pick option A incorrectly.

How to eliminate wrong answers

Option A is wrong because `kubectl describe nodes` shows detailed node information including capacity, allocatable resources, conditions, and taints, but it does not show real-time CPU and memory usage metrics. Option B is wrong because `kubectl get nodes` only lists nodes with their status, roles, age, and version, without any resource usage data. Option C is wrong because `kubectl logs nodes` is not a valid kubectl command; `kubectl logs` is used to fetch logs from pods, not nodes.

Full explanation →

212

Multi-Selecthard

Which THREE of the following are valid taint effects that can be applied to a node? (Select 3)

Select 3 answers

A.NeverSchedule

B.PreferSchedule

C.NoSchedule

D.PreferNoSchedule

E.NoExecute

AnswersC, D, E

NoSchedule is a valid, hard taint effect that prevents the scheduler from placing new pods onto the tainted node unless they have a matching toleration. It has no effect on pods that are already running on the node; those pods continue to run unless they are evicted by other means. This effect is commonly used to restrict a node for dedicated workloads or to perform maintenance without disrupting existing pods.

Why this answer

In Kubernetes, taints are applied to nodes with a taint effect that determines how the scheduler and kubelet react to pods lacking a matching toleration. Option C, NoSchedule, is correct because it instructs the scheduler to avoid placing new pods on the node unless they tolerate the taint, while existing pods remain running. Option D, PreferNoSchedule, is correct because it is a soft preference: the scheduler tries to avoid the node but may still place pods there if no better option exists.

Option E, NoExecute, is correct because it not only prevents new pods from scheduling but also evicts already-running pods that do not tolerate the taint. Options A (NeverSchedule) and B (PreferSchedule) are not valid Kubernetes taint effects; the only supported effects are NoSchedule, PreferNoSchedule, and NoExecute.

Exam trap

CNCF often tests the exact spelling of taint effects, and candidates confuse `PreferNoSchedule` with `PreferSchedule` or invent effects like `NeverSchedule` that do not exist in the Kubernetes API.

Full explanation →

213

MCQeasy

What is the purpose of the kube-proxy component in a Kubernetes cluster?

A.It provides network proxy and load balancing for services

B.It schedules pods to nodes

C.It manages the lifecycle of pods

D.It stores cluster configuration data

AnswerA

kube-proxy watches the Kubernetes API for Services and EndpointSlices, then programs node-level iptables or IPVS rules so that traffic to a Service's ClusterIP is DNATed to healthy backend Pod IPs. This distributed, kernel-mode forwarding is what makes Service load balancing work without a centralized proxy.

Why this answer

Kube-proxy is the component responsible for implementing the Kubernetes Service concept by maintaining network rules on each node. It performs connection forwarding and load balancing for Service endpoints using either iptables, IPVS, or userspace mode, ensuring that traffic destined for a Service's ClusterIP is correctly routed to healthy Pods.

Exam trap

The trap here is that candidates confuse kube-proxy with the kubelet or kube-scheduler because all three are node-level components, but kube-proxy's sole purpose is network proxying and Service load balancing, not pod management or scheduling.

How to eliminate wrong answers

Option B is wrong because scheduling pods to nodes is the responsibility of the kube-scheduler, not kube-proxy. Option C is wrong because managing the lifecycle of pods (creation, monitoring, restart) is handled by the kubelet, not kube-proxy. Option D is wrong because storing cluster configuration data is the function of etcd, a distributed key-value store; kube-proxy does not persist any state.

Full explanation →

214

Multi-Selectmedium

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

Select 2 answers

A.The node has insufficient memory

B.The image is in a private registry and no imagePullSecrets are defined

C.The pod has a resource limit that is too low

D.The image tag is misspelled

E.The kubelet is not running

AnswersB, D

When an image resides in a private registry, the kubelet must authenticate itself using image pull secrets specified in the pod's spec via `imagePullSecrets`. If those secrets are missing or not attached to the pod, the registry responds with an authorization error (e.g., "unauthorized: authentication required"), and the kubelet reports ErrImagePull before entering ImagePullBackOff. This is a common production misconfiguration because merely having the secret in the namespace does not grant the pod access.

Why this answer

Common causes: invalid image tag (typo) and authentication failure when the image is in a private registry.

Full explanation →

215

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 →

216

MCQeasy

You have a pod that is in 'CrashLoopBackOff' state. Which command should you use to view the logs from the previous instance of the container?

A.kubectl logs pod-name --previous

B.kubectl get events

C.kubectl describe pod pod-name

D.kubectl logs pod-name

AnswerA

`kubectl logs pod-name --previous` correctly retrieves the logs from the last terminated container instance in the pod. Because CrashLoopBackOff means the container keeps crashing and restarting, the logs from the most recent crashed instance contain the panic, exception, or startup failure that caused the crash. The `--previous` flag explicitly tells the kubelet to read the terminated container's log file, which is exactly what you need to inspect when the current container has already restarted.

Why this answer

The correct option is A, `kubectl logs pod-name --previous`, because when a container is in CrashLoopBackOff the current container instance may not have started or may have already been replaced, so the `--previous` (or `-p`) flag retrieves the logs from the last terminated instance of that container in the pod. This is the standard way to inspect why the container crashed on its prior run. Option D, `kubectl logs pod-name`, only shows logs from the currently running container instance, which may be empty or unavailable during a crash loop.

Option B, `kubectl get events`, shows cluster-level event messages but not the container's stdout/stderr logs, and option C, `kubectl describe pod pod-name`, shows pod status, conditions, and recent events but not the previous container's application logs.

Full explanation →

217

MCQmedium

Which of the following is a required field when defining a PersistentVolume?

A.storageClassName

B.nodeAffinity

C.capacity

D.persistentVolumeReclaimPolicy

AnswerC

The capacity field is a mandatory attribute in a PersistentVolume definition, specifically requiring the storage key to declare the volume's size (e.g., 10Gi). Kubernetes relies on this value during the binding process to match the PV against the storage requests of a PersistentVolumeClaim. Without specifying capacity, the API server will reject the PV manifest during validation.

Why this answer

In Kubernetes, a PersistentVolume (PV) must define its storage capacity using the `capacity` field, which specifies the amount of storage the PV provides (e.g., `storage: 10Gi`). This is a required field because the PV represents a piece of storage in the cluster, and the scheduler and PersistentVolumeClaim (PVC) binding logic need to know the available size to match claims. Without `capacity`, the PV definition is invalid and will be rejected by the API server.

Exam trap

The trap here is that candidates often confuse optional fields like `storageClassName` or `persistentVolumeReclaimPolicy` as required, because they are commonly used in examples, but the CKA exam tests the strict API schema requirement that only `capacity` is mandatory for a PersistentVolume definition.

How to eliminate wrong answers

Option A is wrong because `storageClassName` is optional; if omitted, the PV uses the default StorageClass or no class, and it is not a required field for PV creation. Option B is wrong because `nodeAffinity` is only required for PVs backed by local storage (e.g., `hostPath` or `local` volumes) to restrict the PV to specific nodes, but it is not a general requirement for all PV types. Option D is wrong because `persistentVolumeReclaimPolicy` is optional and defaults to `Retain`; it controls what happens to the PV after the PVC is released, but it is not mandatory for defining the PV.

Full explanation →

218

MCQhard

You have a PVC that is bound to a PV with a filesystem volume mode. You want to use the volume as a block device in a pod. What should you do?

A.Use a hostPath volume instead.

B.Set volumeDevices in the pod spec instead of volumeMounts.

C.Create a new PVC with volumeMode: Block and bind it to a new PV.

D.Modify the PV's volumeMode to Block.

AnswerC

To transition to a raw block device, you must define a new PersistentVolumeClaim with volumeMode explicitly set to Block. This PVC must then bind to a newly provisioned PersistentVolume that also supports and specifies volumeMode: Block, ensuring the storage plugin exposes the raw block device directly to the container.

Why this answer

A PVC with `volumeMode: Block` must be created and bound to a PV that also has `volumeMode: Block` to use the volume as a block device in a pod. The existing PVC is bound to a PV with `volumeMode: Filesystem`, which cannot be used as a block device without recreating the underlying storage. You cannot change the volume mode of an existing PV or PVC; you must provision new resources with the correct mode.

Exam trap

The trap here is that candidates assume they can simply change the pod spec (e.g., use `volumeDevices`) or modify the PV to convert a filesystem volume into a block device, but Kubernetes requires the volume mode to be set at PV creation and matched in the PVC, making it immutable after binding.

How to eliminate wrong answers

Option A is wrong because using a `hostPath` volume bypasses the PVC/PV abstraction and does not solve the requirement of using the existing PVC as a block device; it introduces a different storage type with its own limitations. Option B is wrong because `volumeDevices` in the pod spec is used to consume a block volume, but the underlying PVC/PV must already have `volumeMode: Block`; simply changing the pod spec does not convert a filesystem-mode volume into a block device. Option D is wrong because the `volumeMode` field of a PV is immutable after creation; you cannot modify it to `Block` without deleting and recreating the PV and its associated storage.

Full explanation →

219

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 →

220

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 →

221

MCQmedium

Your team is deploying a new application that consists of a web frontend and a backend API. The frontend must be accessible from outside the cluster, and the backend should only be accessible from within the cluster. The cluster has multiple namespaces: 'frontend' and 'backend'. You have been asked to design the deployment. The frontend Deployment should have 5 replicas, and the backend Deployment should have 3 replicas. Additionally, you need to ensure that the frontend pods can communicate with the backend pods using a stable DNS name. You also want to isolate the backend from other namespaces. Which set of resources should you create?

A.Frontend: Deployment, Service (NodePort); Backend: Deployment, Service (ClusterIP); no NetworkPolicy

B.Frontend: Deployment, Service (ClusterIP); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace

C.Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (LoadBalancer); NetworkPolicy to allow only frontend to backend

D.Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace and deny others

AnswerD

This architecture correctly leverages a LoadBalancer Service to route external public traffic to the frontend deployment, while keeping the backend isolated using an internal-only ClusterIP Service. Additionally, the NetworkPolicy enforces strict zero-trust security by explicitly allowing ingress traffic only from the frontend namespace while dropping all other non-compliant cluster traffic.

Why this answer

It uses a LoadBalancer Service for the frontend to provide external access, a ClusterIP Service for the backend to restrict access to within the cluster, and a NetworkPolicy that allows ingress traffic from the frontend namespace to the backend while denying all other ingress, thus isolating the backend. This ensures the frontend pods can reach the backend via a stable DNS name (the ClusterIP Service's DNS name) and meets the requirement of backend isolation from other namespaces.

Exam trap

The trap here is that candidates often forget that a ClusterIP Service cannot be accessed from outside the cluster, and they may incorrectly choose a LoadBalancer or NodePort for the backend, or omit the NetworkPolicy needed to enforce isolation.

How to eliminate wrong answers

Option A is wrong because it uses a NodePort Service for the frontend, which exposes the frontend on a high port on every node but does not provide a stable external endpoint like a LoadBalancer, and it lacks a NetworkPolicy to isolate the backend. Option B is wrong because it uses a ClusterIP Service for the frontend, which does not make the frontend accessible from outside the cluster, violating the requirement. Option C is wrong because it uses a LoadBalancer Service for the backend, which exposes the backend externally, contradicting the requirement that the backend should only be accessible from within the cluster.

Full explanation →

222

MCQmedium

You need to implement a PriorityClass named 'high-priority' with value 1000 and mark it as non-preempting. Which YAML field should you set to true?

A.spec.preemptionPolicy: Never

B.spec.description: "non-preempting"

C.spec.globalDefault: true

D.spec.value: 1000

AnswerA

spec.preemptionPolicy: Never is the correct field because PriorityClass supports a preemptionPolicy that controls whether pods with this class may evict lower-priority pods. The Kubernetes default is PreemptLowerPriority, which allows preemption; setting it to Never explicitly disables that behavior, making the PriorityClass non-preempting. This is the only option that directly affects the scheduler's preemption logic.

Why this answer

Setting `spec.preemptionPolicy: Never` in a PriorityClass definition marks it as non-preempting, meaning pods with this priority will not preempt lower-priority pods even if they have a higher priority value. This field is the only one that controls preemption behavior for a PriorityClass.

Exam trap

CNCF often tests the distinction between `spec.value` (which sets priority) and `spec.preemptionPolicy` (which controls preemption behavior), leading candidates to mistakenly think that a high priority value alone implies preemption or that `spec.globalDefault` affects preemption.

How to eliminate wrong answers

Option B is wrong because `spec.description` is a free-text field for human-readable notes and has no effect on preemption behavior. Option C is wrong because `spec.globalDefault: true` sets this PriorityClass as the default for all pods that do not specify a priorityClassName, but it does not affect preemption. Option D is wrong because `spec.value: 1000` sets the priority value (higher numbers indicate higher priority) but does not control preemption; preemption is governed by the `preemptionPolicy` field.

Full explanation →

223

MCQmedium

A developer created a ServiceAccount named 'app-sa' in the 'dev' namespace. They want a pod to use this ServiceAccount. Which field in the pod spec should be set?

A.spec.serviceAccount

B.spec.authentication.serviceAccount

C.spec.serviceAccountName

D.spec.accountName

AnswerC

spec.serviceAccountName is the canonical field in PodSpec that tells the kubelet and kube-apiserver which ServiceAccount to attach to the pod. When set to 'app sa', the pod will mount the token and credentials of that ServiceAccount, enabling authenticated access to the Kubernetes API. If omitted, the default ServiceAccount in the namespace is used automatically, but explicitly setting it here binds the pod to 'app sa'.

Why this answer

The `spec.serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set, the Pod's containers will use the token of that ServiceAccount for API authentication. If omitted, the Pod defaults to the `default` ServiceAccount in its namespace.

Exam trap

The trap here is that candidates may confuse the deprecated `spec.serviceAccount` field (which still works in older clusters but is removed in recent versions) with the correct `spec.serviceAccountName`, or invent a non-existent field like `spec.accountName` due to similarity with other Kubernetes resource specs.

How to eliminate wrong answers

Option A is wrong because `spec.serviceAccount` is a deprecated field (removed in Kubernetes 1.24) and should not be used; it was replaced by `spec.serviceAccountName`. Option B is wrong because `spec.authentication.serviceAccount` is not a valid Kubernetes Pod spec field—authentication is handled via the ServiceAccount token, not a nested `authentication` object. Option D is wrong because `spec.accountName` is not a recognized field in the Pod spec; the correct field name is `serviceAccountName`.

Full explanation →

224

MCQeasy

A CKA candidate runs 'kubectl get nodes' and sees that a worker node is in the 'NotReady' state. Which command should be used to diagnose the node's kubelet health?

A.systemctl status docker

B.kubectl get events --all-namespaces

C.journalctl -u kubelet

D.kubectl logs -n kube-system kubelet-<node>

AnswerC

The kubelet runs as a systemd service on each node (in kubeadm and most Linux distributions), so `journalctl -u kubelet` reads the exact logs from that service, including startup errors, API server connection failures, certificate errors, and runtime health check failures. This is the authoritative source for why a node is NotReady, because NodeReady status is only updated when the kubelet successfully posts its status to the control plane. Unlike `kubectl get events`, these journal logs capture the actual exception that prevented the kubelet from functioning.

Why this answer

The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the most direct way to diagnose kubelet health is to inspect its systemd unit logs using 'journalctl -u kubelet', which shows startup errors, certificate issues, or resource exhaustion that prevent the kubelet from functioning correctly.

Exam trap

CNCF often tests the misconception that the kubelet runs as a Kubernetes pod (like kube-apiserver) and can be debugged with 'kubectl logs', when in reality it is a systemd service on the node, requiring OS-level commands like 'journalctl' or 'systemctl'.

How to eliminate wrong answers

Option A is wrong because 'systemctl status docker' checks the Docker container runtime, not the kubelet; while a runtime failure can cause node issues, the question specifically asks for diagnosing kubelet health. Option B is wrong because 'kubectl get events --all-namespaces' shows cluster-wide events (e.g., pod scheduling failures) but does not provide the kubelet's own log output or system-level errors. Option D is wrong because 'kubectl logs -n kube-system kubelet-<node>' attempts to access a pod named 'kubelet-<node>', but the kubelet does not run as a pod in the kube-system namespace; it runs as a systemd service on the node, so this command would fail with a 'not found' error.

Full explanation →

225

MCQhard

A node has a taint 'gpu=true:NoSchedule'. A pod has a toleration 'key: gpu, operator: Exists, effect: NoSchedule'. Will the pod be scheduled on the node?

A.Yes, because the toleration matches the taint

B.Yes, only if the pod has a nodeSelector for gpu

C.No, because the toleration does not specify a value

D.No, because the node also has other taints

AnswerA

When a pod's toleration matches the key, value, and effect of a node's taint, the Kubernetes scheduler is permitted to schedule the pod onto that node. Tolerations do not force scheduling, but they successfully bypass the NoSchedule restriction imposed by the matching taint.

Why this answer

A toleration with `operator: Exists` and no `value` field matches any taint that has the specified key (`gpu`) and effect (`NoSchedule`), regardless of the taint's value. The taint `gpu=true:NoSchedule` has the key `gpu` and effect `NoSchedule`, so the toleration matches it perfectly, allowing the pod to be scheduled on the node. Tolerations do not require a value when using the `Exists` operator, as it checks only for the key and effect.

Exam trap

The trap here is that candidates often assume a toleration must specify a `value` to match a taint, forgetting that the `Exists` operator with no `value` field matches any value for the given key, making the toleration valid even without an explicit value match.

How to eliminate wrong answers

Option B is wrong because a `nodeSelector` is not required for tolerations to work; tolerations alone determine whether a pod can tolerate a taint, and scheduling is based on matching taints and tolerations, not node selectors. Option C is wrong because the `Exists` operator explicitly does not require a value; it matches any taint with the specified key and effect, so the absence of a value is intentional and valid. Option D is wrong because the question only specifies one taint on the node, and the pod's toleration matches that taint; other taints are not mentioned, and even if they existed, they would need their own matching tolerations to allow scheduling, but that is not part of the given scenario.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 151–225