Knowledge + Practice

Certified Kubernetes Administrator CKA (CKA) — Questions 676–750

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

Take a mock exam Exam hub

Page 10 of 14

676

MCQmedium

You attempt to schedule a pod but it remains 'Pending'. 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) didn't match node selector.' What is the MOST likely cause?

A.A PersistentVolumeClaim is not bound

B.All nodes have insufficient memory or CPU

C.The nodes have taints that the pod does not tolerate

D.The pod's nodeSelector does not match any node labels

AnswerD

Node selector mismatch prevents the pod from being scheduled on any node.

Why this answer

Option A is correct. The error 'didn't match node selector' indicates that the pod has a nodeSelector that does not match any node's labels. Option B would show a different event (resource pressure).

Option C would show an event about taints. Option D (PVC not bound) would show a different event.

Full explanation →

677

Multi-Selecthard

Which THREE of the following are valid steps when restoring etcd from a snapshot using etcdctl?

Select 3 answers

A.Update the etcd configuration to point to the new data directory.

B.Run etcdctl snapshot save to create a backup.

C.Use --data-dir flag with snapshot restore to specify the destination.

D.Stop the etcd service or static Pod.

E.Run etcdctl snapshot restore to create a new data directory.

AnswersA, D, E

After restore, the etcd manifest or config must point to the new data directory.

Why this answer

Option A is correct because after restoring etcd from a snapshot, the restored data is placed into a new data directory (specified by --data-dir). The etcd configuration must be updated to point to this new directory so that the etcd service uses the restored data when it starts. Without this step, etcd would continue using the old data directory, ignoring the restored snapshot.

Exam trap

The trap here is that candidates confuse backup steps (snapshot save) with restore steps (snapshot restore), or think that simply using the --data-dir flag is a separate step rather than part of the restore command itself.

Full explanation →

678

MCQmedium

A DevOps team wants to ensure that a critical application Pod is always scheduled on a node that has SSD storage. They have labeled one node with 'disk=ssd'. Which scheduling approach should they use to guarantee this placement?

A.Set nodeName in the Pod spec to the node name.

B.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and a matchExpression for disk=ssd.

C.Add a toleration for a taint that the node has.

D.Add a nodeSelector with disk=ssd to the Pod spec.

AnswerD

nodeSelector is the simplest way to enforce scheduling on nodes with a specific label.

Why this answer

Option D is correct because a `nodeSelector` is the simplest and most direct way to guarantee that a Pod is scheduled only on nodes that have a specific label. By adding `nodeSelector: disk: ssd` to the Pod spec, Kubernetes will ensure the Pod is placed exclusively on nodes with the `disk=ssd` label, which matches the labeled node. This approach is straightforward and meets the requirement without additional complexity.

Exam trap

The trap here is that candidates often overcomplicate the solution by choosing `nodeAffinity` (option B) because it is more powerful, but the question asks for the simplest approach to guarantee placement, and `nodeSelector` is the correct and sufficient answer for a single label match.

How to eliminate wrong answers

