Knowledge + Practice

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

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

Take a mock exam Exam hub

Page 2 of 14

76

Multi-Selecthard

A Deployment's pods are failing with 'CrashLoopBackOff'. The container exits with code 1. Which two approaches will help identify the issue? (Choose two.)

Select 2 answers

A.kubectl logs <pod>

B.kubectl describe pod <pod>

C.kubectl get pods -o wide

D.kubectl edit deployment <deploy>

AnswersA, B

Why this answer

A is correct because `kubectl logs <pod>` retrieves the container's stdout/stderr output, which often contains the error message or stack trace that caused exit code 1. This is the first step in debugging a CrashLoopBackOff, as it reveals what the application printed before terminating.

Exam trap

The trap here is that candidates may think `kubectl get pods -o wide` provides troubleshooting details, but it only adds IP and node info, not logs or events, while `kubectl edit` is a remediation step, not a diagnostic one.

Why the other options are wrong

C

Shows status but no logs or details.

D

Edits, not diagnoses.

Full explanation →

77

MCQmedium

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

A.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 3

B.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 2

C.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 3

D.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2

AnswerD

Correctly sets maxUnavailable to 3 and maxSurge to 2.

Why this answer

The rolling update strategy is configured under spec.strategy.rollingUpdate with maxUnavailable and maxSurge fields. Option B correctly sets maxUnavailable to 3 and maxSurge to 2.

Full explanation →

78

Multi-Selecthard

Which THREE are valid ways to inject configuration data into a pod?

Select 3 answers

A.Use a Secret as a ConfigMap data source.

B.Mount a ConfigMap as a volume.

C.Use 'kubectl inject configmap' to inject data at runtime.

D.Set environment variables from a ConfigMap using envFrom or valueFrom.

E.Set environment variables from a Secret using envFrom or valueFrom.

AnswersB, D, E

ConfigMaps can be mounted as volumes to provide files to containers.

Why this answer

Options A, C, and D are correct. ConfigMaps can be mounted as volumes or injected as environment variables. Secrets can also be injected as environment variables.

Option B is incorrect because there is no such thing as 'kubectl inject configmap'; injection is done via pod spec. Option E is incorrect because Secrets cannot be used as ConfigMap data; they are separate resources.

Full explanation →

79

MCQeasy

Which of the following is NOT a control plane component in Kubernetes?

A.kube-scheduler

B.etcd

C.kube-proxy

D.kube-apiserver

AnswerC

kube-proxy runs on each worker node, not on the control plane.

Why this answer

kube-proxy is not a control plane component; it is a node-level (worker) component responsible for implementing network rules and handling service-to-pod traffic via iptables or IPVS. The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.

Exam trap

The trap here is that candidates often confuse kube-proxy as a control plane component because it interacts with the API server and is essential for networking, but it operates at the node level and is not part of the control plane's core management functions.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a core control plane component that assigns pods to nodes based on resource availability and constraints. Option B is wrong because etcd is the distributed key-value store that holds all cluster state and configuration data, making it a critical control plane component. Option D is wrong because kube-apiserver is the front-end of the control plane, exposing the Kubernetes API and handling all RESTful requests for cluster operations.

Full explanation →

80

MCQmedium

An administrator wants to ensure that a critical Pod always runs on a node that has an SSD. Which approach should be used?

A.Use podAffinity to prefer nodes running other Pods.

B.Set spec.nodeName to an SSD node's name.

C.Add a taint to nodes without SSD and add a toleration to the Pod.

D.Label SSD nodes with 'disk=ssd' and use nodeSelector in the Pod spec.

AnswerD

NodeSelector ensures the Pod is scheduled only on nodes with the label.

Why this answer

Option D is correct because using a nodeSelector with a label like 'disk=ssd' ensures that the Pod is scheduled only on nodes that have that specific label, which directly matches the requirement to run the Pod on a node with an SSD. This is the simplest and most reliable method for node-level selection in Kubernetes, as it leverages the scheduler's built-in filtering mechanism.

Exam trap

The trap here is that candidates often confuse taints and tolerations with node selection, thinking they can force a Pod onto a specific node type, when in fact taints only repel Pods from nodes and require tolerations to allow scheduling, not to guarantee placement on a desired node.

How to eliminate wrong answers

Option A is wrong because podAffinity is used to schedule Pods relative to other Pods (e.g., co-location), not to select nodes based on hardware characteristics like SSD presence. Option B is wrong because setting spec.nodeName bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not scale; it also requires manual knowledge of the node name and does not use labels or taints for dynamic selection. Option C is wrong because adding a taint to nodes without SSD would repel Pods that do not tolerate that taint, but the Pod would need a toleration to run on those nodes; this approach would prevent the Pod from running on non-SSD nodes but does not actively ensure it runs on an SSD node—it could still be scheduled on any node without the taint, including those without SSD if they are not tainted.

Full explanation →

81

MCQhard

A PriorityClass named 'high-priority' has a value of 1000. A pod using this PriorityClass is pending because no node has enough resources. A lower-priority pod is running on a node. What will happen?

A.The scheduler will preempt the lower-priority pod to schedule the high-priority pod

B.The high-priority pod will remain pending until the lower-priority pod finishes

C.The high-priority pod will be scheduled on a node by overcommitting resources

D.The scheduler will ignore the PriorityClass because the cluster does not have preemption enabled

AnswerA

If a pod cannot be scheduled due to resource constraints, the scheduler can preempt lower-priority pods to free resources.

Why this answer

Option A is correct. Priority-based preemption allows a higher-priority pod to preempt lower-priority pods to free up resources. The scheduler will evict the lower-priority pod to make room.

Option B is incorrect because preemption does not happen until scheduling. Option C is incorrect because preemption is enabled by default. Option D is incorrect because the higher-priority pod will be scheduled after preemption.

Full explanation →

82

MCQeasy

An administrator needs to create a PersistentVolume with 10Gi capacity, ReadWriteOnce access mode, and a reclaim policy of Retain. Which YAML snippet correctly defines this PV?

A.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv

B.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessMode: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv

C.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /data/pv

D.apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 10Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete hostPath: path: /data/pv

AnswerC

Correctly defines capacity, accessModes, and reclaim policy as Retain.

Why this answer

Option A correctly sets capacity.storage, accessModes, and persistentVolumeReclaimPolicy. Option B uses ReadWriteMany which is not required. Option C uses Delete policy instead of Retain.

Option D has incorrect field name 'accessMode' (should be 'accessModes').

Full explanation →

83

MCQmedium

You create a ConfigMap named 'app-config' with key 'database.url'. Which command correctly creates a pod that injects this ConfigMap value as an environment variable named 'DB_URL'?

A.kubectl run my-pod --image=nginx --envFrom=configmap/app-config

B.Create a pod YAML with env.valueFrom.configMapKeyRef

C.kubectl run my-pod --image=nginx --env="DB_URL=configmap:app-config:database.url"

D.kubectl run my-pod --image=nginx --from-configmap=app-config

AnswerB

This is the correct Kubernetes-native way to inject a specific key from a ConfigMap as an environment variable.

Why this answer

The correct command uses kubectl run with --env and references the ConfigMap value: --env=DB_URL=$(kubectl get configmap app-config -o jsonpath='{.data.database\.url}'). However, this is complex; typically you'd use a pod spec. But among options, the one that uses --from-configmap is not valid for kubectl run.

The correct approach in a pod spec is to use valueFrom.configMapKeyRef. For command-line, we need to create a pod with inline env. Option C is closest by using envFrom with a configMapRef.

Note: kubectl run does not support envFrom directly; you'd use a YAML. But for the sake of question, choose the best answer.

Full explanation →

84

MCQeasy

Which kubectl command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl apply configmap app-config config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl create configmap app-config --from-env-file=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

Correct syntax to create ConfigMap from a file.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the file 'config.properties'. The `--from-file` flag reads the file as-is and stores its content under a key that defaults to the filename (config.properties). This is the standard method for creating a ConfigMap from a single file.

Exam trap