Option A is wrong because `nodeName` bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not leverage the label-based selection; it also fails if the node name changes or is unknown. Option B is wrong because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` can also guarantee placement on labeled nodes, but it is more complex than necessary for this simple label match and is not the simplest approach; the question asks for the approach to 'guarantee this placement,' and while it works, `nodeSelector` is the canonical and simpler method. Option C is wrong because tolerations are used to allow Pods to be scheduled on tainted nodes, not to enforce placement on nodes with specific labels; they do not guarantee placement on a labeled node unless combined with other mechanisms like node affinity or nodeSelector.

Full explanation →

679

MCQmedium

A Job 'backup' uses the default restartPolicy. The pod completes successfully. What is the pod's phase?

A.Running

B.Succeeded

C.Completed

D.Terminated

AnswerB

Job pods that complete successfully enter Succeeded phase.

Why this answer

The default restartPolicy for a Job is 'Never'. When a Job pod completes successfully (exit code 0), Kubernetes sets the pod's phase to 'Succeeded'. This is defined in the Kubernetes API, where the pod phase reflects the lifecycle outcome of the container execution.

Exam trap

CNCF often tests the distinction between pod phases (Pending, Running, Succeeded, Failed, Unknown) and container states (Waiting, Running, Terminated), leading candidates to confuse 'Completed' or 'Terminated' with the correct pod phase 'Succeeded'.

How to eliminate wrong answers

Option A is wrong because 'Running' is a pod phase that indicates at least one container is still executing, not a completed state. Option C is wrong because 'Completed' is not a valid Kubernetes pod phase; the correct phase is 'Succeeded' as per the PodStatus API. Option D is wrong because 'Terminated' is not a pod phase; it is a container state within the container status, not the pod-level phase.

Full explanation →

680

MCQmedium

After creating a NetworkPolicy that selects pods with label 'role: db' and allows ingress on TCP port 3306 from pods with label 'role: api', you notice that pods with label 'role: db' are still reachable on port 3306 from pods without 'role: api' label. What is the most likely cause?

A.The NetworkPolicy is not in the same namespace as the pods.

B.The NetworkPolicy uses the wrong protocol.

C.The NetworkPolicy has an egress rule that overrides ingress.

D.The NetworkPolicy requires an explicit 'deny all' rule.

AnswerA

NetworkPolicy only applies within its namespace. If the policy is in a different namespace, it won't affect the pods.

Why this answer

NetworkPolicy is only effective if there is at least one policy selecting the pod; however, if no policy exists that matches, it defaults to allow. But here a policy exists, so it should restrict. The most likely cause is that the policy is missing a rule to explicitly deny other sources, but NetworkPolicy works by whitelisting: if a pod is selected by any policy, only traffic that matches an ingress rule is allowed.

So if the policy allows from 'role: api', then only those pods should be allowed. If other pods can still reach, the policy might not be applied correctly, e.g., wrong namespace. But the most common mistake is that the policy's podSelector does not match the pod's label.

Full explanation →

681

Multi-Selectmedium

Which THREE components are part of the Gateway API?

Select 3 answers

A.Gateway

B.Service

C.Ingress

D.HTTPRoute

E.GatewayClass

AnswersA, D, E

Correct. Gateway represents a point of entry.

Why this answer

Options A, B, and C are correct. Gateway API consists of GatewayClass, Gateway, HTTPRoute, etc. Service, Ingress, and NetworkPolicy are not part of Gateway API; they are separate resources.

Full explanation →

682

MCQeasy

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

A.ReadWriteMany (RWX)

B.ReadWriteOnce (RWO)

C.ReadWriteOncePod (RWOP)

D.ReadOnlyMany (ROX)

AnswerA

RWX allows multiple nodes to mount the volume as read-write.

Why this answer

ReadWriteMany (RWX) allows multiple pods on different nodes to mount the volume as read-write.

Full explanation →

683

Multi-Selectmedium

A Pod is in ImagePullBackOff state. Which of the following are valid troubleshooting steps? (Select two.)

Select 2 answers

A.Run `kubectl describe pod <pod-name>` to view events.

B.Run `kubeadm reset` on the node.

C.Check if the image tag exists in the container registry.

D.Increase the pod's resource limits.

AnswersA, C

Why this answer

A is correct because `kubectl describe pod <pod-name>` shows recent events, including the exact error message from the kubelet when it failed to pull the image (e.g., 'ImagePullBackOff', 'ErrImagePull', or 'Back-off pulling image'). This provides the first diagnostic clue, such as a typo in the image name or a registry authentication failure.

Exam trap

CNCF often tests the misconception that resource limits affect image pulling, but ImagePullBackOff is strictly a container image retrieval issue, not a resource scheduling or limit problem.

Why the other options are wrong

B

kubeadm reset reinitializes the node, unrelated to image pulls.

D

Resource limits don't affect image pulling.

Full explanation →

684

MCQhard

A newly created Service of type ClusterIP is not accessible from within the cluster. You exec into a pod and run 'curl http://service-name:80' but get 'Connection refused'. What is the most likely cause?

A.The service selector does not match pod labels

B.The backend pods are not ready

C.The service is not in the same namespace

D.The application inside the pod is not listening on the targetPort

AnswerD

Connection refused means the port is reached but no process is listening.

Why this answer

Connection refused indicates the application in the backend pods is not listening on the expected port, or the service's targetPort is wrong.

Full explanation →

685

MCQhard

You are managing a Kubernetes cluster with 3 worker nodes (node1, node2, node3). A stateful application named 'app-db' uses a StatefulSet with 3 replicas, each requiring a PersistentVolumeClaim (PVC) of 10Gi with access mode ReadWriteOnce. The cluster uses a StorageClass 'fast-ssd' with a CSI driver that provisions volumes on a shared SAN. The StorageClass has reclaim policy 'Delete' and volumeBindingMode 'WaitForFirstConsumer'. Recently, node1 failed and is unrecoverable. The pod running on node1 (app-db-0) is in 'Pending' state because its PVC is still bound to a PV that exists only on node1's local storage (the CSI driver incorrectly pinned the volume to node1). The other two pods (app-db-1 and app-db-2) are running fine. The application is critical and must be restored as soon as possible. You cannot recover node1. What is the best course of action to get app-db-0 running again?

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

B.Manually repair node1 and rejoin it to the cluster.

C.Delete only the pod app-db-0, and let the StatefulSet recreate it.

D.Delete the PVC and PV associated with app-db-0, and let the StatefulSet recreate the PVC and pod.

AnswerD

Deleting the PVC and PV allows the StatefulSet controller to create a new PVC and PV on a healthy node.

Why this answer

Option D is correct because the pod app-db-0 is stuck in 'Pending' due to its PVC being bound to a PV that is pinned to the failed node1. Deleting both the PVC and the PV allows the StatefulSet's controller to automatically recreate the PVC, which will trigger dynamic provisioning via the 'fast-ssd' StorageClass. With volumeBindingMode 'WaitForFirstConsumer', the new PV will be provisioned on a healthy node that can schedule the pod, resolving the node affinity issue.

Exam trap

The trap here is that candidates assume deleting only the pod (Option C) will force rescheduling, but they overlook that the PVC's binding to a node-specific PV persists, causing the new pod to remain unschedulable due to PV node affinity.

How to eliminate wrong answers

Option A is wrong because scaling the StatefulSet to 0 and back to 3 would delete all pods and PVCs, disrupting the running app-db-1 and app-db-2 unnecessarily, and the new PVC for app-db-0 would still be bound to the old PV if not explicitly deleted. Option B is wrong because node1 is unrecoverable and cannot be repaired, making this option infeasible. Option C is wrong because deleting only the pod does not address the underlying issue: the PVC is still bound to a PV that exists only on the failed node1, so the new pod will be scheduled to the same node (due to PV node affinity) and remain in 'Pending'.

Full explanation →

686

MCQhard

You have a Service 'my-svc' with ClusterIP None (headless). You create a StatefulSet with 3 replicas and a headless Service. How do you reach individual pods?

A.Use the pod DNS name: <pod-name>.my-svc.<namespace>.svc.cluster.local

B.Use the Service name 'my-svc' which will round-robin between pods

C.Use the Service's ClusterIP (None) to reach all pods

D.You cannot reach individual pods directly; you must use the Service name

AnswerA

This is the standard format for individual pod DNS with a headless Service.

Why this answer

With a headless Service, DNS returns the pod IPs as A/AAAA records. Pods are reachable via their individual DNS names: <pod-name>.<service-name>.<namespace>.svc.cluster.local.

Full explanation →

687

MCQhard

You are troubleshooting a connectivity issue between two pods in the same cluster. Pod A cannot reach Pod B's IP. Which command would you run from Pod A to test connectivity?

A.kubectl exec pod-a -- curl <pod-b-ip>

B.kubectl top pod pod-b

C.kubectl logs pod-b

D.kubectl describe pod-b

AnswerA

This executes curl inside pod-a to test connectivity to pod-b.

Why this answer

kubectl exec allows you to run commands inside a container. From there, you can use curl to test connectivity to another pod's IP.

Full explanation →

688

MCQhard

You are troubleshooting a DNS issue. From within a pod, you run 'nslookup kubernetes.default.svc.cluster.local' and get 'connection timed out; no servers could be reached'. What is the most likely cause?

A.The pod's /etc/resolv.conf has incorrect nameservers

B.The node's network plugin is misconfigured

C.The pod's DNS policy is set to 'None'

D.The kube-dns service is not running or is misconfigured

AnswerD

If the DNS service pod is down, no DNS resolution works.

Why this answer

DNS timeout indicates the pod cannot reach the DNS service (kube-dns or CoreDNS).

Full explanation →

689

MCQeasy

Which NetworkPolicy rule will allow ingress traffic from pods with label 'role: frontend' in the same namespace?

A.ingress: - from: - podSelector: matchLabels: role: frontend

B.ingress: - from: - ipBlock: cidr: 0.0.0.0/0

C.egress: - to: - podSelector: matchLabels: role: frontend

D.ingress: - from: - namespaceSelector: matchLabels: role: frontend

AnswerA

Correct ingress rule with podSelector.

Why this answer

A NetworkPolicy ingress rule uses 'from' with a podSelector to select source pods. The podSelector must match the label of the source pods.

Full explanation →

690

Multi-Selecteasy

Which TWO commands can be used to view logs for a pod?

Select 2 answers

A.kubectl exec my-pod -- cat /var/log/app.log

B.kubectl top pod my-pod

C.kubectl describe pod my-pod

D.kubectl logs my-pod

E.kubectl get pod my-pod -o yaml

AnswersC, D

Correct. Shows events and container status including last termination log.

Why this answer

kubectl logs and kubectl describe pod (which shows events and last state) are both useful for viewing log-related information.

Full explanation →

691

MCQmedium

A pod is in the 'Pending' state for a long time. You run 'kubectl describe pod pending-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, 3 node(s) had taint {node-role.kubernetes.io/control-plane: } that the pod didn't tolerate.' What is the MOST likely solution?

A.Remove the taint from the control-plane nodes

B.Delete the pod and recreate it

C.Increase the pod's resource requests

D.Add tolerations to the pod for the control-plane taint

AnswerD

The pod cannot be scheduled on control-plane nodes due to the taint. Adding a toleration allows the pod to be scheduled on those nodes.

Why this answer

Option A is correct. The pod lacks tolerations for the control-plane taint. Adding appropriate tolerations allows scheduling on those nodes.

Option B is irrelevant. Option C is not recommended. Option D does not address the root cause.

Full explanation →

692

MCQmedium

You need to drain a node 'node1' and ensure that pods are evicted gracefully. Which command should you use?

A.kubectl delete node node1

B.kubectl cordon node1

C.kubectl taint node node1 key=value:NoSchedule

D.kubectl drain node1

AnswerD

Why this answer

Option D is correct because `kubectl drain node1` safely evicts all pods from the node while respecting PodDisruptionBudgets (PDBs) and graceful termination periods. It cordons the node first (marking it unschedulable) and then evicts pods, ensuring that workloads are rescheduled on other nodes without disruption.

Exam trap

The trap here is that candidates often confuse `cordon` (which only prevents new pods) with `drain` (which evicts existing pods), leading them to select option B as a quick fix without understanding that existing workloads remain running.

How to eliminate wrong answers

Option A is wrong because `kubectl delete node node1` removes the node object from the cluster but does not evict pods gracefully; pods may be left orphaned or abruptly terminated. Option B is wrong because `kubectl cordon node1` only marks the node as unschedulable, preventing new pods from being scheduled, but does not evict existing pods. Option C is wrong because `kubectl taint node node1 key=value:NoSchedule` adds a taint that prevents future pod scheduling but does not evict currently running pods.

Full explanation →

693

MCQhard

You are performing a backup of etcd using the command: 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. You get an error: 'Error: context deadline exceeded'. What is the most likely cause?

A.The endpoint flag is missing or incorrect, causing the client to timeout trying to connect

B.The etcdctl version is incompatible with etcd

C.The etcd cluster is not running

D.The snapshot file already exists and is locked

AnswerA

Without specifying the --endpoints flag, the client may try to connect to localhost:2379 which might not be reachable, leading to timeout.

Why this answer

The error 'context deadline exceeded' indicates that the etcdctl client attempted to connect to the etcd endpoint but the request timed out before a connection could be established. This is most commonly caused by the --endpoints flag being omitted or pointing to an incorrect address (e.g., localhost:2379 instead of the actual etcd listener), so the client cannot reach the etcd server within the default timeout period.

Exam trap

The trap here is that candidates may assume the error is due to the cluster being down or a file lock, but the 'deadline exceeded' message specifically points to a network connectivity or endpoint misconfiguration issue, not a server-side unavailability or filesystem problem.

How to eliminate wrong answers

Option B is wrong because an incompatible etcdctl version typically produces a different error, such as 'etcdserver: api version mismatch' or 'rpc error: code = Unimplemented', not a context deadline exceeded. Option C is wrong because if the etcd cluster is not running, the client would receive a 'connection refused' error immediately, not a timeout after a deadline. Option D is wrong because a locked or existing snapshot file would cause a file write error (e.g., 'file exists' or 'permission denied'), not a network-level timeout error.

Full explanation →

694

MCQeasy

Which DNS record does CoreDNS create for a headless Service named 'headless-svc' in the namespace 'default'?

A.A records for each pod IP backing the Service

B.No DNS record

C.A CNAME record pointing to an external DNS

D.An A record for the Service IP (ClusterIP)

AnswerA

Headless Services enable DNS-based service discovery returning pod IPs.

Why this answer

For a headless Service (clusterIP: None), CoreDNS returns A/AAAA records for the pod IPs backing the Service, not the Service IP.

Full explanation →

695

MCQeasy

Which of the following is the default DNS name for a Service named 'api' in namespace 'production'?

A.api.production.cluster.local

B.api.production.svc.cluster.local

C.production.api.svc.cluster.local

D.api.svc.production.cluster.local

AnswerB

This is the standard format.

Why this answer

The default DNS name for a Service is <service>.<namespace>.svc.cluster.local.

Full explanation →

696

MCQhard

A pod is in Pending state. You run 'kubectl describe pod pending-pod' and see an event: '0/3 nodes are available: 3 Insufficient memory'. However, you believe there is enough memory across the cluster. What could be the issue?

A.The pod's memory request is higher than any node's allocatable memory

B.The cluster is using a resource quota that is exhausted

C.The pod's memory limit is set too low

D.The nodes have taints that the pod does not tolerate

AnswerA

The scheduler cannot place the pod if no node can meet the request.

Why this answer

Even if total memory is sufficient, individual nodes may not have enough memory to satisfy the pod's request. The pod's memory request might be higher than any single node's available memory.

Full explanation →

697

MCQmedium

You suspect that the kube-scheduler is not running. Which command checks the scheduler's health?

A.systemctl status kube-scheduler

B.kubectl get pods -n kube-system | grep scheduler

C.kubectl get componentstatuses

D.kubectl describe node

AnswerC

Why this answer

Option C is correct because `kubectl get componentstatuses` (or `cs`) queries the Kubernetes API server for the health of core control plane components, including the scheduler. The API server periodically performs a health check against each component and reports its status as Healthy or Unhealthy. This command directly shows whether the scheduler is reachable and responding, making it the appropriate diagnostic tool when you suspect the scheduler is down.

Exam trap

The trap here is that candidates confuse checking the scheduler's pod status (Option B) with checking its health endpoint, or they assume systemd commands (Option A) work in containerized environments, leading them to overlook the dedicated `componentstatuses` command that directly queries the scheduler's health via the API server.

How to eliminate wrong answers

Option A is wrong because `systemctl status kube-scheduler` is a systemd command that only works if the scheduler is running as a systemd service on the same node; in a typical CKA cluster (often kubeadm-deployed), the scheduler runs as a static pod or container, not a systemd service, so this command would fail or show no relevant output. Option B is wrong because `kubectl get pods -n kube-system | grep scheduler` checks for the scheduler pod's existence and running state, but if the scheduler is not running, the pod might still be listed as 'Pending' or 'CrashLoopBackOff', or the command might return nothing; more importantly, the question asks for a health check, not a pod listing, and componentstatuses provides a direct health endpoint check. Option D is wrong because `kubectl describe node` shows node-level conditions (e.g., memory pressure, disk pressure) and resource usage, but it does not report the health of the scheduler or any control plane component; it is used for node troubleshooting, not scheduler health.

Full explanation →

698

MCQmedium

An administrator runs 'kubectl cordon node1' and then 'kubectl drain node1 --ignore-daemonsets'. What is the effect on node1?

A.Node1 is marked as unschedulable and all pods except DaemonSets are evicted

B.Node1 is marked as unschedulable but no pods are evicted

C.New pods are scheduled onto node1 and existing pods are evicted

D.Node1 is marked as schedulable and all pods are evicted

AnswerA

Cordon marks unschedulable, drain evicts pods (excluding DaemonSets due to flag).

Why this answer

The `kubectl cordon node1` command marks node1 as unschedulable, preventing new pods from being scheduled onto it. The subsequent `kubectl drain node1 --ignore-daemonsets` command evicts all pods from node1 except DaemonSets (which are ignored because they are managed by the DaemonSet controller and typically need to run on every node). This combination makes node1 unschedulable and removes all non-DaemonSet pods, preparing the node for maintenance.

Exam trap

The trap here is that candidates often confuse `cordon` (which only marks the node unschedulable) with `drain` (which evicts pods), or mistakenly think `--ignore-daemonsets` means no pods are evicted at all, when in fact it only excludes DaemonSet pods from eviction.

How to eliminate wrong answers

Option B is wrong because the drain command with `--ignore-daemonsets` does evict pods (except DaemonSets), not just mark the node unschedulable. Option C is wrong because the cordon command marks the node as unschedulable, so new pods are not scheduled onto node1; additionally, the drain command evicts existing pods, not schedules new ones. Option D is wrong because cordon marks the node as unschedulable, not schedulable, and the drain command evicts all pods except DaemonSets, not all pods.

Full explanation →

699

Multi-Selectmedium

Which TWO of the following are correct methods to check the health of the kube-apiserver?

Select 2 answers

A.Run 'kubectl top nodes'

B.Run 'systemctl status kube-apiserver'

C.Run 'kubectl get pods -n kube-system -l component=kube-apiserver'

D.Run 'journalctl -u kubelet'

E.Run 'curl -k https://localhost:6443/healthz'

AnswersB, C

If the apiserver is run as a systemd service, systemctl shows its status.

Why this answer

The kube-apiserver exposes a health endpoint on the secure port (usually 6443). You can check its process status with systemctl or check the endpoint directly. kubectl get pods is for checking if the apiserver pod is running in a kubeadm cluster.

Full explanation →

700

MCQeasy

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

A.kubeadm init --pod-network-cidr=10.244.0.0/16

B.kubeadm init --cidr=10.244.0.0/16

C.kubeadm init --network-cidr=10.244.0.0/16

D.kubeadm init --service-cidr=10.244.0.0/16

AnswerA

This is the correct flag and value.

Why this answer

Option A is correct because `kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Exam trap

The trap here is confusing `--pod-network-cidr` with `--service-cidr` or inventing flags like `--cidr` or `--network-cidr`, leading candidates to pick options that either do not exist or configure the wrong network range.

How to eliminate wrong answers

Option B is wrong because `--cidr` is not a valid flag for `kubeadm init`; it is used by other tools like `kube-proxy` or `kubectl` but not for initializing the control plane. Option C is wrong because `--network-cidr` is not a recognized flag in kubeadm; the correct flag is `--pod-network-cidr`. Option D is wrong because `--service-cidr` specifies the CIDR for Kubernetes services (default 10.96.0.0/12), not the pod network; using it for pod CIDR would misconfigure the cluster.

Full explanation →

701

MCQmedium

A pod uses a PersistentVolumeClaim named 'claim-log'. The PVC is pending. You run 'kubectl describe pvc claim-log' and see the event: 'waiting for a volume to be created, either by external provisioner or manually'. The StorageClass 'standard' has provisioner: 'kubernetes.io/no-provisioner'. What is the most likely cause?

A.The StorageClass 'standard' does not have a dynamic provisioner configured

B.The StorageClass is missing the volumeBindingMode

C.The PVC's access mode is incompatible with the StorageClass

D.The PVC requires a larger storage size than any available PV

AnswerA

The provisioner 'kubernetes.io/no-provisioner' does not support dynamic provisioning, so a PV must be manually created.

Why this answer

The provisioner 'kubernetes.io/no-provisioner' indicates static provisioning only. Dynamic provisioning is not enabled, so the PVC waits for a pre-existing PV to match.

Full explanation →

702

MCQmedium

A cluster is running on a cloud provider that supports load balancers. An administrator needs to expose a service externally using a cloud load balancer. However, the service remains in 'Pending' state. The cloud provider requires the cluster to be configured with the correct cloud provider flag. Which kube-controller-manager flag is required for this integration?

A.--cloud-provider

B.--cloud-controller-manager

C.--configure-cloud-routes

D.--cloud-config

AnswerA

This flag enables the cloud provider integration.

Why this answer

The `--cloud-provider` flag on the kube-controller-manager tells Kubernetes which cloud provider integration to use (e.g., `aws`, `gce`, `azure`). Without this flag set to the correct provider, the cloud controller manager cannot provision a load balancer for a Service of type LoadBalancer, leaving it in 'Pending' state because the external IP allocation never completes.

Exam trap

The trap here is that candidates confuse `--cloud-provider` with `--cloud-config` or think `--cloud-controller-manager` is a flag, when in fact the cloud-controller-manager is a separate component that requires `--cloud-provider=external` on the kube-controller-manager to delegate control.

How to eliminate wrong answers

Option B is wrong because `--cloud-controller-manager` is not a flag for the kube-controller-manager; it is a separate binary (cloud-controller-manager) that runs as a pod or static pod when cloud provider integration is enabled. Option C is wrong because `--configure-cloud-routes` controls whether the controller manages cloud provider routing tables (e.g., for pod network CIDRs), not the provisioning of load balancers for Services. Option D is wrong because `--cloud-config` specifies the path to a cloud provider configuration file (e.g., for credentials or region), but it is used alongside `--cloud-provider` and does not by itself enable cloud provider integration.

Full explanation →

703

Multi-Selectmedium

You want to check resource usage of pods and nodes. Which TWO commands should you use?

Select 2 answers

A.kubectl top pod

B.kubectl top pods

C.kubectl top nodes

D.kubectl resource usage

E.kubectl top node

AnswersB, C

Shows CPU/memory usage of pods.

Why this answer

kubectl top pods (B) and kubectl top nodes (E) are the correct commands. The other options are incorrect command syntax.

Full explanation →

704

MCQmedium

You need to back up etcd data for a cluster with etcd running as a static Pod. Which command should you use?

A.kubectl cp etcd-master:/var/lib/etcd /backup/

B.etcdctl snapshot save /backup/snapshot.db

C.kubectl exec -n kube-system etcd-master -- etcdctl snapshot save /backup/snapshot.db