The trap here is confusing `--from-file` with `--from-env-file` or `--from-literal`, where candidates mistakenly think `--from-env-file` is the correct way to import a properties file, but `--from-env-file` parses the file line by line for KEY=VALUE pairs and does not preserve the raw file content.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` is used to apply a configuration to a resource from a file (typically YAML/JSON), not to create a ConfigMap from a properties file; the syntax is invalid. Option B is wrong because `--from-literal` expects key=value pairs directly in the command, not a filename; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal key without a value, not read the file. Option C is wrong because `--from-env-file` is used to import key-value pairs from a file formatted as environment variables (e.g., KEY=VALUE per line), but it does not preserve the raw file content; it parses the file and creates separate keys, which is not the same as storing the entire file under a single key.

Full explanation →

85

MCQeasy

You want to see events sorted by timestamp in the 'kube-system' namespace. Which command should you use?

A.kubectl describe events -n kube-system

B.kubectl get events -n kube-system --sort-by='.metadata.creationTimestamp'

C.kubectl get events -n kube-system --sort-by='.lastTimestamp'

D.kubectl logs -n kube-system events

AnswerB

Correct sorting field and namespace.

Why this answer

kubectl get events --sort-by='.metadata.creationTimestamp' -n kube-system shows events sorted by creation time.

Full explanation →

86

MCQeasy

Which Service type exposes a Service on each Node's IP at a static port in the range 30000-32767?

A.NodePort

B.ExternalName

C.ClusterIP

D.LoadBalancer

AnswerA

NodePort opens a specific port on all nodes.

Why this answer

A NodePort Service exposes the Service on each Node's IP at a static port in the range 30000-32767. When you create a NodePort Service, Kubernetes allocates a port from that range (or you can specify one) and opens that port on every node in the cluster, forwarding traffic to the Service's ClusterIP and then to the selected Pods.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking LoadBalancer also uses the 30000-32767 port range on nodes, but LoadBalancer typically uses a cloud provider's load balancer and does not guarantee a static node port in that range unless NodePort is also specified.

How to eliminate wrong answers

Option B is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any port on nodes. Option C is wrong because ClusterIP exposes the Service only on a cluster-internal IP, not on a static port on each node's IP. Option D is wrong because LoadBalancer provisions an external load balancer (e.g., from a cloud provider) and does not directly expose a static port in the 30000-32767 range on each node's IP.

Full explanation →

87

Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally? (Select TWO.)

Select 2 answers

A.NodePort

B.Headless

C.LoadBalancer

D.ExternalName

E.ClusterIP

AnswersA, C

NodePort exposes the Service on each node's IP at a static port, accessible from outside the cluster.

Why this answer

NodePort exposes on a static port on each node. LoadBalancer provisions an external load balancer. ClusterIP is internal.

ExternalName is a DNS alias. Headless is for stateful workloads without a single IP.

Full explanation →

88

MCQeasy

Which command is used to prevent a node from being scheduled with new pods?

A.kubectl cordon <node>

B.kubectl taint <node> key=value:NoSchedule

C.kubectl patch node <node> -p '{"spec":{"unschedulable":true}}'

D.kubectl drain <node>

AnswerA

Correct command.

Why this answer

The `kubectl cordon <node>` command marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the standard Kubernetes command for this purpose, directly setting the `spec.unschedulable` field to `true` on the node object.

Exam trap

The trap here is that candidates confuse `kubectl taint` with `kubectl cordon`, thinking a NoSchedule taint universally blocks all pods, when in fact it only blocks pods without matching tolerations, whereas cordon blocks all new pods unconditionally.

How to eliminate wrong answers

Option B is wrong because `kubectl taint <node> key=value:NoSchedule` applies a taint that prevents pod scheduling only for pods that do not tolerate that specific taint, not for all pods universally; it is a pod-level scheduling constraint, not a node-level cordon. Option C is wrong because while `kubectl patch node <node> -p '{"spec":{"unschedulable":true}}'` technically achieves the same effect as cordon, it is not the standard or recommended command for this task—`kubectl cordon` is the explicit, user-friendly command designed for this purpose. Option D is wrong because `kubectl drain <node>` evicts all existing pods from the node (with proper PodDisruptionBudgets) and then cordons it, which is a more disruptive operation than simply preventing new pods from being scheduled.

Full explanation →

89

MCQmedium

You have a DaemonSet that runs on all nodes. You need to ensure it does NOT run on a node labeled 'disk=ssd'. Which field in the DaemonSet spec should you use?

A.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution with NotIn operator

B.spec.template.spec.nodeSelector with disk: ssd

C.spec.template.spec.tolerations with key disk value ssd

D.spec.updateStrategy.rollingUpdate.maxUnavailable

AnswerA

This anti-affinity rule ensures pods are not scheduled on nodes with disk=ssd.

Why this answer

Option A is correct because `nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` with the `NotIn` operator allows you to specify that the DaemonSet pod must not be scheduled on nodes with the label `disk=ssd`. This is the proper way to express an anti-affinity rule that excludes nodes based on a label value, ensuring the DaemonSet runs on all nodes except those with `disk=ssd`.

Exam trap

The trap here is that candidates often confuse `nodeSelector` (which selects nodes to include) with the need to exclude nodes, and they may incorrectly choose `nodeSelector` with a negative label value, not realizing that `nodeSelector` only supports equality-based inclusion, not exclusion.

How to eliminate wrong answers

Option B is wrong because `nodeSelector` with `disk: ssd` would require the pod to run only on nodes with that label, which is the opposite of the desired behavior (it would restrict the DaemonSet to SSD nodes instead of excluding them). Option C is wrong because `tolerations` are used to allow pods to be scheduled on nodes with taints, not to control scheduling based on node labels; tolerations do not prevent scheduling on nodes with a specific label. Option D is wrong because `spec.updateStrategy.rollingUpdate.maxUnavailable` controls the number of pods that can be unavailable during a rolling update of the DaemonSet, not the scheduling constraints for which nodes the DaemonSet runs on.

Full explanation →

90

MCQmedium

You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?

A.kubeadm upgrade plan

B.kubeadm upgrade apply v1.29.0

C.kubeadm upgrade node

D.kubeadm upgrade diff

AnswerA

kubeadm upgrade plan checks the feasibility and shows the steps.

Why this answer

After upgrading kubeadm on the control plane node, the first command to run is `kubeadm upgrade plan`. This command checks the current cluster version, validates that the upgrade path is supported (e.g., from v1.28.0 to v1.29.0), and displays the available versions to upgrade to, along with any manual steps required. It is a prerequisite to ensure the upgrade is safe before proceeding with `kubeadm upgrade apply`.

Exam trap

The trap here is that candidates often confuse the sequence and jump directly to `kubeadm upgrade apply`, thinking it is the first step, but the CKA exam tests the prerequisite validation step (`kubeadm upgrade plan`) to ensure a safe upgrade process.

How to eliminate wrong answers

Option B is wrong because `kubeadm upgrade apply v1.29.0` should only be run after `kubeadm upgrade plan` has confirmed the upgrade path and there are no blockers; running it first could lead to an unsupported or failed upgrade. Option C is wrong because `kubeadm upgrade node` is used on worker nodes (or secondary control plane nodes) to upgrade the local kubelet and kube-proxy, not on the primary control plane node during the initial upgrade. Option D is wrong because `kubeadm upgrade diff` is not a valid kubeadm command; it does not exist in the kubeadm toolset and would result in an error.

Full explanation →

91

MCQeasy

Which command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create cm app-config --file=config.properties

B.kubectl create configmap app-config --from-literal=config.properties

C.kubectl create configmap app-config --from-env-file=config.properties

D.kubectl create configmap app-config --from-file=config.properties

AnswerD

Correct.

Why this answer

Option D is correct because `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the specified file. The `--from-file` flag reads the file and stores its entire content as a key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content.

Exam trap