D.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/snapshot.db

AnswerD

Correct command with API version 3, endpoints, and certificate flags.

Why this answer

Option D is correct because it uses the `etcdctl` command with the required API version 3, specifies the etcd endpoint, and provides the necessary TLS certificates (CA, server cert, and key) to authenticate to the etcd server. When etcd runs as a static Pod, it uses TLS for client-server communication, so these flags are mandatory for a successful snapshot.

Exam trap

The trap here is that candidates often forget to include the TLS certificates and endpoint flags when using `etcdctl`, assuming the command will work with defaults, or they mistakenly think `kubectl cp` can produce a valid etcd backup.

How to eliminate wrong answers

Option A is wrong because `kubectl cp` copies files from a Pod's filesystem, but it cannot be used to take a consistent etcd snapshot; copying the data directory while etcd is running can result in a corrupted or inconsistent backup. Option B is wrong because it omits the `--endpoints` and TLS flags, so it will fail to connect to the secured etcd endpoint (which uses HTTPS on port 2379). Option C is wrong because it runs `etcdctl` inside the etcd container without specifying the endpoint or TLS certificates; the default `etcdctl` configuration inside the container may not have the correct environment or credentials, and the command will likely fail due to authentication errors.

Full explanation →

705

MCQmedium

A cluster administrator needs to create a PersistentVolume that can be mounted as a block device (not a filesystem) by a Pod. Which field in the PersistentVolume spec must be set to enable this?

A.persistentVolumeReclaimPolicy: Retain

B.volumeMode: Filesystem

C.accessModes: ReadWriteOnce

D.volumeMode: Block

AnswerD

volumeMode set to 'Block' makes the volume available as a raw block device.

Why this answer

The volumeMode field in PersistentVolume spec determines whether the volume is presented as a filesystem or a raw block device. Setting volumeMode: Block will make it a block device. The default is Filesystem.

Full explanation →

706

MCQhard

You have a kubeconfig file with multiple contexts. You want to temporarily switch to a different context for a single kubectl command. Which flag should you use?

A.--context

B.--user

C.--cluster

D.--kubeconfig

AnswerA

Overrides the current context for that command.

Why this answer

The `--context` flag allows you to override the current context from the kubeconfig file for a single kubectl command. This is the correct way to temporarily switch contexts without modifying the kubeconfig file's current-context field. The flag accepts the context name as defined in the kubeconfig's contexts array.

Exam trap

The trap here is that candidates confuse `--context` with `--kubeconfig` or `--cluster`, thinking they need to specify the file or cluster directly, when the correct approach is to use the context name that bundles cluster, user, and namespace together.

How to eliminate wrong answers

Option B is wrong because `--user` specifies the user credential to use for authentication, not the context; it does not change the cluster or namespace. Option C is wrong because `--cluster` specifies the cluster endpoint to target, but it does not include the associated user or namespace, so it cannot fully define a context. Option D is wrong because `--kubeconfig` specifies an alternative kubeconfig file to use, not a context switch within the current file.

Full explanation →

707

Multi-Selectmedium

Which TWO of the following are valid ways to set the namespace for a kubectl command?

Select 2 answers

A.kubectl config set-context --namespace=myns

B.kubectl config set-context $(kubectl config current-context) --namespace=myns

C.kubectl namespace myns

D.kubectl get pods --namespace=myns

E.export KUBE_NAMESPACE=myns

AnswersB, D

This updates the current context's namespace, affecting subsequent commands.

Why this answer

Option B is correct because `kubectl config set-context` with the current context explicitly updates the namespace for that context, making it the default for all subsequent `kubectl` commands without needing the `--namespace` flag. Option D is correct because the `--namespace` flag can be passed directly to any `kubectl` command to override the current context's namespace for that single invocation.

Exam trap

The trap here is that candidates may confuse `kubectl config set-context --namespace=myns` (which creates a malformed context) with the correct form that explicitly names the current context, or they may incorrectly assume a `kubectl namespace` command or a `KUBE_NAMESPACE` environment variable exists.

Full explanation →

708

MCQeasy

A Pod that was running fine is now showing 'OOMKilled' in its status. Which kubectl command would show you the memory limit and usage for the container?

A.kubectl top pod <pod>

B.kubectl describe pod <pod>

C.kubectl top node

D.kubectl logs <pod>

AnswerB

Shows both limits/requests and recent events like OOMKilled.

Why this answer

'kubectl describe pod' shows resource limits and requests. Option A shows live usage but not limits. Option C shows node usage.

Option D shows logs.

Full explanation →

709

MCQmedium

A pod named 'web-frontend' is in CrashLoopBackOff. You run 'kubectl logs web-frontend' and see: 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause and how should you fix it?

A.The NodePort is conflicting; change the service type to ClusterIP.

B.The container is missing an environment variable required for startup; add it via ConfigMap.

C.The container process is not terminating gracefully; add a preStop hook or use a proper init system to release the port.

D.The pod has insufficient memory; increase memory limits in the deployment.

AnswerC

The error shows port already in use, indicating the old process didn't release it.

Why this answer

The error 'address already in use' indicates the container process is trying to bind to port 8080, but that port is still held by a previous instance of the process that did not release it. This typically happens when the container process does not handle SIGTERM gracefully (e.g., it ignores the signal or takes too long to shut down), so Kubernetes kills it with SIGKILL, leaving the socket in a TIME_WAIT or lingering state. Adding a preStop hook or using a proper init system (like tini or a signal-aware wrapper) ensures the process releases the port before the container stops, preventing the crash loop.

Exam trap

The trap here is that candidates often confuse a port conflict error with a service misconfiguration (NodePort) or resource issue, when the real cause is a process lifecycle problem related to signal handling and socket cleanup.

How to eliminate wrong answers

Option A is wrong because a NodePort conflict would manifest as a service-level error (e.g., port allocation failure), not as a bind error inside the container's own process on 8080. Option B is wrong because a missing environment variable would cause a startup failure with a different error (e.g., 'unexpected EOF' or 'config not found'), not a TCP bind error. Option D is wrong because insufficient memory would produce an OOMKill event (visible in `kubectl describe pod` as 'OOMKilled'), not a bind error on a specific port.

Full explanation →

710

Multi-Selectmedium

Which TWO of the following are valid commands to view cluster events sorted by timestamp?

Select 2 answers

A.kubectl get events

B.kubectl get events --sort-by=.metadata.creationTimestamp

C.kubectl get events -w

D.kubectl get events --sort-by=.metadata.name

E.kubectl get events --all-namespaces

AnswersA, B

By default, events are sorted by last timestamp.

Why this answer

Options A and D are correct. 'kubectl get events' shows events sorted by last timestamp by default. 'kubectl get events --sort-by=.metadata.creationTimestamp' explicitly sorts by creation time. Option B is a valid command but not sorted. Option C sorts by name.

Option E is a valid command but not sorted.

Full explanation →

711

MCQeasy

Which command displays the expiration date of all certificates managed by kubeadm?

A.kubeadm certs check-expiration

B.kubeadm alpha certs check-expiration

C.kubeadm certs list

D.kubectl get certificates

AnswerA

This command shows expiration details for each certificate.

Why this answer

Option A is correct because `kubeadm certs check-expiration` is the dedicated command in kubeadm v1.15+ that inspects the expiration dates of all certificates managed by kubeadm, including those for the API server, kubelet, and etcd. It reads certificate files from `/etc/kubernetes/pki/` and displays their remaining validity period in a human-readable table.

Exam trap

The trap here is that candidates confuse `kubeadm` certificate management commands with `kubectl` CSR resources, or assume an outdated `alpha` subcommand is still valid, leading them to pick B or D instead of the correct A.

How to eliminate wrong answers

Option B is wrong because `kubeadm alpha certs check-expiration` was deprecated in kubeadm v1.15 and removed in v1.20; the `alpha` subcommand no longer exists in current versions, making this command invalid. Option C is wrong because `kubeadm certs list` is not a valid kubeadm subcommand; the correct verb is `check-expiration`, not `list`. Option D is wrong because `kubectl get certificates` targets Kubernetes CertificateSigningRequest (CSR) resources, not the static certificate files managed by kubeadm; it shows CSR status, not expiration dates of the actual X.509 certificates on disk.

Full explanation →

712

MCQmedium

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows the following event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate.' Which action would resolve the issue?

A.Run 'kubectl describe node node-name' on each node to check conditions

B.Run 'kubectl taint nodes node-name node-role.kubernetes.io/master:NoSchedule-' to remove the taint

C.Run 'kubectl cordon node-name' on the node with the master taint

D.Add tolerations to the pod spec matching the taints on the nodes

AnswerD

Adding tolerations allows the pod to be scheduled on nodes with those taints.

Why this answer

Option D is correct. The pod is not tolerating the taints on any node. To schedule the pod, you must add the corresponding tolerations to the pod spec.

Option A would remove all pods from the node, not solve the taint issue. Option B tolerates only one taint. Option C describes the node, but does not change the pod's tolerations.

Full explanation →

713

MCQhard

A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?

A.The PVC is not bound to a PV because no PV exists.

B.The CSI driver is not installed or malfunctioning.

C.The pod does not have the correct node selector.

D.The StorageClass uses 'Immediate' binding mode.

AnswerB

If the CSI driver fails, dynamic provisioning will not occur.

Why this answer

When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.

Exam trap

The trap here is that candidates may assume 'WaitForFirstConsumer' delays binding indefinitely or that a missing PV is the root cause, rather than recognizing that dynamic provisioning requires a functioning CSI driver to create the PV after scheduling.

How to eliminate wrong answers

Option A is wrong because dynamic provisioning creates a PV on demand; the absence of a pre-existing PV is expected and not a problem. Option C is wrong because the pod's node selector does not affect the CSI driver's ability to provision the PV; the issue is with the driver itself. Option D is wrong because the StorageClass explicitly uses 'WaitForFirstConsumer' binding mode, not 'Immediate', so this option describes a configuration that is not present.

Full explanation →

714

MCQmedium

A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?

A.kubectl describe node <node-name>

B.journalctl -u kubelet

C.kubectl logs kubelet -n kube-system

D.systemctl restart kubelet

AnswerB

journalctl -u kubelet shows the kubelet's systemd journal logs, which is the standard way to view kubelet logs.

Why this answer

Option B is correct. journalctl -u kubelet retrieves the kubelet's systemd journal logs, which is the standard method for troubleshooting kubelet issues. Option A is incorrect because kubectl logs is for pod containers. Option C provides node status but not detailed logs.

Option D restarts the service without showing logs.

Full explanation →

715

Multi-Selectmedium

Which TWO of the following are valid causes for a pod to be in CrashLoopBackOff?

Select 2 answers

A.The livenessProbe fails causing a restart

B.The container exits with a non-zero exit code

C.The node is out of memory

D.The image pull secret is missing

E.The container is using too much CPU

AnswersA, B

If the liveness probe fails repeatedly, the container is restarted and may enter CrashLoopBackOff.

Why this answer

CrashLoopBackOff occurs when a container exits repeatedly. Common causes include application errors and misconfigured probes.

Full explanation →

716

MCQmedium

An administrator notices that a pod using a PersistentVolumeClaim is stuck in 'Pending' state. The PVC is bound to a PV with the status 'Released'. What is the most likely cause?

A.The PV's reclaim policy is 'Retain' and the PV must be manually recycled.

B.The PV has a faulty disk and needs replacement.

C.The StorageClass has an incorrect provisioner.

D.The PV is not bound to any PVC.

AnswerA

Retain policy keeps the PV in Released state; it must be manually deleted or re-claimed.

Why this answer

A PVC stuck in 'Pending' means it cannot find a suitable PV to bind to. The PV is in 'Released' status, which indicates it was previously bound to a PVC that has since been deleted. With a 'Retain' reclaim policy, the PV is not automatically recycled or made available for reuse; the administrator must manually delete and recreate the PV to clear its claimRef and make it available again.

This manual intervention is required because the 'Retain' policy preserves the underlying storage and its data, leaving the PV in a 'Released' state that cannot be bound to a new PVC.

Exam trap

The trap here is that candidates often assume a 'Released' PV is automatically reusable or that the 'Pending' PVC is due to a provisioning or capacity issue, when in fact the 'Retain' policy requires manual cleanup of the claimRef to make the PV available for binding again.

How to eliminate wrong answers

Option B is wrong because a faulty disk would typically manifest as a PV in 'Failed' or 'Lost' status, not 'Released', and the PVC would remain 'Pending' due to the PV being unavailable, but the 'Released' status specifically indicates a prior binding was released, not a hardware fault. Option C is wrong because an incorrect StorageClass provisioner would prevent PVs from being dynamically provisioned, but the PV in question already exists and is bound to a PVC (as shown by its 'Released' status), so the issue is not with provisioning but with the PV's reclaim lifecycle. Option D is wrong because the PV is bound to a PVC (its claimRef is set), as evidenced by its 'Released' status, which only occurs after a PVC that was bound to it is deleted; an unbound PV would show 'Available' status.

Full explanation →

717

MCQmedium

A node in your cluster shows status 'NotReady'. You have SSH access to the node. What is the first command you should run to check the kubelet status?

A.systemctl status docker (or containerd)

B.cat /var/log/kubelet.log

C.systemctl status kubelet

D.journalctl -u kubelet

AnswerC

This directly checks the kubelet service status.

Why this answer

Correct answer is B. 'systemctl status kubelet' checks the kubelet service status. Option A checks the container runtime. Option C is for system logs, not service status.

Option D checks the kubelet log, but checking service status first is more direct.

Full explanation →

718

MCQhard

You need to back up etcd on a single control plane node. Which command correctly creates a snapshot?

A.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 snapshot save /backup/etcd-snapshot.db

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

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

D.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db

AnswerD

This is the correct command with API v3 and required certificates.

Why this answer

Option D is correct because it uses the required `ETCDCTL_API=3` environment variable and specifies the necessary TLS client certificates (`--cacert`, `--cert`, `--key`) to authenticate to the etcd server, which by default listens on `https://127.0.0.1:2379` with mutual TLS enabled. The `snapshot save` command creates a point-in-time backup of the etcd data store, essential for disaster recovery in a Kubernetes control plane.

Exam trap

The trap here is that candidates often forget the TLS certificates or the `ETCDCTL_API=3` variable, assuming a simple `etcdctl snapshot save` will work, but the CKA exam environment enforces secure connections requiring full authentication flags.

How to eliminate wrong answers

Option A is wrong because it omits the required TLS certificate flags (`--cacert`, `--cert`, `--key`), so the command will fail with a certificate verification error when connecting to the etcd server over HTTPS. Option B is wrong because `snapshot restore` is used to restore a snapshot to a new data directory, not to create a backup; it does not produce a snapshot file. Option C is wrong because it lacks both the `ETCDCTL_API=3` environment variable (which enables the v3 API) and the required TLS flags, and it does not specify the endpoint, so it defaults to the v2 API and will fail to connect.

Full explanation →

719

MCQeasy

Which component is responsible for maintaining network rules on each worker node to enable service discovery and load balancing?

A.kube-controller-manager

B.CoreDNS

C.kube-proxy

D.kubelet

AnswerC

kube-proxy implements the Service concept by maintaining network rules on nodes.

Why this answer

kube-proxy is the component responsible for maintaining network rules on each worker node. It implements the Kubernetes Service concept by managing IP tables or IPVS rules to route traffic to the correct Pods, enabling service discovery and load balancing across Pod endpoints.

Exam trap

The trap here is confusing the responsibility for DNS-based service discovery (CoreDNS) with the responsibility for network-level traffic routing and load balancing (kube-proxy), leading candidates to incorrectly select CoreDNS.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller loops (e.g., ReplicaSet, Node, Endpoint controllers) but does not directly manage per-node network rules or packet forwarding. Option B is wrong because CoreDNS provides service discovery via DNS name resolution (e.g., translating service names to ClusterIPs) but does not enforce network rules or perform load balancing of traffic. Option D is wrong because kubelet is the primary node agent that registers nodes, manages Pod lifecycle, and reports node status, but it does not handle network rule maintenance or traffic routing.

Full explanation →

720

MCQmedium

You want to expose an application running in the cluster on a public IP address. Which Service type should you use?

A.NodePort

B.LoadBalancer

C.ExternalName

D.ClusterIP

AnswerB

LoadBalancer provides an external load balancer with a public IP.

Why this answer

LoadBalancer provisions an external load balancer (e.g., in cloud) and assigns a public IP. NodePort exposes on node IPs but not necessarily public. ClusterIP is internal.

ExternalName maps to an external DNS name.

Full explanation →

721

Multi-Selecthard

You need to grant a ServiceAccount named 'monitor-sa' in namespace 'monitoring' the ability to read Pods and Services across all namespaces. Which TWO resources are needed? (Choose TWO.)

Select 2 answers

A.ClusterRoleBinding binding the ClusterRole to the ServiceAccount

B.ServiceAccount token secret

C.ClusterRole with rules for pods and services

D.RoleBinding in each namespace

E.Role in the 'monitoring' namespace

AnswersA, C

ClusterRoleBinding binds the ClusterRole to subjects (like ServiceAccounts) across all namespaces.

Why this answer

A is correct because a ClusterRoleBinding grants cluster-scoped permissions to a subject (like a ServiceAccount) across all namespaces. Since the ServiceAccount 'monitor-sa' needs to read Pods and Services in every namespace, a ClusterRoleBinding is the appropriate resource to bind a ClusterRole to the ServiceAccount, avoiding the need for per-namespace RoleBindings.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide permissions if bound to a ClusterRole, but a RoleBinding only applies to the namespace it is created in, not across all namespaces.

Full explanation →

722

Multi-Selecthard

Which THREE of the following are true about NetworkPolicy? (Select THREE.)

Select 3 answers

A.NetworkPolicy is a cluster-scoped resource

B.NetworkPolicy can only allow traffic, not deny

C.NetworkPolicy requires a CNI plugin that supports it

D.If no NetworkPolicy selects a pod, traffic to that pod is allowed