The trap here is confusing `--from-file` (which imports a file's content as a ConfigMap entry) with `--from-env-file` (which imports environment variables from a file), or using the non-existent `--file` flag, leading candidates to select options that either use the wrong flag or misinterpret the file's purpose.

How to eliminate wrong answers

Option A is wrong because `kubectl create cm` is a valid alias for `kubectl create configmap`, but the flag `--file=config.properties` does not exist; the correct flag is `--from-file`. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal value, not a file path. Option C is wrong because `--from-env-file` is used to import environment variables from a file formatted as key=value lines (like a .env file), but it expects the file to contain multiple lines of environment variables, not a single file's content as a ConfigMap entry.

Full explanation →

92

MCQeasy

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. What is the most likely cause?

A.The node is out of disk space

B.The pod exceeded its memory limit

C.The container command is invalid

D.The container image name is misspelled

AnswerD

A misspelled image name causes the pull to fail.

Why this answer

ImagePullBackOff typically occurs when Kubernetes cannot pull the container image from the registry.

Full explanation →

93

MCQhard

Which CSI driver feature must be supported by the driver to allow expanding a PVC while the pod using it is still running?

A.Volume attach

B.Volume expansion

C.Mount options

D.ExpandInUsePersistentVolume

AnswerD

This capability in the CSIDriver spec allows expansion while the volume is in use by a pod.

Why this answer

Online expansion requires the CSIDriver object to have the 'ExpandInUsePersistentVolume' capability set to true.

Full explanation →

94

MCQmedium

You suspect the kube-apiserver is down. Which command should you run on the control-plane node to check its status?

A.systemctl status kube-apiserver

B.kubectl get pods -n kube-system

C.journalctl -u kubelet

D.ps aux | grep kube-controller

AnswerA

Correct. This checks the systemd service status.

Why this answer

kube-apiserver runs as a static pod or systemd service. systemctl is used to check systemd services.

Full explanation →

95

Multi-Selectmedium

A pod is stuck in 'Pending' state. Which THREE are common causes for this?

Select 3 answers

A.Node not registered with the cluster

B.Container image name is incorrect

C.Insufficient CPU or memory resources on any node

D.Node taints that the pod does not tolerate

E.PersistentVolumeClaim not bound to a volume

AnswersC, D, E

If no node has enough resources, the pod stays Pending.

Why this answer

Pending pods often indicate resource constraints (A), taint/toleration mismatch (B), or PVC not bound (C). Node not registered (D) would prevent scheduling but is less common. Image pull error (E) leads to ImagePullBackOff, not Pending.

Full explanation →

96

MCQhard

You create a Pod with an init container and a main container. The init container runs a script that writes to a shared volume. The main container reads from that volume. However, the Pod is stuck in 'Init:CrashLoopBackOff'. What is the most likely cause?

A.The init container is waiting for the main container to start

B.The init container's command is failing due to an error in the script

C.The main container has a resource limit that is too low

D.The shared volume is not mounted with the correct permissions

AnswerB

Init container crash loops usually indicate a failing command.

Why this answer

Option C is correct. If the init container is in CrashLoopBackOff, it means it is failing repeatedly. The most common cause is that the init container's command is failing (e.g., script error, missing dependencies).

Option A is incorrect because resource limits on the main container do not affect init containers. Option B is incorrect because volume permissions would cause runtime issues, but the init container would still run. Option D is incorrect because init containers run sequentially; if one fails, the next does not start.

Full explanation →

97

MCQmedium

You run 'kubectl top nodes' but get 'error: metrics not available yet'. What is the most likely cause?

A.kubectl top requires root access

B.Nodes have insufficient CPU

C.The Metrics Server is not deployed

D.Kubelet is not running on nodes

AnswerC

Metrics Server provides resource metrics; without it, top commands fail.

Why this answer

Metrics server is not deployed or not ready, so resource metrics are unavailable.

Full explanation →

98

Multi-Selecteasy

Which TWO of the following are valid ways to inject configuration data into a pod? (Select TWO.)

Select 2 answers

A.Editing the pod's spec directly via kubectl edit

B.Using a Sidecar container to fetch config from a remote API

C.Mounting a ConfigMap as a volume

D.Injecting a ConfigMap as environment variables

E.Storing config in a PersistentVolume

AnswersC, D

Correct. ConfigMap can be mounted as a volume.

Why this answer

Correct options: A and D. ConfigMaps can be mounted as volumes or injected as environment variables. Secrets can also be used similarly.

Option B is not a method; direct editing is not injection. Option C is not standard. Option E is for storing raw data, not injecting.

Full explanation →

99

Multi-Selecthard

Your kubeadm cluster was initialized with default certificates. You need to check the expiration of the API server certificate and renew it if necessary. Which TWO commands are appropriate? (Choose TWO.)

Select 2 answers

A.kubeadm certs renew all

B.kubeadm certs check-expiration

C.kubectl config view

D.kubeadm upgrade plan

E.kubectl cluster-info

AnswersA, B

Renews all certificates managed by kubeadm.

Why this answer

Option A is correct because `kubeadm certs renew all` renews all PKI certificates in the cluster, including the API server certificate, without requiring a full cluster reinitialization. Option B is correct because `kubeadm certs check-expiration` displays the expiration dates of all certificates managed by kubeadm, allowing you to verify the API server certificate's expiry before deciding to renew.

Exam trap

The trap here is that candidates confuse `kubeadm certs` subcommands with `kubectl` commands, mistakenly thinking `kubectl config view` or `kubectl cluster-info` can reveal certificate expiration, when in fact only `kubeadm` has direct access to the PKI files on the control plane node.

Full explanation →

100

MCQmedium

To make a node unschedulable without evicting existing pods, which command should be used?

A.kubectl cordon node01

B.kubectl taint node01 key=value:NoSchedule

C.kubectl drain node01

D.kubectl uncordon node01

AnswerA

Cordon marks the node as unschedulable but does not evict pods.

Why this answer

Option A is correct because `kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the precise command for the task described, as it modifies the node's `spec.unschedulable` field to `true` without affecting running workloads.

Exam trap

The trap here is that candidates confuse taints (which control pod placement based on tolerations) with cordoning (which globally blocks all scheduling), or they mistakenly choose `drain` which evicts pods, missing the explicit 'without evicting existing pods' constraint.

How to eliminate wrong answers

Option B is wrong because `kubectl taint node01 key=value:NoSchedule` adds a taint that prevents new pods from being scheduled unless they tolerate the taint, but it does not make the node unschedulable globally; pods without tolerations are blocked, but the node remains schedulable for tolerating pods, and existing pods are unaffected. Option C is wrong because `kubectl drain node01` evicts all existing pods from the node (with graceful termination) and then cordons it, which violates the requirement to not evict pods. Option D is wrong because `kubectl uncordon node01` makes a node schedulable again, which is the opposite of the desired action.

Full explanation →

101

MCQmedium

An admin runs 'kubectl get pods' and sees a pod in the 'Pending' state. Which is the most likely cause?

A.The pod has been deleted

B.The pod is waiting for a container to start

C.The pod cannot be scheduled due to insufficient resources

D.The container image is invalid

AnswerC

Pending often indicates the scheduler cannot find a node with enough resources.

Why this answer

A pod in 'Pending' state indicates that the pod has been accepted by the Kubernetes API server but is not yet running. The most common cause is that the scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other scheduling constraints (taints, node selector, affinity rules). This results in the pod remaining unscheduled, hence 'Pending'.

Exam trap

CNCF often tests the distinction between pod states: candidates confuse 'Pending' with image-related issues, but 'Pending' specifically means the pod has not been scheduled yet, whereas image errors occur after scheduling.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because waiting for a container to start is part of the normal pod lifecycle after scheduling, and the pod would be in 'ContainerCreating' or 'Running' state, not 'Pending'. Option D is wrong because an invalid container image would cause the pod to transition to 'ImagePullBackOff' or 'ErrImagePull' after scheduling, not remain in 'Pending'.

Full explanation →

102

MCQhard

A cluster administrator wants to ensure that a set of batch processing Pods are preemptible and should not cause disruption to other critical workloads. Which combination of scheduling features should be used?

A.Taint all worker nodes with a custom taint and add tolerations to batch Pods.

B.Assign a low priority class to the batch Pods and set a PodDisruptionBudget for critical workloads.

C.Use nodeAffinity to schedule batch Pods on dedicated nodes.

D.Use resource quotas to limit the batch Pods' resource consumption.

AnswerB

Low priority allows preemption, and PDB prevents excessive disruption to critical Pods.

Why this answer

Option B is correct because assigning a low priority class to batch Pods ensures they are preempted by higher-priority critical workloads when resources are scarce, while a PodDisruptionBudget (PDB) for critical workloads guarantees that a minimum number of those Pods remain available during voluntary disruptions (e.g., node drains). This combination allows batch Pods to be preemptible without causing disruption to critical workloads, aligning with the requirement.

Exam trap

The trap here is that candidates often confuse taints/tolerations or node affinity with preemption and disruption protection, failing to realize that only priority classes enable preemption and PDBs control voluntary disruptions.

How to eliminate wrong answers

Option A is wrong because tainting worker nodes with a custom taint and adding tolerations to batch Pods only prevents other Pods from scheduling on those nodes unless they have the toleration; it does not make batch Pods preemptible or protect critical workloads from disruption. Option C is wrong because using nodeAffinity to schedule batch Pods on dedicated nodes isolates them but does not provide preemption capability or disruption protection for critical workloads; dedicated nodes can still be disrupted by node failures or maintenance. Option D is wrong because resource quotas limit the total resource consumption of batch Pods but do not make them preemptible or prevent disruption to critical workloads; quotas only enforce resource caps, not scheduling priority or availability guarantees.

Full explanation →

103

MCQhard

A PersistentVolumeClaim named 'pvc-data' is stuck in Pending state. Running 'kubectl describe pvc pvc-data' shows: 'waiting for a volume to be created, either by external provisioner or by manually creating a PersistentVolume'. The cluster has a default StorageClass named 'fast-ssd' with a provisioner 'kubernetes.io/gce-pd'. What is the most likely cause?

A.The cluster has no nodes with the required storage driver.

B.The PVC requests a capacity that exceeds the available quota.

C.The volumeBindingMode is set to WaitForFirstConsumer.

D.The PVC's storage class name is misspelled.

AnswerC

With WaitForFirstConsumer, the volume is not provisioned until a pod using the PVC is scheduled. The PVC remains Pending until then.

Why this answer

The message indicates dynamic provisioning is stalled. This commonly happens if the StorageClass's volumeBindingMode is set to WaitForFirstConsumer and no pod has claimed the PVC yet. The PVC will stay Pending until a pod uses it, at which point the volume is created in the correct zone.

Full explanation →

104

Multi-Selecteasy

Which THREE of the following are CNI plugins?

Select 3 answers

A.kube-proxy

B.Flannel

C.Weave

D.CoreDNS

E.Calico

AnswersB, C, E

Correct. Flannel is a CNI plugin.

Why this answer

Options A, B, and D are correct. Calico, Flannel, and Weave are popular CNI plugins. CoreDNS is a DNS server, not a CNI plugin. kube-proxy is a network proxy component, not a CNI plugin.

Full explanation →

105

MCQmedium

A Deployment has been updated with a new image, but the rollout is stuck. You run 'kubectl rollout status deployment/my-app' and see 'Waiting for rollout to finish: 2 out of 5 new replicas have been updated...'. The deployment's strategy is RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. What is the most likely cause?

A.The rollout is complete; the status message is misleading.

B.The new pods are unable to start due to resource constraints on nodes.

C.The deployment has a missing selector label.

D.The old ReplicaSet is not scaling down because the new ReplicaSet has not met the minReadySeconds.

AnswerB

If new pods fail to become Ready, the rollout cannot proceed because maxUnavailable prevents scaling down old pods beyond 25%.

Why this answer

The rollout status shows that only 2 out of 5 new replicas have been updated, indicating that the new Pods are failing to become Ready. Given the RollingUpdate strategy with maxSurge: 25% and maxUnavailable: 25%, the controller can create up to 1 extra Pod (25% of 5 = 1.25, rounded up) and can terminate up to 1 old Pod at a time. If new Pods cannot start due to resource constraints (e.g., insufficient CPU/memory), they will remain in a Pending or CrashLoopBackOff state, preventing the ReplicaSet from reaching the desired count and stalling the rollout.

Exam trap

The trap here is that candidates may confuse a stuck rollout with a missing selector or minReadySeconds issue, but the partial progress (2 out of 5) strongly points to Pod startup failures, not configuration mismatches or timing delays.

How to eliminate wrong answers

Option A is wrong because the rollout is explicitly not complete; the status message indicates 2 out of 5 new replicas have been updated, and the command is still waiting, meaning the rollout is in progress or stuck. Option C is wrong because a missing selector label would cause the Deployment to fail to match any Pods entirely, resulting in zero replicas being created, not a partial update of 2 out of 5. Option D is wrong because minReadySeconds affects how long a Pod must be Ready before the controller considers it available, but the issue here is that new Pods are not becoming Ready at all, not that they are waiting for a stabilization period.

Full explanation →

106

MCQeasy

Which of the following is NOT a valid Service type in Kubernetes?

A.ExternalName

B.NodePort

C.Headless

D.ClusterIP

AnswerC

Headless is not a Service type; it's a configuration of ClusterIP.

Why this answer

Headless is not a valid Service type in Kubernetes; it is a configuration of a ClusterIP service where the cluster IP is set to 'None' to return individual pod DNS records instead of a single virtual IP. The valid Service types are ClusterIP, NodePort, LoadBalancer, and ExternalName.

Exam trap

The trap here is that candidates often confuse 'Headless' as a separate Service type because it is a common configuration pattern, but Kubernetes officially defines only four Service types (ClusterIP, NodePort, LoadBalancer, ExternalName), and Headless is merely a variant of ClusterIP.

How to eliminate wrong answers

Option A is wrong because ExternalName is a valid Service type that maps a service to a DNS name via the externalName field, returning a CNAME record. Option B is wrong because NodePort is a valid Service type that exposes the service on a static port on each node's IP, typically used for external access. Option D is wrong because ClusterIP is the default Service type that exposes the service on a cluster-internal IP, reachable only within the cluster.

Full explanation →

107

MCQhard

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

A.Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.

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

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

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

AnswerA

This follows the official upgrade sequence: upgrade kubeadm, then control plane, then worker nodes one by one after draining.

Why this answer

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

Exam trap

The trap here is that candidates often think upgrading kubelet and kubectl first is safe, but the CKA tests the understanding that kubeadm and control plane components must be upgraded before worker node binaries to maintain version compatibility and cluster stability.

How to eliminate wrong answers

Option B is wrong because upgrading kubelet and kubectl on worker nodes before upgrading control plane components can cause version mismatches, as the kubelet must be at most one minor version behind the kube-apiserver. Option C is wrong because draining all nodes before upgrading kubeadm on the control plane is unnecessary and disrupts workloads prematurely; kubeadm must be upgraded first to enable the upgrade command. Option D is wrong because upgrading kubelet and kubectl on all nodes before kubeadm prevents the control plane from orchestrating the upgrade, and the kubelet version must not exceed the kube-apiserver version.

Full explanation →

108

Multi-Selectmedium

Which TWO of the following statements about StorageClass are correct? (Select two.)

Select 2 answers

A.A StorageClass must have a provisioner field set to 'kubernetes.io/no-provisioner' to use static provisioning.

B.A StorageClass is a namespaced resource.

C.The reclaimPolicy in a StorageClass defaults to Retain.

D.A StorageClass can be used for dynamic provisioning of PersistentVolumes.

E.A StorageClass can specify a volumeBindingMode, which can be Immediate or WaitForFirstConsumer.

AnswersD, E

StorageClass defines a provisioner that creates PVs dynamically.

Why this answer

StorageClass allows dynamic provisioning and has a reclaimPolicy that defaults to Delete. It also can specify volumeBindingMode. The provisioner field is required.

So correct: A and C.

Full explanation →

109

Multi-Selectmedium

Which TWO of the following are valid ways to create a Role in the 'default' namespace that grants get and list on pods?

Select 2 answers

A.kubectl create role pod-reader --verb=get,list --resource=pods -n default

B.kubectl create role pod-reader --verb=discover --resource=pods -n default

C.kubectl create role pod-reader --verb=delete --resource=pods -n default

D.Apply a YAML with apiVersion: rbac.authorization.k8s.io/v1, kind: Role, rules: [apiGroups: [""], resources: ["pods"], verbs: ["get", "list"]]

E.kubectl create clusterrole pod-reader --verb=get,list --resource=pods

AnswersA, D

Imperative creation of Role with get and list on pods.

Why this answer

Option A is correct because `kubectl create role pod-reader --verb=get,list --resource=pods -n default` directly creates a Role in the default namespace with the specified verbs and resource. This command is a standard Kubernetes RBAC command that generates a Role with the correct apiGroups ("" for core resources) and the requested permissions.

Exam trap

The trap here is that candidates may confuse Role with ClusterRole, or assume that any verb like 'discover' is valid, or overlook that the question requires both 'get' and 'list' verbs specifically.

Full explanation →

110

MCQmedium

An administrator needs to allow a service account 'monitor-sa' in namespace 'monitoring' to read pods across all namespaces. Which RBAC resources should be created?

A.Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa

B.Create a ClusterRole with pod read permissions and a RoleBinding in each namespace

C.Create a Role in the monitoring namespace and a RoleBinding to monitor-sa

D.Create a Role with pod read permissions and a ClusterRoleBinding to monitor-sa

AnswerA

ClusterRole is cluster-scoped, and ClusterRoleBinding grants the permissions to the service account across all namespaces.

Why this answer

A ClusterRole is required because the service account needs to read pods across all namespaces, which is a cluster-scoped permission. A ClusterRoleBinding binds that ClusterRole to the service account 'monitor-sa', granting the permissions cluster-wide. This is the correct approach for cross-namespace access.

Exam trap

The trap here is that candidates often confuse Role vs ClusterRole scope, thinking a Role can be used with a ClusterRoleBinding or that multiple RoleBindings are the only way to achieve cross-namespace access.

How to eliminate wrong answers

Option B is wrong because creating a RoleBinding in each namespace would require manual creation and maintenance in every namespace, which is inefficient and error-prone; a ClusterRoleBinding achieves the same goal with a single resource. Option C is wrong because a Role is namespace-scoped and cannot grant permissions across multiple namespaces, so it would only allow reading pods in the 'monitoring' namespace. Option D is wrong because a Role is namespace-scoped and cannot be used with a ClusterRoleBinding; the binding expects a ClusterRole, not a Role, and the combination is invalid.

Full explanation →

111

MCQhard

A StatefulSet named 'web' is defined with a volumeClaimTemplate. The StatefulSet has replicas: 3. The volumeClaimTemplate specifies storage: 1Gi and storageClassName: 'ssd'. After the StatefulSet is created, you run 'kubectl get pvc' and see three PVCs named 'www-web-0', 'www-web-1', and 'www-web-2'. What is the name of the PersistentVolumeClaim template used in the StatefulSet?

A.web-www

B.web

C.www

D.ssd

AnswerC

The PVC naming pattern is <template-name>-<statefulset-name>-<ordinal>. Here it's 'www-web-0', so template name is 'www'.

Why this answer

In a StatefulSet volumeClaimTemplate, the PVCs are named as <template-name>-<statefulset-name>-<ordinal>. The observed PVCs are 'www-web-0', 'www-web-1', 'www-web-2'. The pattern: the template name is 'www', the StatefulSet name is 'web', and the ordinals are 0,1,2.

So the template name is 'www'.

Full explanation →

112

Multi-Selectmedium

Which TWO of the following are valid access modes for PersistentVolumes?

Select 2 answers

A.ReadOnlyMany (ROX)

B.ReadWriteMany (RWX)

C.ReadWriteOnce (RWO)

D.WriteOnce (WO)

E.ReadWriteOncePod (RWOP)

AnswersA, C

ROX is a valid access mode.

Why this answer

Valid access modes include ReadWriteOnce (RWO) and ReadOnlyMany (ROX). ReadWriteMany (RWX) is also valid but not listed as a correct option here. ReadWriteOncePod (RWOP) is valid but not listed.

WriteOnce is not a valid access mode.

Full explanation →

113

MCQmedium

You have a pod with resource requests: cpu: 500m, memory: 128Mi. The node has 4 CPU cores and 8Gi memory. What is the maximum number of such pods that can be scheduled on this node based on CPU only?

A.4

B.16

C.6

D.8

AnswerD

4000m / 500m = 8 pods based on CPU requests.

Why this answer

The node has 4 CPU cores, which equals 4000m (millicores). Each pod requests 500m CPU. Dividing 4000m by 500m gives 8 pods.

This is the maximum number that can be scheduled based on CPU alone, assuming no other pods or system overhead. Option D is correct.

Exam trap

The trap here is that candidates may confuse CPU cores with millicores (e.g., thinking 4 cores means 4 pods at 500m each, or miscomputing 500m as half a core leading to 8 pods but then incorrectly dividing by memory limits).

How to eliminate wrong answers

Option A is wrong because 4 pods would only use 2000m CPU, leaving half the node's CPU unused, which is not the maximum. Option B is wrong because 16 pods would require 8000m CPU, exceeding the node's 4000m capacity. Option C is wrong because 6 pods would use 3000m CPU, still leaving 1000m unused, so it is not the maximum.

Full explanation →

114

MCQeasy

Which kube-proxy mode supports connection-based load balancing using Linux IPVS?

A.ipvs

B.iptables

C.kernelspace

D.userspace

AnswerA

IPVS (IP Virtual Server) provides advanced load balancing algorithms (e.g., least connections, source hashing).

Full explanation →

115

MCQhard

You are a cluster administrator for a multi-tenant Kubernetes cluster. Each tenant runs a set of microservices in their own namespace. The cluster uses a custom CSI driver that provisions storage on a NetApp storage array. Recently, several tenants reported that their pods are stuck in Pending state with events indicating 'failed to provision volume' and 'timeout waiting for a volume to be created'. Upon investigation, you notice that the CSI controller pod is running but has high memory usage, and logs show 'context deadline exceeded' errors when calling the storage array API. The storage array is healthy and responsive to manual API calls from your workstation. Meanwhile, PVCs created in a test namespace with the same StorageClass succeed. What is the most likely cause and the best course of action?

A.Adjust the CSI driver configuration to increase the maximum number of concurrent operations and reduce the request timeout

B.Increase the memory limit of the CSI controller pod to reduce OOM risk

C.Restart the CSI controller pod to clear its memory and reset connections

D.Add a network policy to isolate tenant namespaces to reduce load on the CSI driver

AnswerA

Increasing concurrency and reducing timeouts can help handle the volume of requests and prevent the gRPC connection pool from being exhausted.

Why this answer

Option A is correct because the 'context deadline exceeded' errors and high memory usage in the CSI controller pod indicate that the driver is overwhelmed by the number of concurrent volume provisioning requests, causing timeouts. Increasing the maximum number of concurrent operations allows the driver to handle more requests in parallel, while reducing the request timeout prevents long waits for unresponsive calls, aligning with the healthy storage array and successful test PVCs.

Exam trap

The trap here is that candidates may focus on the high memory usage and assume an OOM issue (Option B) or a transient failure (Option C), rather than recognizing the concurrency and timeout misconfiguration as the root cause of the provisioning failures.

How to eliminate wrong answers

Option B is wrong because increasing the memory limit does not address the root cause of timeouts due to excessive concurrent operations; high memory usage is a symptom, not the cause, and OOM risk is not indicated. Option C is wrong because restarting the CSI controller pod would only temporarily clear memory and reset connections, but the same workload pattern would quickly re-create the timeout issue, making it a non-permanent fix. Option D is wrong because network policies isolate traffic at the network layer, not the CSI driver's internal request handling; tenant namespaces do not directly affect the CSI controller's ability to provision volumes, and the issue is with the driver's concurrency limits, not network congestion.

Full explanation →

116

MCQmedium

You have a CronJob that runs a backup job every 5 minutes. The job takes about 2 minutes to complete. You notice that sometimes two job pods are running simultaneously. What is the most likely cause?

A.The backup takes longer than expected due to data volume.

B.The concurrencyPolicy is set to 'Allow' (default) which permits overlapping executions.

C.The job's parallelism is set to 2.

D.The CronJob's startingDeadlineSeconds is set too low.

AnswerB

Default concurrencyPolicy is Allow, so new jobs can start before old ones finish.

Why this answer

Option B is correct because the default `concurrencyPolicy` for a CronJob is `Allow`, which permits new Job pods to start even if a previous Job is still running. Since the backup takes 2 minutes and the CronJob runs every 5 minutes, overlapping executions should not normally occur unless the Job duration exceeds the interval. However, if the `concurrencyPolicy` is set to `Allow`, the CronJob controller will create a new Job pod regardless of whether the previous one is still running, leading to simultaneous pods.

The most likely cause is that the `concurrencyPolicy` is explicitly or implicitly set to `Allow`, allowing overlapping executions.

Exam trap

The trap here is that candidates often assume the default `concurrencyPolicy` is `Forbid` or that CronJobs inherently prevent overlapping executions, but the default is actually `Allow`, which permits concurrent runs unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because the backup taking longer than expected due to data volume would cause the Job to run longer, but it does not explain why two pods are running simultaneously; with the default `Forbid` concurrency policy, a new pod would not be created until the previous one completes. Option C is wrong because `parallelism` is a property of a Job, not a CronJob; it controls how many Pods run in parallel for a single Job execution, not whether multiple Job executions can overlap. Option D is wrong because `startingDeadlineSeconds` controls how long the CronJob controller will try to start a missed Job after its scheduled time; it does not affect whether concurrent executions are allowed.

Full explanation →

117

MCQmedium

You need to create a ServiceAccount named 'my-sa' and a ClusterRoleBinding that binds the built-in 'view' ClusterRole to that ServiceAccount. Which set of commands achieves this?

A.kubectl create sa my-sa && kubectl create clusterrolebinding my-binding --clusterrole=view --sa=my-sa

B.kubectl create sa my-sa -n default && kubectl create clusterrolebinding my-binding --clusterrole=view --serviceaccount=default:my-sa

C.kubectl create sa my-sa && kubectl create rolebinding my-binding --clusterrole=view --serviceaccount=my-sa

D.kubectl create serviceaccount my-sa && kubectl create clusterrolebinding my-binding --clusterrole=view --user=my-sa

AnswerB

Correct syntax: sa creation and clusterrolebinding with --serviceaccount=namespace:name.

Why this answer

Option B is correct because it creates the ServiceAccount 'my-sa' in the 'default' namespace (as required for a ServiceAccount) and then uses the correct `--serviceaccount=namespace:name` syntax to bind the built-in 'view' ClusterRole to that ServiceAccount via a ClusterRoleBinding. The `--serviceaccount` flag must include the namespace to uniquely identify the ServiceAccount in a cluster-scoped binding.

Exam trap

The trap here is that candidates often forget to include the namespace in the `--serviceaccount` flag or mistakenly use `--sa` or `--user` instead, leading to an incorrect or incomplete binding.

How to eliminate wrong answers

Option A is wrong because it uses the `--sa` flag, which is not a valid flag for `kubectl create clusterrolebinding`; the correct flag is `--serviceaccount`. Option C is wrong because it creates a RoleBinding instead of a ClusterRoleBinding, which would only grant permissions within a single namespace, not cluster-wide. Option D is wrong because it uses `--user=my-sa` instead of `--serviceaccount=default:my-sa`, and `kubectl create serviceaccount` is not a valid command (the correct command is `kubectl create sa`).

Full explanation →

118

MCQeasy

A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?

A.The deployment has a resource quota that prevents new pods

B.The pod's terminationGracePeriodSeconds is set to 0

C.The node controller has not yet evicted the pod

D.The deployment's replicas field is set to 2

AnswerC

The node controller waits for a default of 5 minutes before evicting pods from a failed node.

Why this answer

When a node fails, the node controller marks the node as `NodeReady=False` and waits for a configurable timeout (`pod-eviction-timeout`, default 5 minutes) before evicting pods. Until eviction, the deployment's ReplicaSet sees the pod as still existing (though on an unreachable node) and does not create a replacement. Option C correctly identifies that the node controller has not yet evicted the pod, which is the default behavior.

Exam trap

The trap here is that candidates assume a deployment immediately reschedules pods after a node failure, but the CKA tests knowledge of the node controller's eviction timeout and the fact that the ReplicaSet controller waits for pod eviction before creating replacements.

How to eliminate wrong answers

Option A is wrong because a resource quota would cause a failure to create a new pod (with an error event), not prevent the deployment from attempting rescheduling; the deployment would still try and fail, but the question states it has not rescheduled the missing pod. Option B is wrong because `terminationGracePeriodSeconds` affects how long a pod is given to shut down gracefully after a deletion request, not the node controller's eviction timeout or the deployment's rescheduling logic. Option D is wrong because if the deployment's `replicas` field were set to 2, the deployment would be satisfied with 2 running pods and would not attempt to reschedule; however, the question states the deployment originally had 3 replicas, so this would be a configuration change, not a transient failure scenario.

Full explanation →

119

Multi-Selecthard

Which three of the following are true about IngressClass?

Select 3 answers

A.An IngressClass can be marked as default by adding the annotation 'ingressclass.kubernetes.io/is-default-class: true'.

B.IngressClass can reference a controller name like 'nginx.org/ingress-controller'.

C.IngressClass is a namespaced resource.

D.Each cluster can only have one IngressClass.

E.An Ingress resource must specify an IngressClass if there is more than one IngressClass.

AnswersA, B, E

Correct annotation to set default.

Why this answer

IngressClass defines which controller should implement an Ingress. It can set a default IngressClass, and a cluster can have multiple IngressClasses. The IngressClass resource is cluster-scoped.

Full explanation →

120

MCQhard

You are tasked with upgrading a Kubernetes cluster from version 1.24 to 1.25. The cluster has one control plane node and three worker nodes, all running Ubuntu 20.04 with kubeadm. You have already upgraded the control plane node to v1.25.0 and it is healthy. You now need to upgrade the first worker node. On the worker node, you run 'kubeadm upgrade node' and it completes successfully. However, when you run 'kubectl drain worker1 --ignore-daemonsets', the node drain hangs indefinitely. You check the node and find that a DaemonSet pod named 'fluentd-*' is stuck in Terminating state. The DaemonSet is from the logging system and must remain running during the upgrade. You cannot delete the DaemonSet. What is the best course of action to complete the upgrade of this worker node?

A.Reinstall kubelet on the worker node and restart it

B.Skip draining the node and proceed with the kubelet upgrade

C.Add --delete-emptydir-data to the drain command

D.Cordon the node and then run kubectl drain with --force

AnswerD

Cordoning prevents new pods, and --force overrides the DaemonSet pod termination protection.

Why this answer

Option D is correct because the drain is hanging due to a DaemonSet pod stuck in Terminating state. Since DaemonSets are managed by the node controller and cannot be evicted by a normal drain, using `--force` bypasses the preflight checks that prevent drain when pods are not evictable. Cordoning the node first ensures no new workloads are scheduled, and `--force` allows the drain to proceed despite the stuck pod, which will be replaced by the DaemonSet controller on the upgraded node.

Exam trap

The trap here is that candidates think `--force` is only for pods with local data or that draining is optional, but the CKA exam tests the understanding that `--force` is necessary to bypass DaemonSet pod eviction failures during node maintenance.

How to eliminate wrong answers

Option A is wrong because reinstalling kubelet does not address the stuck DaemonSet pod; the drain hangs due to pod eviction failure, not a kubelet issue. Option B is wrong because skipping the drain can cause service disruption; the kubelet upgrade requires draining to safely terminate pods, and skipping it may leave pods running during the kubelet restart, leading to potential data loss or downtime. Option C is wrong because `--delete-emptydir-data` only allows eviction of pods with emptyDir volumes, but the DaemonSet pod is stuck in Terminating state due to the node controller's protection, not because of emptyDir volumes.

Full explanation →

121

MCQhard

You are a cluster administrator managing a multi-node Kubernetes cluster version 1.22. The cluster runs critical applications in the 'production' namespace. You have been asked to upgrade the control plane node to version 1.23 while minimizing downtime. The cluster uses a single control plane node (not HA). You have already backed up etcd and verified the backup is valid. You have also reviewed the upgrade notes and there are no breaking changes that affect your workloads. You have drained the control plane node and ensured all pods are evicted. The node is now in 'Ready,SchedulingDisabled' state. You then run 'kubeadm upgrade plan' and see that upgrade to v1.23.0 is available. Next, you run 'kubeadm upgrade apply v1.23.0'. The command completes successfully. However, when you try to uncordon the node with 'kubectl uncordon <node>', you get an error: 'error: unable to update node: the object has been modified; please apply your changes to the latest version and try again'. What is the most likely cause and the correct next step?

A.Re-drain the node to reset its state, then uncordon again.

B.Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.

C.Restart the kubelet on the control plane node to refresh the node object.

D.Generate a new bootstrap token and rejoin the node to the cluster.

AnswerB

The conflict is due to the node being updated; retrying should resolve it.

Why this answer

The error 'the object has been modified' indicates a resource conflict due to concurrent updates to the node object, typically from the kubelet or controller manager updating the node status simultaneously. This is a transient optimistic locking conflict in Kubernetes, and simply retrying the 'kubectl uncordon' command will resolve it because the conflict is temporary and the node is already upgraded and ready to be scheduled.

Exam trap

The trap here is that candidates may think the node is in a broken state requiring a restart or rejoin, when in fact the error is just a transient API conflict that is resolved by retrying the uncordon command.

How to eliminate wrong answers

Option A is wrong because re-draining the node is unnecessary and would evict pods again, causing additional downtime; the node is already drained and the issue is just a conflict on the node object. Option C is wrong because restarting the kubelet does not resolve an API object conflict; the kubelet is already running and the node is in 'Ready,SchedulingDisabled' state, so restarting it would not refresh the node's resourceVersion or fix the conflict. Option D is wrong because generating a new bootstrap token and rejoining the node is a drastic step for a node that is already part of the cluster and upgraded; it would reinitialize the node and cause unnecessary disruption, and the conflict is not related to authentication or cluster membership.

Full explanation →

122

MCQeasy

You are troubleshooting a node that is in 'NotReady' state. Which command should you use to check the kubelet logs for errors?

A.journalctl -u kubelet

B.journalctl -u docker

C.journalctl -u kube-apiserver

D.journalctl -u kube-controller-manager

AnswerA

journalctl -u kubelet displays the logs for the kubelet service, which is the primary source for troubleshooting node issues.

Why this answer

Option A is correct. The kubelet logs can be viewed using 'journalctl -u kubelet'. Option B is used for system logs, not kubelet-specific.

Option C checks kube-apiserver logs. Option D checks kube-controller-manager logs.

Full explanation →

123

MCQmedium

A new StorageClass 'fast' is created with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but no pod consumes it. What is the state of the PVC immediately after creation?

A.Bound

B.Pending

C.Lost

D.The PVC will not be created

AnswerB

The PVC will be in Pending state until a pod consumes it, at which point the volume is provisioned and bound.

Why this answer

Option B is correct: When volumeBindingMode is WaitForFirstConsumer, the PVC remains in 'Pending' until a pod using it is scheduled. The volume is not provisioned until a consumer exists. Option A would be true for Immediate mode.

Option C is incorrect because the PVC does not fail. Option D is incorrect because the PVC is created but not bound.

Full explanation →

124

Multi-Selectmedium

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Select 2 answers

A.Restart all containers on the node

B.Check the kubelet service logs using 'journalctl -u kubelet'

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

D.Check kube-proxy configuration

E.Verify the network plugin (e.g., Calico, Flannel) pods are running

AnswersB, E

Kubelet logs often indicate why the node is NotReady.

Why this answer

Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (restarting containers) is not relevant.

Option E (checking kube-proxy) is for service connectivity, not node readiness.

Full explanation →

125

MCQeasy

Which resource is used to configure TLS termination and path-based routing for HTTP(S) traffic into a cluster?

A.Ingress

B.Service

C.NetworkPolicy

D.Gateway

AnswerA

Ingress provides HTTP routing, TLS termination, and path-based rules.

Why this answer

An Ingress resource provides HTTP and HTTPS routing to services within a Kubernetes cluster, enabling TLS termination and path-based routing. It acts as a layer 7 load balancer, directing external traffic to the appropriate backend Service based on hostnames and paths defined in its rules.

Exam trap

CNCF often tests the distinction between Ingress and Service, where candidates mistakenly think a Service can handle TLS termination or path-based routing, but a Service only provides layer 4 load balancing without HTTP awareness.

How to eliminate wrong answers

Option B is wrong because a Service is a layer 4 abstraction that provides stable network endpoints for pods, but it does not support TLS termination or path-based routing; those functions require a higher-level resource. Option C is wrong because a NetworkPolicy controls ingress and egress traffic at the IP address or port level (layer 3/4) using pod selectors and CIDR rules, not HTTP path or TLS configuration. Option D is wrong because a Gateway is a newer, more advanced API (part of the Gateway API project) that can handle TLS and routing, but it is not the standard resource used for TLS termination and path-based routing in the CKA exam; the exam focuses on the traditional Ingress resource.

Full explanation →

126

MCQeasy

You see events like 'Failed to pull image' when running 'kubectl get events'. Which command can you use to get more detailed information about a specific pod's events?

A.kubectl get pod <pod-name> -o yaml

B.kubectl top pod <pod-name>

C.kubectl describe pod <pod-name>

D.kubectl logs <pod-name>

AnswerC

'kubectl describe pod' includes a section for Events that shows recent events for that pod, such as failed pulls.

Why this answer

'kubectl describe pod' shows events related to the pod, including pull failures.

Full explanation →

127

MCQmedium

You are preparing to upgrade a Kubernetes cluster from v1.27 to v1.28 using kubeadm. What is the correct order of operations for upgrading the control plane nodes?

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

B.Upgrade the first control plane node, then upgrade the remaining control plane nodes, then upgrade worker nodes.

C.Upgrade all nodes simultaneously by running kubeadm upgrade apply on all nodes at once.

D.Upgrade worker nodes, then upgrade the control plane nodes, then drain the worker nodes.

AnswerB

This is the standard kubeadm upgrade procedure: control plane first, then workers.

Why this answer

Option B is correct because the recommended upgrade order for a kubeadm-managed cluster is to upgrade the first control plane node (using `kubeadm upgrade apply`), then the remaining control plane nodes (using `kubeadm upgrade node`), and finally the worker nodes. This ensures the cluster's control plane components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) are updated first, maintaining cluster stability and API server availability during the process.

Exam trap

The trap here is that candidates may think upgrading all nodes simultaneously is faster or that worker nodes should be upgraded first to avoid downtime, but the CKA expects strict adherence to the kubeadm upgrade workflow where control plane nodes must be upgraded before worker nodes.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before control plane nodes can cause incompatibility between the newer kubelet versions and the older kube-apiserver, leading to node registration or API communication failures. Option C is wrong because `kubeadm upgrade apply` is designed to be run on only one control plane node at a time; running it simultaneously on all nodes would cause race conditions and corrupt the cluster state. Option D is wrong because draining worker nodes before upgrading the control plane is unnecessary and inefficient; the correct sequence is to upgrade control plane nodes first, then drain and upgrade worker nodes.

Full explanation →

128

MCQmedium

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

A.The nodes are all in NotReady state

B.The pod does not tolerate the taints on the available nodes

C.The pod requires at least 2 nodes

D.The pod has insufficient resources

AnswerB

Taints cause pods without matching tolerations to remain unscheduled.

Why this answer

The pod cannot tolerate the taints. One node has a custom taint, another is unreachable.

Full explanation →

129

Multi-Selecthard

Which THREE of the following are valid steps to enable audit logging in a Kubernetes cluster?

Select 3 answers

A.Store the audit policy in a ConfigMap and reference it via --audit-policy-configmap.

B.Create an audit policy file defining what events to log.

C.Add the --audit-log-path flag to the kube-apiserver.

D.Restart the kubelet on the control plane node.

E.Mount the audit policy file into the kube-apiserver container.

AnswersB, C, E

The policy file is required.

Why this answer

Option B is correct because audit logging in Kubernetes requires an audit policy file that defines which events (e.g., RequestResponse, Metadata) should be logged. This policy file must be created and then passed to the kube-apiserver via the --audit-policy-file flag. Without a policy file, the apiserver will not know what to log, even if other flags are set.

Exam trap

The trap here is that candidates may confuse the --audit-policy-configmap option (which does not exist) with the valid --audit-policy-file flag, or think that restarting the kubelet is necessary for apiserver changes, when in fact the kube-apiserver is a static Pod managed by the kubelet but its configuration is independent.

Full explanation →

130

MCQmedium

You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. The output shows 'active (running)'. What should you check NEXT?

A.Check if the kubelet is registered with the API server using 'kubectl get cs'

B.Check the kubelet logs with 'journalctl -u kubelet' for errors

C.Restart the kubelet service

D.Check if the node has sufficient disk space

AnswerB

Why this answer

Even if kubelet is running, it may have errors. Journalctl shows detailed logs to diagnose why the node is NotReady.

Full explanation →

131

Multi-Selecteasy

Which TWO of the following are valid methods to expose ConfigMap data to pods?

Select 2 answers

A.As environment variables

B.As a Kubernetes Service

C.As a container command argument

D.As a Pod annotation

E.As a volume mount

AnswersA, E

Using configMapKeyRef in env.

Why this answer

Option A is correct because ConfigMap data can be injected into a pod as environment variables using the `envFrom` or `env` field in the pod spec, referencing the ConfigMap name and keys. This allows the pod to consume configuration values as standard environment variables, which are accessible to the container runtime at process startup.

Exam trap

The trap here is that candidates may confuse 'exposing data to pods' with 'using data in pod definitions,' leading them to select command arguments (option C) as a direct method, when in fact command arguments require an intermediate exposure method like environment variables or volume mounts to supply the ConfigMap values.

Full explanation →

132

MCQeasy

What is the default port for the Kubernetes API server?

A.10250

B.8080

C.2379

D.6443

AnswerD

The API server listens on port 6443 by default for secure HTTPS connections.

Why this answer

The Kubernetes API server defaults to port 6443 for secure HTTPS traffic. This is the standard port used by kubectl and other clients to communicate with the control plane over TLS-encrypted connections, as defined in the Kubernetes documentation and default kube-apiserver configuration.

Exam trap

The trap here is that candidates often confuse the deprecated insecure port 8080 with the default secure port 6443, especially if they have experience with older Kubernetes versions or minikube setups that might expose port 8080 locally.

How to eliminate wrong answers

Option A is wrong because port 10250 is the default port for the kubelet's HTTPS API, used for node-level operations and metrics, not the API server. Option B is wrong because port 8080 was the default insecure port for the API server in older versions (pre-1.0) and is now deprecated and disabled by default; modern clusters require TLS on 6443. Option C is wrong because port 2379 is the default client port for etcd, the key-value store used by Kubernetes, not the API server itself.

Full explanation →

133

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.Increase the memory limit in the pod's container resource specification

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

D.Delete the namespace and redeploy all workloads

AnswerB

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

Why this answer

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

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

Full explanation →

134

MCQeasy

A pod is in CrashLoopBackOff state. Which command shows the last termination reason?

A.kubectl logs <pod>

B.kubectl describe pod <pod>

C.kubectl get pod <pod> -o yaml

D.kubectl top pod <pod>

AnswerB

Why this answer

The `kubectl describe pod <pod>` command displays detailed information about the pod, including the container state transitions and the last termination reason in the `Last State` field under the container status. This is the correct way to see why the container previously exited, which is essential for diagnosing a CrashLoopBackOff.

Exam trap

The trap here is that candidates often reach for `kubectl logs` first, not realizing that in a CrashLoopBackOff the container may have already restarted, so the logs from the last crash are not visible without the `--previous` flag, whereas `kubectl describe pod` directly shows the last termination reason.

Why the other options are wrong

A

Shows current logs, not termination reason.

C

Shows state but not human-readable termination reason.

D

Shows resource usage, not status.

Full explanation →

135

MCQmedium

You run `kubectl get endpoints my-service` and see no endpoints listed. The Service's selector matches labels on pods that are running. What is the most likely cause?

A.The kube-proxy is not running

B.The Service is in a different namespace

C.The pods are not passing their readiness probes

D.The Service type is ExternalName

AnswerC

Only pods with a Ready status are added to endpoints.

Why this answer

If the Service selector matches running pods but no endpoints appear, the pods might not be ready (i.e., readiness probes failing). Endpoints controller only includes pods that are Ready.

Full explanation →

136

MCQhard

A StatefulSet named 'web' uses volumeClaimTemplates to create a PVC named 'data' with storage class 'ssd'. The StatefulSet has 3 replicas. After scaling down to 2 replicas, what happens to the PVC of the third pod (web-2)?

A.The PVC is detached but not deleted

B.The PVC remains and must be manually deleted if not needed

C.The PVC's reclaim policy determines its fate

D.The PVC is automatically deleted along with the pod

AnswerB

PVCs are retained to preserve data. The admin must manually delete them.

Why this answer

StatefulSet does not delete PVCs when scaling down to prevent data loss. The PVC remains until manually deleted.

Full explanation →

137

MCQeasy

Which command initializes a Kubernetes control plane node using kubeadm?

A.kubeadm create

B.kubeadm setup

C.kubeadm start

D.kubeadm init

AnswerD

kubeadm init initializes the control plane.

Why this answer

Option D is correct because `kubeadm init` is the specific command used to bootstrap and initialize a Kubernetes control plane node. It performs pre-flight checks, generates certificates, creates the static Pod manifests for core control plane components (API server, controller manager, scheduler, etcd), and configures the admin kubeconfig file. This is the standard kubeadm workflow for setting up a new cluster.

Exam trap

The trap here is that candidates may confuse the generic 'init' verb with other common system administration commands like 'start' or 'setup', or they may mistakenly think 'create' is a valid kubeadm subcommand because other tools (e.g., `kubectl create`) use that verb.

How to eliminate wrong answers

Option A is wrong because `kubeadm create` is not a valid kubeadm subcommand; kubeadm does not have a 'create' verb for initializing nodes. Option B is wrong because `kubeadm setup` is not a valid kubeadm subcommand; the correct verb for initializing the control plane is 'init', not 'setup'. Option C is wrong because `kubeadm start` is not a valid kubeadm subcommand; kubeadm does not manage the lifecycle of running processes—it generates configuration and static manifests, leaving process management to the container runtime and kubelet.

Full explanation →

138

MCQhard

You create a StorageClass with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but remains in 'Pending' state. The PVC expects a node with label 'disktype=ssd'. A suitable node exists. What is the MOST likely reason the PVC is still Pending?

A.The node selector on the PVC is incorrect.

B.The PVC requests a storage size larger than available.

C.No pod has been created that uses this PVC.

D.The persistentVolumeReclaimPolicy is set to Retain.

AnswerC

WaitForFirstConsumer delays binding until a pod consumes the PVC.

Why this answer

With WaitForFirstConsumer, the volume is not provisioned until a pod using the PVC is scheduled. The PVC will remain Pending until a pod references it.

Full explanation →

139

Multi-Selecthard

Which THREE are valid methods to provide authentication to the Kubernetes API server? (Select three.)

Select 3 answers

A.Username and password

B.Client certificates

C.ServiceAccount bearer tokens

D.Static token file

E.SSH keys

AnswersB, C, D

X509 client certificates are a common authentication method.

Why this answer

Client certificates are a valid authentication method for the Kubernetes API server. The API server can be configured with the `--client-ca-file` flag to trust a Certificate Authority (CA), and then clients present a TLS certificate signed by that CA to authenticate. This is a common and secure method for user and component authentication.

Exam trap

The trap here is that candidates may confuse SSH keys (used for node-level access) with client certificates or tokens used for API server authentication, or mistakenly think username/password is still a supported method in current Kubernetes versions.

Full explanation →

140

MCQmedium

A NetworkPolicy allows ingress from pods with label 'role: frontend'. Which field is used to select those pods?

A.from.podSelector

B.spec.podSelector

C.ingress.podSelector

D.to.podSelector

AnswerA

Correct: podSelector in the from array selects source pods.

Why this answer

In the ingress rule, `from` specifies sources. Within `from`, `podSelector` selects pods in the same namespace with matching labels.

Full explanation →

141

MCQhard

Refer to the exhibit. An etcd pod on the master node shows repeated rejected connections from node2 (192.168.1.102) and node3 (192.168.1.103). The error indicates non-TLS traffic. What is the most likely cause?

A.The API server is using an incorrect etcd endpoint.

B.The etcd cluster is not configured for TLS, but clients are using TLS.

C.The etcd pod is not using the correct certificate authority.

D.Kube-proxy on node2 and node3 is incorrectly configured to connect directly to etcd using HTTP instead of HTTPS.

AnswerD

Correct. The error from nodes 2 and 3 suggests they are trying to connect to etcd without TLS. Since they are worker nodes, likely kube-proxy or kubelet is misconfigured to reach etcd directly.

Why this answer

The error 'first record does not look like a TLS handshake' means that non-TLS traffic is being sent to etcd's TLS-enabled port. In Kubernetes, components like kube-apiserver communicate with etcd over TLS. But kube-proxy or other components might be sending plain HTTP to the etcd client port.

The fact that node2 and node3 are worker nodes (no control-plane role) suggests that kube-proxy or kubelet is misconfigured to connect to etcd directly instead of via the API server.

Full explanation →

142

MCQeasy

A pod is in CrashLoopBackOff state. Which command should you use to see the logs of the previous instance?

A.kubectl logs <pod-name>

B.kubectl logs -p <pod-name>

C.kubectl describe pod <pod-name>

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

AnswerB

Why this answer

When a pod is in CrashLoopBackOff state, the current container instance has crashed and Kubernetes is restarting it. The `-p` flag (or `--previous`) in `kubectl logs` retrieves logs from the previous terminated container instance, which contains the crash output. Option B is correct because `kubectl logs -p <pod-name>` is the exact syntax to view logs of the previous instance.

Exam trap

The trap here is that candidates confuse `kubectl logs` with `kubectl describe pod` for viewing crash logs, or they forget the `-p` flag and assume the current logs will show the crash, when in fact the crash output is only in the previous instance's logs.

Why the other options are wrong

A

Shows current container logs, not previous.

C

Describes pod status but does not show logs.

D

Flag is -p, not --previous.

Full explanation →

143

MCQmedium

You need to schedule a pod on a node with label 'disktype=ssd'. Which field should you add to the pod spec?

A.nodeSelector

B.tolerations

C.nodeName

D.affinity.nodeAffinity

AnswerA

nodeSelector with key disktype and value ssd schedules the pod on matching nodes.

Why this answer

The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes that have a specific label. By setting `nodeSelector` with `disktype: ssd`, the scheduler will only consider nodes that have the label `disktype=ssd` for placement. This is a hard constraint that does not require any additional configuration on the nodes.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` or `tolerations`, thinking that `nodeAffinity` is always required for label-based scheduling, or that `tolerations` can select nodes by labels, when in fact `nodeSelector` is the simplest and correct field for a single label match.

How to eliminate wrong answers

Option B (tolerations) is wrong because tolerations allow a Pod to be scheduled on nodes that have matching taints, but they do not select nodes based on labels; they are used to bypass taint restrictions, not to enforce label-based scheduling. Option C (nodeName) is wrong because `nodeName` directly assigns the Pod to a specific node by name, bypassing the scheduler entirely and ignoring any label-based selection; it is not a flexible scheduling constraint. Option D (affinity.nodeAffinity) is wrong because while `nodeAffinity` can also select nodes based on labels, it is a more advanced and complex feature that includes both required and preferred rules; for a simple label match like `disktype=ssd`, `nodeSelector` is the correct and minimal field to use.

Full explanation →

144

Multi-Selecteasy

Which TWO of the following are valid commands to check resource usage of pods?

Select 2 answers

A.kubectl top nodes

B.kubectl describe pods

C.kubectl top pod <pod-name>

D.kubectl get pods --watch

E.kubectl top pods

AnswersC, E

Shows resource usage for a specific pod.

Why this answer

Options A and E are correct. kubectl top pods and kubectl top pod <pod-name> display resource usage for pods. Option B is for details. Option C is for nodes.

Option D is for watching status.

Full explanation →

145

Multi-Selectmedium

Which TWO of the following are valid reclaim policies for a PersistentVolume? (Select TWO)

Select 2 answers

A.Retain

B.Delete

C.Recycle

D.Preserve

E.Archive

AnswersA, B

Retain keeps the volume data and the PV in Released state.

Why this answer

The valid reclaim policies in Kubernetes are Retain, Delete, and Recycle (deprecated). From the options, Retain and Delete are valid. Recycle is also valid but deprecated.

The question expects Retain and Delete as the most commonly used.

Full explanation →

146

MCQhard

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

A.Approve the pending CSR using 'kubectl certificate approve csr-node2'.

B.Run 'kubeadm join' again with the correct token.

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

D.Restart the kubelet on node2.

AnswerA

Correct. The CSR must be approved to allow the node to obtain a certificate and join the cluster.

Why this answer

When a new node joins, the kubelet creates a CSR for its client certificate. The CSR must be approved by an administrator (or automatically via a controller). Until approved, the node cannot authenticate and remains NotReady.

Full explanation →

147

MCQhard

You apply the following NetworkPolicy: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress ``` What is the result?

A.All traffic is allowed because no ingress/egress rules are specified

B.Only ingress traffic is denied; egress traffic is allowed

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

D.The policy is invalid because podSelector is empty

AnswerC

The policy selects all pods and denies all ingress and egress.

Why this answer

This policy selects all pods in the namespace and denies all ingress and egress traffic because no rules are defined. Option C is correct. Option A is for when no policy is applied.

Option B is wrong because egress is also denied. Option D is wrong because the policy applies to all pods.

Full explanation →

148

MCQmedium

A developer creates a YAML manifest for a pod that uses a PersistentVolumeClaim. The PVC requests 5Gi of storage but the only available PV has 10Gi. What will happen when the pod is created?

A.The PV will be resized to 5Gi to match the PVC.

B.The PVC will bind to the PV and the pod will run.

C.The PVC will not bind and the pod will remain Pending.

D.The PVC will bind but the pod will be OOMKilled.

AnswerB

A PVC can bind to a PV that has more storage than requested.

Why this answer

A PVC can bind to a PV with larger capacity as long as the PV meets all other requirements (access modes, etc.). The PVC will bind and the pod will run.

Full explanation →

149

MCQmedium

You have a Deployment with 5 replicas. During a rolling update, you want to ensure that at most 3 pods are unavailable at any time. Which field should you set in the Deployment's strategy?

A.replicas: 3

B.minReadySeconds: 3

C.maxUnavailable: 3

D.maxSurge: 3

AnswerC

maxUnavailable limits the number of pods that can be unavailable during update.

Why this answer

Option B is correct. The 'maxUnavailable' field specifies the maximum number of pods that can be unavailable during the rolling update. Setting it to 3 means at most 3 pods can be down at once.

Option A is incorrect because maxSurge specifies how many extra pods can be created above the desired count. Option C is incorrect because replicas is the desired number. Option D is incorrect because minReadySeconds affects readiness, not availability during update.

Full explanation →

150

MCQhard

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

A.Add a toleration for the control-plane taint.

B.Increase the number of replicas of the app to spread the pods.

C.Delete the existing pods of the same app to free up nodes.

D.Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.

AnswerD

Changing to preferred makes the rule a soft requirement, allowing the scheduler to place the pod even if the rule cannot be met.

Why this answer

The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Exam trap

The trap here is that candidates focus on the taint error (which is only one node) and mistakenly think adding a toleration will solve the problem, ignoring the more fundamental anti-affinity constraint that affects all three nodes.

How to eliminate wrong answers

Option A is wrong because the pod's event explicitly states '1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate', but the primary issue is that 3 nodes didn't match pod affinity/anti-affinity — adding a toleration for the control-plane taint would only address one node, not the anti-affinity constraint blocking all nodes. Option B is wrong because increasing replicas would create more pods of the same app, which would worsen the anti-affinity conflict by requiring even more nodes that don't have same-app pods, making scheduling harder. Option C is wrong because deleting existing pods of the same app would free up nodes for the pending pod, but this is a manual, disruptive workaround that doesn't fix the underlying scheduling policy; the correct solution is to adjust the anti-affinity rule to be a preference rather than a requirement.

Full explanation →

Page 2 of 14

All pages

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

Practice CKA by domain

Target a specific domain to shore up weak areas.

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

See all domains with question counts →