E.NetworkPolicy can be applied to a subset of pods using podSelector

AnswersC, D, E

Not all CNI plugins implement NetworkPolicy.

Why this answer

NetworkPolicy relies on the CNI plugin to enforce its rules. The Kubernetes API only stores the policy definition; the actual packet filtering is performed by the underlying network plugin (e.g., Calico, Cilium, Weave Net). Without a CNI plugin that supports NetworkPolicy, the policy objects are created but have no effect on traffic.

Exam trap

The trap here is that candidates often assume NetworkPolicy can explicitly deny traffic (like a firewall rule), but Kubernetes NetworkPolicy only supports allow rules; denial is implicit when a policy selects a pod and does not include a rule for that traffic.

Full explanation →

723

MCQeasy

You have a pod named 'web-pod' that is in a CrashLoopBackOff state. To examine the logs from the previous instance of the container, which command should you use?

A.kubectl logs web-pod --previous

B.kubectl exec web-pod -- cat /var/log/app.log

C.kubectl describe pod web-pod

D.kubectl logs web-pod

AnswerA

The --previous flag retrieves logs from the previous terminated container instance.

Why this answer

Option B is correct. kubectl logs --previous retrieves logs from the previous container instance, which is crucial for debugging CrashLoopBackOff. Option A shows current logs but the container may have restarted. Options C and D do not retrieve previous logs.

Full explanation →

724

Multi-Selecthard

Which THREE of the following are characteristics of a StatefulSet's volumeClaimTemplates?

Select 3 answers

A.When a Pod is deleted, the corresponding PVC is automatically deleted.

B.The PVCs are created in the same namespace as the StatefulSet.

C.Each PVC gets a unique name derived from the template name and the Pod ordinal.

D.They are used to automatically create PersistentVolumeClaims for each replica.

E.The volumeClaimTemplate must specify a storageClassName.

AnswersB, C, D

PVCs are namespace-scoped and are created in the StatefulSet's namespace.

Why this answer

VolumeClaimTemplates in a StatefulSet are used to automatically create PVCs for each Pod replica. Each PVC gets a unique name based on the template name and pod ordinal. The PVC is created before the Pod and is deleted when the Pod is deleted? Actually, by default, when a StatefulSet is scaled down, the PVC is not deleted; it is retained.

The PVC is also not automatically created based on pod index? It is created for each replica. The PVCs are created in the same namespace as the StatefulSet. So correct statements: A: They are used to automatically create PersistentVolumeClaims.

B: Each PVC gets a unique name derived from the template name and pod ordinal. D: The PVCs are created in the same namespace as the StatefulSet. INCORRECT: C: When a Pod is deleted, the corresponding PVC is automatically deleted (false; PVCs are retained by default).

E: The volumeClaimTemplate must have a storage class specified (false; it can omit storageClassName to use default).

Full explanation →

725

MCQhard

A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?

A.The kubelet is not configured with the correct node IP.

B.The new node does not have enough disk space for container images.

C.There is a network connectivity issue between the new node and the control plane.

D.The API server is overloaded and cannot handle the node update request.

AnswerC

Context deadline exceeded indicates timeout reaching the API server.

Why this answer

The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.

Exam trap

The trap here is that candidates often confuse 'context deadline exceeded' with a resource exhaustion issue (like disk or memory) or a kubelet configuration error, when in fact it is a classic symptom of network connectivity failure between the node and the control plane.

How to eliminate wrong answers

Option A is wrong because an incorrect node IP would cause the kubelet to bind to the wrong interface, but the error 'context deadline exceeded' specifically points to a timeout in reaching the API server, not a local binding issue. Option B is wrong because insufficient disk space for container images would manifest as image pull failures or eviction, not as a kubelet status update timeout. Option D is wrong because an overloaded API server would affect all nodes and clients, not just a single new node, and the error message is specific to the kubelet's update request timing out, not a server-side rejection.

Full explanation →

726

MCQmedium

You have a Deployment with 4 replicas. During a rolling update, you want to ensure that only 2 pods are unavailable at any given time. Which field should you set in the Deployment spec?

A.spec.strategy.rollingUpdate.maxUnavailable

B.spec.updateStrategy.rollingUpdate.maxUnavailable

C.spec.replicas.maxUnavailable

D.spec.strategy.rollingUpdate.maxSurge

AnswerA

maxUnavailable sets the maximum number of pods that can be unavailable during the update. Setting it to 2 ensures at most 2 pods are unavailable.

Why this answer

Option B is correct. The 'maxUnavailable' field specifies the maximum number of pods that can be unavailable during a rolling update. Setting it to 2 ensures that at most 2 pods are down at any time.

Option A is incorrect because 'maxSurge' controls how many extra pods can be created above the desired count. Option C is for StatefulSets, not Deployments. Option D is not a valid field.

Full explanation →

727

MCQeasy

Which of the following is a valid CSI (Container Storage Interface) driver operation in Kubernetes?

A.CreateVolume

B.CreateDeployment

C.CreateService

D.CreatePod

AnswerA

CreateVolume is a CSI operation used to create a new volume.

Why this answer

CSI drivers in Kubernetes allow storage providers to develop custom storage solutions that integrate with Kubernetes using the CSI interface. Valid operations include provisioning, attaching, mounting, etc. Among the options, 'CreateVolume' is a standard CSI operation that is part of the CSI specification and is used by Kubernetes to dynamically provision volumes.

Full explanation →

728

MCQmedium

An application requires that a pod runs on a node that has a GPU. The cluster has nodes with and without GPUs labeled as 'gpu=true' and 'gpu=false'. Which scheduling method should be used?

A.Taint on non-GPU nodes and toleration on the pod

B.Pod affinity to prefer GPU nodes

C.Node affinity with a requiredDuringSchedulingIgnoredDuringExecution rule for gpu=true

D.nodeSelector with gpu=true

AnswerD

nodeSelector directly matches the label gpu=true.

Why this answer

Option D is correct because `nodeSelector` is the simplest and most direct way to force a pod to run only on nodes that have a specific label, such as `gpu=true`. This ensures the pod is scheduled exclusively on GPU-equipped nodes without requiring taints, tolerations, or complex affinity rules. The `nodeSelector` field in the pod spec matches against node labels at scheduling time, making it ideal for this straightforward requirement.

Exam trap

The trap here is that candidates often confuse taints/tolerations (which repel pods) with node affinity or nodeSelector (which attract pods to specific nodes), leading them to pick Option A when the requirement is to ensure a pod runs on a GPU node, not to prevent it from running on non-GPU nodes.

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes (or allow them to be scheduled on tainted nodes), not to attract pods to nodes with a specific label; they would prevent pods without the toleration from running on non-GPU nodes but do not actively ensure the pod lands on a GPU node. Option B is wrong because pod affinity is used to co-locate pods relative to each other (e.g., schedule this pod near another pod), not to match node labels like GPU availability. Option C is wrong because while node affinity with `requiredDuringSchedulingIgnoredDuringExecution` can achieve the same goal as `nodeSelector`, it is more complex and verbose for a simple label match; `nodeSelector` is the recommended approach for this exact use case per Kubernetes documentation.

Full explanation →

729

MCQeasy

A developer accidentally runs 'kubectl delete pvc data-claim'. What is the immediate effect on the PersistentVolume pv-data?

A.The PV pv-data is automatically deleted.

B.The PV pv-data remains Bound to the deleted PVC.

C.The PV pv-data immediately becomes Available and can be reused.

D.The PV pv-data enters the Released state and is not deleted.

AnswerD

Retain policy causes Released status.

Why this answer

When a PVC is deleted, the associated PV enters the 'Released' state, not 'Available'. This is because the PV still contains data from the previous claim (the retain policy is 'Retain' by default), and Kubernetes does not automatically delete or reuse it. The PV remains in 'Released' until an administrator manually clears the claimRef or deletes the PV.

Exam trap

The trap here is that candidates assume the PV's reclaim policy is 'Delete' by default, or that deleting a PVC automatically makes the PV 'Available' for reuse, when in fact the default policy is 'Retain' and the PV enters 'Released'.

How to eliminate wrong answers

Option A is wrong because the PV is not automatically deleted when the PVC is deleted; the PV's lifecycle is independent and depends on its reclaim policy (default is 'Retain'). Option B is wrong because the PV does not remain 'Bound' to the deleted PVC; the binding is removed, and the PV transitions to 'Released'. Option C is wrong because the PV does not immediately become 'Available'; it enters 'Released' and cannot be reused until the claimRef is manually cleared by an administrator.

Full explanation →

730

Multi-Selectmedium

Which THREE statements about StorageClasses are true?

Select 3 answers

A.Only cluster administrators can create StorageClasses.

B.StorageClasses are namespaced resources.

C.A StorageClass can specify a provisioner to enable dynamic volume provisioning.

D.The volumeBindingMode in a StorageClass can be set to 'WaitForFirstConsumer' to delay PV creation until a pod uses the PVC.

E.A StorageClass can set the reclaim policy for dynamically provisioned PVs.

AnswersC, D, E

The provisioner field defines which volume plugin to use for provisioning PVs.

Why this answer

StorageClasses define a provisioner for dynamic provisioning (A), can set the reclaim policy (B), and can have volumeBindingMode set to WaitForFirstConsumer (C). They are not restricted to cluster admins only; users can create them if RBAC allows (D is false). StorageClasses are cluster-scoped (E is false).

Full explanation →

731

MCQeasy

A user reports that a pod is stuck in 'ContainerCreating' state. Which command would you run first to diagnose the issue?

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl get events --watch

D.kubectl exec -it <pod-name> -- /bin/sh

AnswerB

Why this answer

The 'ContainerCreating' state indicates the pod has been scheduled but the container runtime is failing to start the container. `kubectl describe pod` provides detailed events, status conditions, and error messages from the kubelet, such as image pull failures, volume mount errors, or CNI plugin issues, which are the most direct source of diagnostic information for this state.

Exam trap

The trap here is that candidates often jump to `kubectl logs` thinking it shows startup errors, but logs are only available after the container's entrypoint has executed, not during container creation failures.

Why the other options are wrong

A

Logs require a running container; the pod is still ContainerCreating, so no logs exist.

C

This shows all cluster events, not specifically the pod's issue; it's less direct than describe pod.

D

Exec requires a running container; pod is not running.

Full explanation →

732

MCQeasy

You have multiple kubeconfig files. Which command merges them into a single config file?

A.kubectl config merge config1 config2 > merged-config

B.KUBECONFIG=config1:config2 kubectl config view --flatten > merged-config

C.cat config1 config2 > merged-config && kubectl config use-context merged-config

D.kubectl merge-config config1 config2

AnswerB

Why this answer

Option B is correct because the `KUBECONFIG` environment variable can accept a colon-separated list of kubeconfig files, and `kubectl config view --flatten` merges them into a single configuration, outputting the combined result to stdout, which can be redirected to a new file. This is the standard method for merging multiple kubeconfig files in Kubernetes.

Exam trap

The trap here is that candidates may assume a direct `kubectl` subcommand like `merge` exists, or that simple file concatenation works, but the CKA exam tests knowledge of the environment variable-based merge method as the only correct approach.

How to eliminate wrong answers

Option A is wrong because `kubectl config merge` is not a valid kubectl command; the correct approach uses `KUBECONFIG` and `kubectl config view --flatten`. Option C is wrong because simply concatenating config files with `cat` does not properly merge contexts, clusters, and users; it produces a malformed YAML file, and `kubectl config use-context` does not perform merging. Option D is wrong because `kubectl merge-config` is not a valid kubectl subcommand; no such command exists in the Kubernetes CLI.

Full explanation →

733

MCQeasy

You want to check the memory usage of nodes in your cluster. Which command should you use?

A.kubectl top nodes

B.kubectl describe nodes

C.kubectl get nodes -o wide

D.kubectl get --raw /api/v1/nodes

AnswerA

Why this answer

kubectl top nodes displays resource usage (CPU/memory) of nodes, provided Metrics Server is installed.

Full explanation →

734

Multi-Selecteasy

Which TWO of the following are valid commands to check the status of control plane components?

Select 2 answers

A.systemctl status kube-apiserver

B.kubectl get nodes

C.kubectl get pods -n kube-system

D.kubectl get events --all-namespaces

E.kubectl top nodes

AnswersA, C

On some clusters, control plane components run as systemd services, so this command checks their status.

Why this answer

Control plane components can be checked via kubectl (if running as pods) or systemctl (if running as services).

Full explanation →

735

MCQhard

You have a NetworkPolicy that denies all ingress traffic by default, and you want to allow traffic only from pods with label 'app: monitoring' in the same namespace. What should the policy spec look like?

A.ingress: - from: - ipBlock: cidr: 0.0.0.0/0

B.ingress: - from: - podSelector: matchLabels: app: monitoring - namespaceSelector: matchLabels: name: my-namespace

C.ingress: - from: - podSelector: matchLabels: app: monitoring

D.ingress: - from: - namespaceSelector: matchLabels: app: monitoring

AnswerC

This allows ingress from pods with label app: monitoring in the same namespace.

Why this answer

To allow ingress from pods with a specific label in the same namespace, you add an ingress rule with a podSelector. The default deny is implicit if no ingress rules exist, or you can explicitly set podSelector: {} to deny all. But since the question says 'denies all ingress traffic by default', you need to add an ingress rule that allows the desired pods.

Full explanation →

736

Multi-Selectmedium

Which TWO of the following are valid reasons for a pod to be in the Pending state? (Choose two)

Select 2 answers

A.The pod's PersistentVolumeClaim is not bound

B.Insufficient CPU or memory resources on any node

C.The pod's image name is incorrect

D.The pod's liveness probe is failing

E.The container command fails immediately

AnswersA, B

Why this answer

Pending means the pod has not been scheduled. Resource constraints and unbound PVCs prevent scheduling. Image errors cause ImagePullBackOff, not Pending.

Command failure and liveness probe failures cause CrashLoopBackOff or Running but not Ready.

Full explanation →

737

MCQmedium

An administrator runs 'kubectl get nodes' and sees that a worker node is in the 'Ready,SchedulingDisabled' state. Which command was most likely executed on that node?

A.kubectl drain node01

B.kubectl taint nodes node01 key=value:NoSchedule

C.kubectl cordon node01

D.kubectl uncordon node01

AnswerC

cordon marks the node as unschedulable.

Why this answer

The 'Ready,SchedulingDisabled' state indicates the node has been marked as unschedulable using the 'kubectl cordon' command. Cordon marks the node as unschedulable, preventing new pods from being scheduled onto it while existing pods continue running. This matches the observed state exactly.

Exam trap

The trap here is confusing 'cordon' with 'drain' — candidates often think 'drain' is required to see 'SchedulingDisabled', but 'cordon' alone produces that state without evicting pods.

How to eliminate wrong answers

Option A is wrong because 'kubectl drain' evicts all pods from the node and then marks it as unschedulable, resulting in a 'Ready,SchedulingDisabled' state only after pod eviction, but the question asks for the command that most likely produced the state without specifying pod eviction. Option B is wrong because 'kubectl taint' with 'NoSchedule' prevents scheduling based on tolerations but does not change the node's scheduling status to 'SchedulingDisabled'; the node would remain 'Ready' without the disabled suffix. Option D is wrong because 'kubectl uncordon' reverses the cordon effect, making the node schedulable again, which would show 'Ready' without 'SchedulingDisabled'.

Full explanation →

738

MCQmedium

You deploy a pod with resource limits but no requests. The pod gets OOMKilled. What is the most likely reason?

A.The pod's liveness probe is failing

B.The container's entrypoint command is invalid

C.The container tried to use more memory than the limit

D.The node does not have enough memory for the limit

AnswerC

OOMKilled occurs when memory usage exceeds the limit.

Why this answer

When a pod has a memory limit set but no memory request, the Linux kernel enforces the limit via cgroups. If the container's processes attempt to allocate more memory than the limit, the kernel's Out-Of-Memory (OOM) killer terminates the container, resulting in an OOMKilled status. This is the most direct cause of the OOMKilled event.

Exam trap

The trap here is that candidates often confuse OOMKilled with resource scheduling issues (Option D) or probe failures (Option A), but OOMKilled specifically indicates the container was terminated by the kernel for exceeding its memory limit, not for node-level insufficiency or health check failures.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe would cause the pod to be restarted due to probe failure, not an OOMKill; the pod status would show 'CrashLoopBackOff' or 'Error', not OOMKilled. Option B is wrong because an invalid entrypoint command would prevent the container from starting at all, resulting in a 'CrashLoopBackOff' or 'Init:Error' status, not an OOMKilled termination after the container had been running. Option D is wrong because if the node lacks enough memory for the limit, the pod would remain in 'Pending' state with an 'Insufficient memory' scheduling failure, not be OOMKilled after running.

Full explanation →

739

MCQhard

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

A.Increase the memory limit of the pod or add more worker nodes

B.Remove the taint from the control-plane node

C.Add a toleration for the control-plane taint to the pod spec

D.Set nodeSelector to schedule on control-plane nodes

AnswerA

Why this answer

The error indicates insufficient memory on worker nodes, not the taint issue. Adding memory or nodes resolves the scheduling failure.

Full explanation →

740

Multi-Selecthard

Which THREE components are part of the Gateway API resource model? (Select THREE)

Select 3 answers

A.Gateway

B.GatewayClass

C.LoadBalancer

D.HTTPRoute

E.Ingress

AnswersA, B, D

Gateway represents the instantiation of a gateway.

Why this answer

The Gateway API defines three core resource types: GatewayClass, Gateway, and HTTPRoute. Option A, C, and D are correct. Option B is from Ingress v1.

Option E is not a Gateway API resource (it's a service type).

Full explanation →

741

MCQmedium

A pod with an init container that runs a database migration fails. The init container exits with code 1. What is the pod's status?

A.Init:CrashLoopBackOff

B.Pending

C.Failed

D.Running

AnswerA

The init container is failing repeatedly, leading to CrashLoopBackOff state.

Why this answer

When an init container exits with a non-zero exit code (code 1), Kubernetes considers the init container to have failed. By default, the pod restarts the init container according to the pod's restart policy (which defaults to Always for pods, but init containers always restart on failure regardless of the pod's restart policy). This repeated failure and restart cycle places the pod in the Init:CrashLoopBackOff status, indicating that the init container is crashing in a loop.

Exam trap

The trap here is that candidates confuse the pod phase (Pending, Running, Failed) with the detailed pod status condition (Init:CrashLoopBackOff), and mistakenly choose 'Failed' thinking the init container failure ends the pod, not realizing Kubernetes will retry the init container automatically.

How to eliminate wrong answers

Option B (Pending) is wrong because the pod has already started executing its init containers; it is not stuck waiting for scheduling or image pull. Option C (Failed) is wrong because a pod enters the Failed phase only when all its containers have terminated and the pod will not be restarted (e.g., a non-init container with restart policy Never), but here the init container will be retried. Option D (Running) is wrong because the pod's init container has not completed successfully, so the pod's status cannot be Running; the pod remains in a waiting state until all init containers succeed.

Full explanation →

742

MCQhard

A cluster administrator is configuring a Pod to use a PersistentVolumeClaim (PVC) that is dynamically provisioned using a StorageClass with volumeBindingMode: WaitForFirstConsumer. The PVC is created before the Pod. When the Pod is created, which node will the PV be provisioned on?

A.The PV is provisioned immediately on the node specified in the StorageClass's allowedTopologies.

B.The node where the Pod is scheduled.

C.Any node in the cluster that has sufficient resources for the PV.

D.The control plane node.

AnswerB

With WaitForFirstConsumer, the PV is provisioned on the node that the pod is scheduled to, ensuring the PV is local to the pod.

Why this answer

WaitForFirstConsumer means the PV will not be provisioned until a pod using the PVC is scheduled. The PV is then provisioned on the node where the pod is scheduled. Since the PVC exists but no pod references it yet, the PV is not provisioned.

When the pod is created, the scheduler selects a node that meets the pod's resource requirements and constraints, and then the PV is provisioned on that node. So the PV is provisioned on the node where the pod is scheduled.

Full explanation →

743

MCQmedium

You run 'kubectl get pods' and see that a pod is in 'CrashLoopBackOff'. You want to examine the container's previous exit code. Which command provides this information?

A.kubectl get events

B.kubectl describe pod pod-name

C.kubectl logs pod-name --previous

D.kubectl logs pod-name

AnswerB

'kubectl describe pod' shows container status including last state's exit code.

Why this answer

Option B is correct. 'kubectl describe pod' shows the container state, including the last state's exit code. Option A shows current logs. Option C shows previous logs but not the exit code.

Option D shows events but not exit codes.

Full explanation →

744

Multi-Selecteasy

Which TWO commands are used to manage nodes in a cluster?

Select 2 answers

A.kubectl taint

B.kubectl cordon

C.kubectl delete node

D.kubectl drain

E.kubectl get nodes

AnswersB, D

Why this answer

B is correct because `kubectl cordon` marks a node as unschedulable, preventing new pods from being assigned to it while existing pods continue running. D is correct because `kubectl drain` safely evicts all pods from a node, optionally respecting PodDisruptionBudgets, and then marks the node as unschedulable. Both commands are essential for node maintenance and are directly used to manage node scheduling state in a cluster.

Exam trap

The trap here is that candidates confuse `kubectl taint` with node management commands, thinking it controls node scheduling directly, when in fact taints only affect pod placement through tolerations and do not prevent existing pods from running or being scheduled on the node.

Full explanation →

745

MCQmedium

A developer needs to create a Role that allows listing pods in the 'dev' namespace. Which YAML snippet correctly defines this Role?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-lister rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]

B.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-lister-binding namespace: dev subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-lister apiGroup: rbac.authorization.k8s.io

C.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-lister namespace: dev rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]

D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-lister rules: - apiGroups: [""] resources: ["pods"] verbs: ["get"]

AnswerC

This defines a Role in the dev namespace with list pods permission.

Why this answer

Option C is correct because it defines a Role (not ClusterRole) scoped to the 'dev' namespace with the 'list' verb on 'pods', which matches the requirement exactly. In Kubernetes RBAC, a Role grants permissions within a specific namespace, and the empty apiGroups string [""] refers to the core API group where pods reside.

Exam trap

The trap here is that candidates often confuse 'get' with 'list' or choose a ClusterRole thinking it can be used for namespace-scoped access, but the CKA exam tests precise understanding that a Role must be namespace-scoped and use the correct verb for the intended operation.

How to eliminate wrong answers

Option A is wrong because it defines a ClusterRole, which is cluster-scoped and not namespace-scoped; while a ClusterRole can be used to grant permissions across namespaces, the requirement specifically asks for a Role in the 'dev' namespace. Option B is wrong because it defines a RoleBinding, which binds a Role to a user but does not define the Role itself; the question asks for the Role definition, not the binding. Option D is wrong because it defines a Role with the verb 'get' instead of 'list'; 'get' allows retrieving a specific pod by name, but the requirement is to list pods, which requires the 'list' verb.

Full explanation →

746

Multi-Selectmedium

Which TWO of the following are valid steps to troubleshoot a pod that is in 'CrashLoopBackOff'?

Select 2 answers

A.Run 'kubectl exec -it pod-name -- /bin/bash' to inspect the container

B.Run 'kubectl logs pod-name --previous' to view logs from the previous crash

C.Run 'kubectl describe pod pod-name' to see events and state

D.Run 'kubectl rollout restart deployment/pod-name'

E.Run 'kubectl delete pod pod-name' to force restart

AnswersB, C

This retrieves logs from the crashed instance.

Why this answer

Correct answers are A and C. Checking logs and describing the pod are standard troubleshooting steps. B is not directly helpful.

D is not a troubleshooting step. E is not a command.

Full explanation →

747

MCQhard

An administrator needs to configure dynamic provisioning for persistent volumes using an external CSI driver. Which of the following is the correct approach?

A.Set the 'volumeBindingMode' to 'Immediate' in the PVC.

B.Install the CSI driver and then all PVCs will automatically be provisioned.

C.Create a StorageClass with 'provisioner' set to the CSI driver name.

D.Create a PersistentVolume with the CSI driver name in the 'csi' section.

AnswerC

StorageClass with provisioner enables dynamic provisioning when a PVC references it.

Why this answer

Dynamic provisioning requires a StorageClass object that references the CSI driver's provisioner name. The provisioner field in StorageClass must match the driver name registered on the cluster. Option B is correct.

Full explanation →

748

Multi-Selecthard

Which THREE components must be present in a high-availability control plane setup?

Select 3 answers

A.kubelet

B.kube-proxy

C.kube-controller-manager

D.etcd

E.kube-apiserver

AnswersC, D, E

Why this answer

The kube-controller-manager is a core control plane component that runs controller processes to regulate the state of the cluster, such as the node controller, replication controller, and endpoints controller. In a high-availability setup, multiple instances of the kube-controller-manager run concurrently, but only one active leader performs work at a time, using leader election via endpoints or leases to ensure no duplicate actions occur.

Exam trap

CNCF often tests the distinction between control plane components and node-level agents, so candidates mistakenly include kubelet or kube-proxy as part of the control plane because they are essential to cluster operation, but they are not part of the control plane's high-availability architecture.

Full explanation →

749

Multi-Selectmedium

Which TWO of the following are valid methods to configure kubectl to use a specific context?

Select 2 answers

A.kubectl config set-context my-context

B.kubectl config current-context

C.kubectl config use-context my-context

D.export KUBECONFIG=/path/to/config

E.kubectl --config /path/to/config get pods

AnswersC, D

Why this answer

Option C is correct because `kubectl config use-context my-context` is the explicit command to switch the current context in kubectl's configuration file (typically ~/.kube/config). This updates the `current-context` field in the config, so all subsequent kubectl commands target the cluster, namespace, and user defined in that context.

Exam trap

The trap here is that candidates confuse `set-context` (which only defines or updates a context) with `use-context` (which activates it), and also mistakenly think `--config` is a valid kubectl flag when the correct flag is `--kubeconfig`.

Full explanation →

750

Multi-Selectmedium

Which TWO of the following are valid reclaim policies for PersistentVolumes?

Select 2 answers

A.Retain

B.Delete

C.Recycle

D.Archive

E.Reuse

AnswersA, B

Retain is a valid reclaim policy.

Why this answer

A is correct because the Retain reclaim policy is a valid PersistentVolume (PV) reclaim policy. When a PersistentVolumeClaim (PVC) is deleted, Retain instructs the system to keep the PV and its underlying storage resource intact, allowing manual data recovery or reuse. This policy is defined in the PV's `persistentVolumeReclaimPolicy` field and is one of the three officially supported policies in Kubernetes.

Exam trap

The trap here is that candidates may confuse deprecated or non-existent policies (like Recycle or Archive) with valid ones, or assume that Recycle is still supported, when in fact only Retain and Delete are currently valid for the CKA exam.

Full explanation →

Page 10 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 →