CCNA Cluster Architecture, Installation and Configuration Questions — Page 2 of 3

MCQhard

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

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

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

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

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

AnswerB

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.kubelet

B.kube-proxy

C.container runtime

D.etcd

E.kube-apiserver

AnswersD, E

etcd is a control plane component.

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.kubectl config get-contexts -o name

B.kubectl config view --context current

C.kubectl config current-context

D.kubectl config get-contexts

E.kubectl config view --minify

AnswersC, E

Displays the current context.

Why this answer

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

Exam trap

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

Practice this question →

MCQhard

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

A.kubelet on the worker node

B.kube-apiserver on the control plane

C.kube-controller-manager

D.etcd cluster health

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

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

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

D.The worker node has not been cordoned.

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kube-scheduler

B.kube-controller-manager

C.kubelet

D.kube-proxy

AnswerC

The kubelet manages pods on the node.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

A kubeadm cluster is being upgraded from v1.28 to v1.29. You have upgraded the control plane components on the first master node. What is the NEXT step according to the recommended upgrade procedure?

A.Drain the first node

B.Upgrade the worker nodes

C.Upgrade the remaining control plane nodes

D.Run kubeadm upgrade plan

AnswerC

Control plane nodes are upgraded sequentially.

Why this answer

After upgrading the control plane components on the first master node in a kubeadm cluster, the next step is to upgrade the remaining control plane nodes. The kubeadm upgrade procedure requires upgrading all control plane nodes before any worker nodes, because the control plane must be fully upgraded to v1.29 to ensure API server compatibility and etcd cluster consistency. Skipping to worker nodes or draining the first node prematurely would violate the upgrade order specified in the official Kubernetes upgrade documentation.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 3 answers

A.Upgrade kubelet and kubectl on the node.

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

C.Upgrade the container runtime to a compatible version.

D.Drain the node before upgrading it.

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

AnswersA, B, D

These components must be upgraded manually.

Why this answer

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

Exam trap

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

Practice this question →

MCQmedium

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

A.kubectl drain node1

B.kubectl cordon node1

C.kubectl taint nodes node1 key=value:NoSchedule

D.kubectl delete node node1

AnswerB

Correct: cordon marks node unschedulable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubectl config switch-context

B.kubectl config set-context

C.kubectl config current-context

D.kubectl config use-context

AnswerD

This command sets the current context for kubectl.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

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

C.Mount the secret directly using a volume.

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

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

B.Upgrade all nodes simultaneously

C.Upgrade worker nodes first, then control plane nodes

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.ClusterRoleBinding with get, list, watch on pods

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

C.ClusterRole with get, list, watch on pods

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

AnswerB

Correct: Role scoped to namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 2 answers

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

B.Check the pod logs on the node

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

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

E.Reboot the node

AnswersA, C

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

Why this answer

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

Exam trap

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

Practice this question →

MCQhard

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

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

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

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

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

AnswerC

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

Why this answer

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

Practice this question →

MCQeasy

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

A.To restart the kubelet service

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

C.To upgrade the cluster to a newer version

D.To add a new node to the cluster

AnswerB

This is the correct description of 'kubeadm reset'.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecteasy

Which TWO commands are used to manage node schedulability? (Select TWO.)

Select 2 answers

A.kubectl label

B.kubectl drain

C.kubectl uncordon

D.kubectl taint

E.kubectl cordon

AnswersC, E

Marks node schedulable.

Why this answer

Option C (kubectl uncordon) is correct because it marks a node as schedulable, allowing new pods to be placed on it. Option E (kubectl cordon) is correct because it marks a node as unschedulable, preventing new pods from being scheduled while leaving existing pods running. Both commands directly manage the node's schedulability status by toggling the `spec.unschedulable` field.

Exam trap

The trap here is that candidates confuse `kubectl drain` (which includes cordoning and pod eviction) with a command that solely manages schedulability, or they mistakenly think `kubectl taint` directly controls node schedulability rather than influencing pod placement through tolerations.

Practice this question →

Multi-Selecthard

Which THREE are valid methods to authenticate a user to the Kubernetes API server? (Select 3)

Select 3 answers

A.Bearer tokens (e.g., service account tokens)

B.Username/password via HTTP Basic Auth

C.Client certificates

D.Static password file

E.OpenID Connect (OIDC) tokens

AnswersA, C, E

Bearer tokens are used for service accounts and can also be used for users via static tokens.

Why this answer

Bearer tokens, such as those used by service accounts, are a valid authentication method for the Kubernetes API server. The API server validates the token against the token authentication file or, for service accounts, against the TokenReview API, which verifies the token's validity and associated identity.

Exam trap

The trap here is that candidates often confuse HTTP Basic Auth with bearer token authentication, or mistakenly think a static password file is a valid method, when Kubernetes only supports token-based (including OIDC) and certificate-based authentication.

Practice this question →

MCQeasy

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

A.kubectl cordon node01

B.kubectl drain node01

C.kubectl taint node node01 key=value:NoExecute

D.kubectl delete node node01

AnswerB

Drain evicts pods and marks the node unschedulable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

Which THREE of the following are valid steps in a Kubernetes cluster upgrade procedure using kubeadm?

Select 3 answers

A.Drain the control plane node before upgrading it

B.Downgrade the kubelet on worker nodes to match the control plane version

C.Upgrade the kubeadm binary on the node before upgrading the cluster

D.Run 'kubeadm upgrade plan' to check versions and available upgrades

E.Uncordon the node before draining it

AnswersA, C, D

Draining evicts workloads so the node can be upgraded safely.

Why this answer

Option A is correct because draining the control plane node before upgrading it ensures that all workloads are evicted and rescheduled to other nodes, preventing service disruption. This is a standard Kubernetes procedure where 'kubectl drain' marks the node as unschedulable and evicts pods, respecting PodDisruptionBudgets.

Exam trap

The trap here is that candidates may confuse the upgrade order (e.g., thinking you can upgrade kubelet before kubeadm) or incorrectly assume that downgrading the kubelet is acceptable, when in fact the kubelet must be at the same or newer version as the control plane, not older.

Practice this question →

MCQhard

During a cluster upgrade from v1.28 to v1.29, which component should be upgraded first on the control plane node?

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerD

etcd should be upgraded first to ensure data store compatibility.

Why this answer

During a Kubernetes cluster upgrade, the control plane components must be upgraded in a specific order to maintain cluster stability and API availability. etcd, as the cluster's backing store, should be upgraded first because all other control plane components (kube-apiserver, kube-scheduler, kube-controller-manager) depend on it for reading and writing cluster state. Upgrading etcd first ensures that the data store is compatible with the new version before the API server and other controllers are updated.

Exam trap

CNCF often tests the misconception that the kube-apiserver should be upgraded first because it is the central component, but the correct order requires etcd to be upgraded first due to its role as the underlying data store.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the next component to upgrade after etcd, but it cannot be upgraded first as it relies on etcd for storing and retrieving cluster state; upgrading it before etcd could lead to API version mismatches or data corruption. Option B is wrong because kube-scheduler depends on the kube-apiserver to watch for unscheduled pods and bind them to nodes; upgrading it before the API server would break its communication with the cluster. Option C is wrong because kube-controller-manager also depends on the kube-apiserver to watch and reconcile controller loops; upgrading it before the API server would cause it to fail to interact with the cluster state.

Practice this question →

MCQeasy

Which command initializes a new Kubernetes cluster using kubeadm?

A.kubeadm create cluster

B.kubeadm setup

C.kubeadm init

D.kubeadm start

AnswerC

Correct.

Why this answer

Option C is correct because `kubeadm init` is the official Kubernetes command to bootstrap a control-plane node and initialize a new cluster. It performs preflight checks, generates certificates, creates the static Pod manifests for core components (etcd, API server, controller manager, scheduler), and configures the admin kubeconfig file.

Exam trap

The trap here is that candidates confuse `kubeadm init` with generic system commands like `create` or `start`, or assume a `setup` subcommand exists, when in fact `kubeadm init` is the only correct command for initializing a cluster.

How to eliminate wrong answers

Option A is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control-plane initialization and `join` for worker nodes. Option B is wrong because `kubeadm setup` does not exist in the kubeadm CLI; the correct command for initializing a cluster is `kubeadm init`. Option D is wrong because `kubeadm start` is not a valid kubeadm subcommand; kubeadm does not manage the lifecycle of running processes—it only bootstraps the cluster, after which kubelet and container runtime handle the Pods.

Practice this question →

MCQeasy

Which control plane component is responsible for storing the cluster state and configuration?

A.etcd

B.kube-controller-manager

C.kube-apiserver

D.kube-scheduler

AnswerA

etcd is the store for all cluster state and configuration.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage component because it is the primary interface for all cluster operations, but it is actually a stateless API gateway that relies entirely on etcd for persistence.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller loops that reconcile the current state with the desired state stored in etcd, but it does not store any data itself. Option C (kube-apiserver) is wrong because it is the front-end API gateway that validates and processes requests, but it delegates all persistent storage to etcd and does not maintain its own database. Option D (kube-scheduler) is wrong because it only assigns pods to nodes based on resource availability and policies, and it reads cluster state from the API server without storing any state or configuration.

Practice this question →

MCQmedium

You are using kubeadm to initialize a Kubernetes cluster. After running 'kubeadm init', the control-plane node is not ready. You run 'kubectl get nodes' and see the node status as 'NotReady'. Which component is most likely not functioning correctly?

A.kube-scheduler

B.etcd

C.kube-apiserver

D.kubelet

AnswerD

The kubelet is responsible for node status. If it is not running or cannot communicate with the API server, the node will be NotReady.

Why this answer

The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and maintaining pod lifecycle. After 'kubeadm init', if the control-plane node shows 'NotReady', it almost always indicates that the kubelet is not running or is failing to communicate with the control plane, often due to missing or misconfigured container runtime (e.g., containerd, CRI-O) or network plugin (CNI).

Exam trap

The trap here is that candidates often confuse control-plane component failures (like scheduler or API server) with node-level agent failures, but the 'NotReady' status is specifically a kubelet-driven condition, not a control-plane component status.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is responsible for assigning pods to nodes, not for node readiness; a non-functional scheduler would cause pods to remain Pending, not a node to be NotReady. Option B is wrong because etcd is the cluster's key-value store; while etcd failure would cause widespread issues, node readiness is determined by the kubelet's heartbeat to the API server, not directly by etcd. Option C is wrong because the kube-apiserver is the front-end for the control plane; if it were down, 'kubectl get nodes' would fail entirely, rather than showing a node as NotReady.

Practice this question →

100

MCQmedium

To back up etcd, which command should be used with etcdctl?

A.etcdctl export

B.etcdctl backup

C.etcdctl dump

D.etcdctl snapshot save

AnswerD

This command saves a snapshot of etcd data to a file.

Why this answer

The correct command to back up etcd is `etcdctl snapshot save`, which creates a point-in-time snapshot of the etcd key-value store. This is the officially recommended method for backing up etcd data in Kubernetes clusters, as it captures the entire database state consistently.

Exam trap

The trap here is that candidates may confuse `etcdctl` subcommands with similar-sounding Linux backup commands (like `dump` or `export`) or assume a generic `backup` subcommand exists, when the CKA exam specifically tests knowledge of the exact `snapshot save` syntax.

How to eliminate wrong answers

Option A is wrong because `etcdctl export` is not a valid command; the correct command for exporting data is `etcdctl snapshot save`. Option B is wrong because `etcdctl backup` is not a valid subcommand; etcdctl uses `snapshot save` for backups. Option C is wrong because `etcdctl dump` is not a valid command; the closest valid command is `etcdctl snapshot save` for backups or `etcdctl get` for retrieving specific keys.

Practice this question →

101

Multi-Selecthard

Which THREE of the following are steps required when restoring an etcd cluster from a snapshot?

Select 3 answers

A.Run 'etcdctl snapshot restore' specifying a new data directory

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

C.Restore the snapshot on every etcd member in the cluster

D.Stop the etcd service on the node

E.Run 'kubeadm init' to reinitialize the control plane

AnswersA, B, D

Restore command creates a new data directory from snapshot.

Why this answer

Option A is correct because 'etcdctl snapshot restore' is the command used to restore an etcd cluster from a snapshot. You must specify a new data directory (e.g., --data-dir=/var/lib/etcd-restored) to avoid overwriting existing data and to allow the restored snapshot to be used as a fresh data source for the etcd member.

Exam trap

The trap here is that candidates assume the snapshot must be restored on every member, but in practice you restore on one member and let the cluster rebuild itself, or you restore individually with unique data directories and cluster tokens.

Practice this question →

102

MCQmedium

A node has been cordoned. Which statement about the node is true?

A.All pods on the node are immediately terminated

B.The kubelet on the node is stopped

C.The node is removed from the cluster

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

AnswerD

Cordoning sets the node's status to Unschedulable, preventing new pods from being scheduled while existing pods keep running.

Why this answer

When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

Exam trap

The trap here is confusing `cordon` with `drain` — candidates often think cordoning also evicts pods, but it only prevents new scheduling, leaving existing pods untouched.

How to eliminate wrong answers

Option A is wrong because cordoning does not terminate pods; only `kubectl drain` evicts or deletes pods. Option B is wrong because the kubelet continues to run and manage existing pods; cordoning only affects the scheduler. Option C is wrong because the node remains a member of the cluster and is still visible via `kubectl get nodes`; it is not removed.

Practice this question →

103

MCQhard

A cluster was upgraded from version 1.28 to 1.29. After the upgrade, you notice that a custom controller using the 'batch/v2alpha1' API for CronJobs no longer works. What is the most likely reason?

A.The API server was not restarted after the upgrade

B.The CronJob resource has been renamed to ScheduledJob

C.The batch/v2alpha1 API version is deprecated and removed in 1.29

D.The custom controller uses an incorrect kubeconfig

AnswerC

batch/v2alpha1 was removed in 1.29. Must use batch/v1.

Why this answer

The batch/v2alpha1 API version for CronJobs was deprecated in Kubernetes 1.21 and removed entirely in 1.29. Since the cluster was upgraded from 1.28 to 1.29, the custom controller can no longer use this API version because the API server no longer serves it. Controllers must migrate to the stable batch/v1 API version to function correctly.

Exam trap

The trap here is that candidates may assume the API server needs a manual restart (Option A) or confuse the resource name change (Option B), but the real issue is Kubernetes' strict API version lifecycle and removal policy.

How to eliminate wrong answers

Option A is wrong because the API server is automatically restarted as part of the upgrade process (e.g., via kubeadm upgrade), and a missing restart would cause broader failures, not just a single API version. Option B is wrong because the CronJob resource has never been renamed to ScheduledJob; that was a pre-release name in very early Kubernetes versions and is not relevant here. Option D is wrong because an incorrect kubeconfig would cause authentication or connection failures for all API calls, not specifically for the batch/v2alpha1 API version.

Practice this question →

104

MCQmedium

What is the purpose of 'kubeadm reset'?

A.To restart the Kubernetes services on a node.

B.To reinitialize the cluster with new configuration.

C.To remove the node from the cluster and clean up.

D.To rollback the last upgrade.

AnswerC

reset cleans up the node so it can be rejoined or used for other purposes.

Why this answer

`kubeadm reset` is designed to revert any changes made by `kubeadm init` or `kubeadm join` on a node, effectively cleaning up the node's local state (e.g., removing CNI configurations, etcd member data, and kubelet certificates) so it can be safely removed from the cluster or reinitialized. Option C correctly identifies this as removing the node from the cluster and cleaning up, which is the primary purpose of the command.

Exam trap

CNCF often tests the misconception that `kubeadm reset` is a general-purpose reset or rollback tool, when in fact it is a destructive cleanup command that only prepares a node for re-joining or re-initialization, not for reverting cluster-wide changes or upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm reset` does not restart Kubernetes services; it tears down and cleans up the node, whereas `systemctl restart kubelet` or `kubeadm upgrade` commands handle service restarts. Option B is wrong because `kubeadm reset` does not reinitialize the cluster with new configuration; it only cleans up the current state, and reinitialization would require running `kubeadm init` again with a new config. Option D is wrong because `kubeadm reset` is not a rollback mechanism for upgrades; `kubeadm upgrade` has its own rollback procedures (e.g., `kubeadm upgrade apply --etcd-upgrade=false` or manual etcd snapshot restore), and `reset` simply destroys the node's Kubernetes artifacts without preserving upgrade history.

Practice this question →

105

Multi-Selectmedium

Which TWO commands can be used to view the configuration of a kubeconfig file?

Select 2 answers

A.kubectl describe configmap kubeconfig

B.kubectl config set-context

C.kubectl config current-context

D.kubectl config get-contexts

E.kubectl config view

AnswersD, E

This lists all contexts defined in the kubeconfig.

Why this answer

Option D is correct because `kubectl config get-contexts` lists all contexts defined in the kubeconfig file, showing their names, clusters, and users. Option E is correct because `kubectl config view` displays the entire merged kubeconfig file content, including clusters, users, and contexts, in YAML or JSON format.

Exam trap

The trap here is that candidates may confuse commands that modify the kubeconfig (like `set-context`) with commands that display it, or mistakenly think `current-context` shows the full configuration when it only shows the active context name.

Practice this question →

106

MCQeasy

Which component is responsible for managing the network rules and forwarding on each node?

A.container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerC

kube-proxy maintains network rules and performs connection forwarding.

Why this answer

kube-proxy is the component responsible for managing network rules and forwarding traffic on each node. It implements the Kubernetes Service concept by maintaining iptables or IPVS rules that route packets to the correct backend pods, handling load balancing and service discovery at the network layer.

Exam trap

CNCF often tests the misconception that kubelet handles networking, but kubelet only manages pod lifecycle and container runtime interactions, not network rule management.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is only responsible for pulling images and running containers, not for managing network rules or packet forwarding. Option B is wrong because the kubelet is the primary node agent that registers the node with the API server and manages pod lifecycle, but it does not handle network rule management or forwarding. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, and it has no role in network traffic forwarding.

Practice this question →

107

MCQhard

You need to allow a specific pod running in namespace 'app' to communicate with a database pod in namespace 'db' only. Which NetworkPolicy configuration achieves this?

A.NetworkPolicy in namespace 'db' with podSelector: {} and ingress from namespace 'app' and podSelector: {}

B.NetworkPolicy in namespace 'db' with podSelector: {} and ingress from namespace 'app'

C.NetworkPolicy in namespace 'app' with egress to namespace 'db' and podSelector: {}

D.NetworkPolicy in namespace 'app' allowing ingress from namespace 'db'

AnswerB

This policy allows ingress to all pods in 'db' from any pod in 'app'.

Why this answer

Option B is correct because a NetworkPolicy in the 'db' namespace with an empty podSelector: {} selects all pods in that namespace, and the ingress rule from namespace 'app' with an empty podSelector: {} allows traffic from any pod in the 'app' namespace. This configuration restricts inbound traffic to the database pods exclusively to pods from the 'app' namespace, meeting the requirement.

Exam trap

The trap here is that candidates often think a NetworkPolicy must be placed in the source namespace (e.g., 'app') to control egress, but the correct approach is to place the policy in the destination namespace ('db') to restrict ingress, and they may also overlook that an empty podSelector: {} selects all pods, not a specific one.

How to eliminate wrong answers

Option A is wrong because it includes an ingress rule with podSelector: {} inside the from block, which would allow traffic from all pods in the 'app' namespace (which is fine), but the extra podSelector: {} is redundant and does not break the policy, but the option is not the minimal correct answer; however, the key issue is that the question asks for a configuration that allows communication only from the specific pod in 'app' to the database pod in 'db', and Option A's podSelector: {} in the from block actually selects all pods in the 'app' namespace, not a specific pod, so it is too permissive. Option C is wrong because placing the NetworkPolicy in the 'app' namespace with egress to namespace 'db' and podSelector: {} would control outbound traffic from all pods in 'app' to all pods in 'db', but it does not restrict inbound traffic to the database pod, and it allows all pods in 'app' to egress, not just the specific pod. Option D is wrong because a NetworkPolicy in the 'app' namespace allowing ingress from namespace 'db' would control inbound traffic to pods in 'app', not outbound traffic from 'app' to 'db', and it does not address the requirement of allowing a specific pod in 'app' to communicate with a database pod in 'db'.

Practice this question →

108

MCQeasy

Which command is used to create a backup of etcd data using etcdctl?

A.etcdctl endpoint status

B.etcdctl snapshot restore /backup/snapshot.db

C.etcdctl snapshot save /backup/snapshot.db

D.etcdctl member list

AnswerC

This command creates a snapshot backup of etcd data.

Why this answer

Option C is correct because `etcdctl snapshot save` is the command used to create a point-in-time backup of etcd data. This command captures the entire key-value store and writes it to a specified file path, which is essential for disaster recovery in Kubernetes clusters that use etcd as their backing store.

Exam trap

The trap here is that candidates confuse the `save` and `restore` subcommands, often selecting `snapshot restore` (Option B) because they think 'backup' implies 'restore', but `save` is the correct verb for creating a backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl endpoint status` only returns health and version information about the etcd endpoints, not a backup of the data. Option B is wrong because `etcdctl snapshot restore` is used to restore a previously saved snapshot, not to create a new backup. Option D is wrong because `etcdctl member list` lists the members of the etcd cluster and their status, which is unrelated to creating a data backup.

Practice this question →

109

MCQhard

You have configured a ServiceAccount with an associated image pull secret. The Pod referencing this ServiceAccount still fails with ImagePullBackOff due to authentication errors. What is the most likely misconfiguration?

A.The secret is not in the same namespace as the Pod.

B.The secret type is wrong; it should be kubernetes.io/dockercfg.

C.The ServiceAccount does not have the imagePullSecrets field configured.

D.The Pod spec must set the secret in imagePullSecrets directly.

AnswerC

To use image pull secrets via a ServiceAccount, the secret must be added to the ServiceAccount's imagePullSecrets field.

Why this answer

Option C is correct because simply associating a ServiceAccount with a Pod does not automatically inject its imagePullSecrets into the Pod's spec. The ServiceAccount must explicitly have the imagePullSecrets field configured (e.g., `imagePullSecrets: - name: my-secret`) for the secret to be used when pulling images. Without this field, the Pod will not inherit the secret, leading to authentication failures and ImagePullBackOff.

Exam trap

The trap here is that candidates assume simply creating a ServiceAccount and associating it with a Pod (via `serviceAccountName`) is enough to inherit image pull secrets, but they forget that the ServiceAccount must explicitly list the secret in its `imagePullSecrets` field for the injection to occur.

How to eliminate wrong answers

Option A is wrong because the secret must be in the same namespace as the Pod and ServiceAccount for the reference to work; if it were in a different namespace, the Pod would fail to mount it entirely, not just with an authentication error. Option B is wrong because the correct secret type for image pull secrets is `kubernetes.io/dockerconfigjson` (not `kubernetes.io/dockercfg`, which is legacy and less common), and using the wrong type would cause a different error (e.g., invalid format) rather than a pure authentication failure. Option D is wrong because while a Pod can directly specify imagePullSecrets in its spec, the question states the Pod references a ServiceAccount, so the expected behavior is that the ServiceAccount's imagePullSecrets are automatically injected; requiring direct Pod spec configuration would defeat the purpose of using a ServiceAccount.

Practice this question →

110

MCQmedium

An admin wants to view the current context in their kubeconfig. Which command should they use?

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config current-context

D.kubectl config view

AnswerC

This outputs the current context name.

Why this answer

Option C is correct because `kubectl config current-context` is the exact command to display the currently active context from the kubeconfig file. The context includes the cluster, namespace, and user that `kubectl` will use by default. This is a direct query of the `current-context` field in the kubeconfig YAML/JSON structure.

Exam trap

The trap here is that candidates often confuse `get-contexts` (which lists all contexts) with `current-context` (which shows only the active one), or they mistakenly think `cluster-info` or `config view` will directly reveal the current context without additional parsing.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts from the kubeconfig file, not just the current one; it requires the user to visually identify the active context (marked with an asterisk). Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., master and services), not the current context from the kubeconfig. Option D is wrong because `kubectl config view` outputs the entire kubeconfig file contents, which includes all contexts, clusters, and users, but does not specifically highlight or return only the current context.

Practice this question →

111

Multi-Selectmedium

Which TWO of the following are valid methods to authenticate to the Kubernetes API server?

Select 2 answers

A.Client certificate

B.ServiceAccount token

C.Secrets

D.RBAC

E.Node authorization

AnswersA, B

Client certificates are used for user and component authentication.

Why this answer

Client certificate authentication (option A) is valid because the Kubernetes API server can be configured with TLS to require clients to present a valid X.509 certificate signed by the cluster's Certificate Authority (CA). The API server verifies the certificate's Common Name (CN) or Subject Alternative Name (SAN) against the user identity, and the 'organizational unit' (O) field can map to Kubernetes groups. This is a core authentication method used by tools like kubectl and kubelet.

Exam trap

The trap here is confusing authorization (RBAC, Node authorization) with authentication, or thinking that Secrets are a credential type presented to the API server, when they are merely storage objects that can hold tokens for later use.

Practice this question →

112

MCQhard

After running 'kubeadm certs check-expiration', an admin sees that the 'apiserver' certificate expires in 30 days. Which command should be used to renew it?

A.kubeadm upgrade node

B.openssl req -new -x509 -days 365 -key /etc/kubernetes/pki/apiserver.key -out /etc/kubernetes/pki/apiserver.crt

C.kubeadm certs renew apiserver

D.kubectl certificate renew apiserver

AnswerC

This renews the apiserver certificate.

Why this answer

Option C is correct because `kubeadm certs renew apiserver` is the dedicated kubeadm command to renew the API server certificate without restarting the control plane. It updates the certificate in place using the existing CA, and the new certificate is automatically picked up after a static pod restart or kubelet reload.

Exam trap

The trap here is that candidates may confuse `kubeadm certs renew` with `kubectl certificate` (which handles CSR approval, not renewal) or attempt a manual openssl command that breaks the trust chain, while the correct approach is the kubeadm-managed renewal that preserves CA-signed trust.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade node` is used to upgrade the kubelet configuration on worker nodes, not to renew certificates on the control plane. Option B is wrong because `openssl req -new -x509` creates a self-signed certificate, which would break the PKI trust chain; Kubernetes requires certificates signed by the cluster CA, not self-signed ones. Option D is wrong because `kubectl certificate renew` is not a valid kubectl command; certificate renewal in kubeadm is handled by the `kubeadm certs` subcommand, not kubectl.

Practice this question →

113

MCQmedium

You are using kubeadm to initialize a cluster. After running 'kubeadm init', you follow the instructions to set up the kubeconfig for the regular user. Which of the following commands should you run to allow kubectl to communicate with the cluster?

A.sudo cp /etc/kubernetes/controller-manager.conf $HOME/.kube/config

B.sudo cp /etc/kubernetes/scheduler.conf $HOME/.kube/config

C.sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

D.sudo cp /etc/kubernetes/kubelet.conf $HOME/.kube/config

AnswerC

This copies the admin kubeconfig to the user's home directory, which kubectl uses by default.

Why this answer

After running 'kubeadm init', the admin.conf file is generated in /etc/kubernetes/ and contains the cluster CA certificate, client certificate, and API server endpoint. This is the only kubeconfig file that grants full administrative access to the cluster, making it the correct file to copy to the user's $HOME/.kube/config for kubectl to communicate with the cluster.

Exam trap

The trap here is that candidates confuse the various kubeconfig files generated by kubeadm (each tied to a specific control plane component) and mistakenly copy a component-specific config (like controller-manager.conf or kubelet.conf) instead of the admin.conf, which is the only one designed for administrative kubectl access.

How to eliminate wrong answers

Option A is wrong because /etc/kubernetes/controller-manager.conf is the kubeconfig used by the kube-controller-manager component, not for regular user kubectl access. Option B is wrong because /etc/kubernetes/scheduler.conf is the kubeconfig used by the kube-scheduler component, not for regular user kubectl access. Option D is wrong because /etc/kubernetes/kubelet.conf is the kubeconfig used by the kubelet on the node, not for regular user kubectl access.

Practice this question →

114

MCQhard

You need to renew all certificates on a kubeadm-managed cluster. Which command accomplishes this?

A.kubeadm certs renew apiserver

B.kubeadm certs check-expiration

C.kubeadm certs renew all

D.kubeadm upgrade apply

AnswerC

Renews all certificates managed by kubeadm.

Why this answer

Option C is correct because `kubeadm certs renew all` is the dedicated command to renew all PKI certificates in a kubeadm-managed cluster. It regenerates each certificate using the existing CA key, updating the certificate files in `/etc/kubernetes/pki/` without restarting control plane components; a manual restart or kubelet reload is required afterward.

Exam trap

The trap here is that candidates confuse `kubeadm certs renew all` with `kubeadm upgrade apply`, thinking an upgrade is required to renew certificates, when in fact the dedicated renew command exists and is the correct tool for certificate-only renewal without changing cluster version.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs renew apiserver` only renews the API server certificate, not all certificates (e.g., etcd, kubelet, controller-manager). Option B is wrong because `kubeadm certs check-expiration` only displays expiration dates and does not perform any renewal. Option D is wrong because `kubeadm upgrade apply` upgrades the cluster version and may renew certificates as a side effect, but it is not the dedicated command for certificate renewal and may introduce version changes or fail if only renewal is needed.

Practice this question →

115

Multi-Selecthard

You have taken an etcd snapshot using 'ETCDCTL_API=3 etcdctl snapshot save snapshot.db'. Which TWO commands are needed to restore this snapshot to a new etcd member? (Choose TWO.)

Select 2 answers

A.etcdctl endpoint health

B.etcdctl snapshot save backup.db

C.Update the etcd configuration (e.g., --data-dir) and restart the etcd service

D.etcdctl snapshot restore snapshot.db --data-dir=/var/lib/etcd-restore

E.etcdctl snapshot status snapshot.db

AnswersC, D

After restore, you must configure etcd to use the new data directory.

Why this answer

Option C is correct because after restoring an etcd snapshot, the etcd service must be configured to use the restored data directory (e.g., via `--data-dir` or the `ETCD_DATA_DIR` environment variable) and then restarted. This ensures the new etcd member loads the snapshot data instead of starting with an empty or default state.

Exam trap

The trap here is that candidates often confuse snapshot status or health checks with actual restoration steps, forgetting that `snapshot restore` must be followed by updating the etcd configuration and restarting the service to make the restored data active.

Practice this question →

116

Multi-Selecthard

Which THREE of the following are valid methods to authenticate to the Kubernetes API server? (Select 3)

Select 3 answers

A.Service account bearer tokens

B.Anonymous requests

C.Static token file

D.Password file with usernames and passwords

E.X.509 client certificates

AnswersA, C, E

Used by pods to authenticate.

Why this answer

Service account bearer tokens are a valid authentication method to the Kubernetes API server. When a pod is associated with a service account, Kubernetes automatically mounts a token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the API server validates against the TokenReview API, allowing the pod to authenticate as that service account.

Exam trap

CNCF often tests the misconception that static token files and password files are equivalent, but static token files (option C) are valid while password files (option D) were deprecated and removed, so candidates must remember the deprecation timeline.

Practice this question →

117

MCQeasy

Which command allows you to view the current context in a kubeconfig file?

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config view

D.kubectl config current-context

AnswerD

Correct command to display the current context.

Why this answer

Option D is correct because `kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. It reads the `current-context` field from the kubeconfig (typically `~/.kube/config`) and outputs its name, making it the most direct way to view the current context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which lists all contexts) with `kubectl config current-context` (which shows only the active one), leading them to choose A because they see the current context listed with an asterisk, but the question specifically asks for the command that 'allows you to view the current context' — not all contexts.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts in the kubeconfig file, but it does not specifically isolate or highlight the current context; it requires visual inspection to identify the one marked with an asterisk. Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., Kubernetes master and services), not the current context from the kubeconfig. Option C is wrong because `kubectl config view` outputs the entire kubeconfig file contents (including contexts, clusters, users, and current-context), which is more verbose and not a targeted way to view just the current context.

Practice this question →

118

MCQeasy

Which command is used to backup etcd data using etcdctl?

A.etcdctl backup

B.etcdctl export

C.etcdctl snapshot save

D.etcdctl dump

AnswerC

This creates a snapshot backup of etcd.

Why this answer

Option C is correct because `etcdctl snapshot save` is the official command in etcdctl v3 to create a point-in-time backup of the etcd data store. This command captures the entire key-value store and metadata into a snapshot file, which can later be restored using `etcdctl snapshot restore` to recover the cluster state.

Exam trap

The trap here is that candidates confuse the deprecated v2 `etcdctl backup` command with the correct v3 `etcdctl snapshot save` command, or they assume any 'export' or 'dump' verb is sufficient for a full backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl backup` is not a valid command in etcdctl v3; it was used in the deprecated v2 API but is no longer supported. Option B is wrong because `etcdctl export` dumps key-value pairs in JSON format but does not create a consistent, restorable snapshot of the entire etcd data store. Option D is wrong because `etcdctl dump` is not a valid etcdctl command; it may be confused with `etcdctl snapshot save` or other dump utilities but does not exist in the etcdctl CLI.

Practice this question →

119

Multi-Selectmedium

Which TWO of the following are valid methods to restore an etcd cluster from a snapshot? (Choose TWO.)

Select 2 answers

A.etcdctl restore

B.kubectl apply -f etcd-backup.yaml

C.Stopping all etcd members, copying the snapshot to the data directory, and starting etcd

D.etcdctl snapshot restore

E.kubeadm reset

AnswersC, D

If you replace the data directory with the snapshot, etcd will use it on startup.

Why this answer

Option C is correct because restoring an etcd cluster from a snapshot can be done by stopping all etcd members, copying the snapshot file to the etcd data directory (typically `/var/lib/etcd`), and then restarting the etcd service. This manual method works when you replace the entire data directory with the snapshot content, allowing etcd to rebuild its state from the snapshot on startup.

Exam trap

CNCF often tests the distinction between `etcdctl restore` (invalid) and `etcdctl snapshot restore` (valid), and the trap here is that candidates may confuse the deprecated `etcdctl restore` command with the correct `etcdctl snapshot restore` subcommand, or think that `kubectl apply` can handle binary snapshot files.

Practice this question →

120

MCQeasy

Which component is responsible for maintaining the desired state of the cluster, such as ensuring the correct number of replicas for a Deployment?

A.kube-apiserver

B.kubelet

C.kube-controller-manager

D.kube-scheduler

AnswerC

Runs controllers like Deployment controller.

Why this answer

The kube-controller-manager is responsible for running controller processes that regulate the state of the cluster. It includes the Deployment controller, which watches the API server for changes to Deployment objects and ensures the actual number of replicas matches the desired state by creating or deleting Pods via the ReplicaSet controller.

Exam trap

The trap here is that candidates often confuse the kubelet's role in maintaining Pod health on a node with the controller-manager's cluster-wide reconciliation of desired state, especially since both involve 'ensuring' something is running.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane, exposing the Kubernetes API; it does not actively reconcile desired state but rather validates and processes requests. Option B is wrong because kubelet is an agent running on each worker node that ensures containers are running in a Pod as specified by the PodSpec, but it does not manage cluster-level desired state like replica counts. Option D is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for maintaining the desired number of replicas.

Practice this question →

121

MCQmedium

Which command is used to check the expiration of certificates managed by kubeadm?

A.kubeadm certs status

B.kubeadm certs check-expiration

C.kubeadm certs list

D.kubeadm certs renew

AnswerB

This command shows the expiration dates of each certificate.

Why this answer

The correct command to check the expiration of certificates managed by kubeadm is `kubeadm certs check-expiration`. This command reads the certificate files located in `/etc/kubernetes/pki/` and displays their remaining validity period, allowing administrators to proactively renew certificates before they expire.

Exam trap

The trap here is that candidates may confuse `kubeadm certs check-expiration` with `kubeadm certs renew`, thinking the latter also shows expiration status, but `renew` only performs the renewal action without displaying current expiration data.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs status` is not a valid kubeadm subcommand; the correct subcommand for checking expiration is `check-expiration`. Option C is wrong because `kubeadm certs list` does not exist; kubeadm does not provide a `list` subcommand for certificates. Option D is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration status, and it requires prior verification of expiration to avoid unnecessary renewals.

Practice this question →

122

MCQhard

You have an etcd cluster with three members. You need to take a snapshot for disaster recovery. Which command correctly creates a snapshot?

A.etcdctl snapshot restore /backup/snapshot.db

B.ETCDCTL_API=2 etcdctl backup --data-dir /var/lib/etcd

C.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db --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

D.etcdctl snapshot save /backup/snapshot.db

AnswerC

Correct command with API v3, snapshot save, and required TLS flags.

Why this answer

Option C is correct because it uses the etcdctl v3 API with the `snapshot save` command, which is the proper method for creating a consistent point-in-time backup of an etcd cluster. The command includes mandatory TLS authentication flags (`--cacert`, `--cert`, `--key`) and the `--endpoints` flag to target a specific etcd member, ensuring a secure and successful snapshot operation.

Exam trap

The trap here is that candidates often forget to include TLS flags or the `--endpoints` flag, assuming a local default connection works, or they confuse `snapshot save` with `snapshot restore` or the deprecated v2 API backup command.

How to eliminate wrong answers

Option A is wrong because `etcdctl snapshot restore` is used to restore a snapshot, not to create one. Option B is wrong because `ETCDCTL_API=2 etcdctl backup` uses the deprecated v2 API, which does not support snapshotting the v3 data store and is not recommended for disaster recovery in modern etcd clusters. Option D is wrong because it omits the required `--endpoints` and TLS flags; without these, the command will fail to connect to the etcd server (which listens on a secure port by default) or will default to localhost without authentication, resulting in a permission error or connection refusal.

Practice this question →

123

MCQeasy

Which component on a worker node is responsible for maintaining network rules and forwarding traffic to the correct pod?

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerC

kube-proxy handles network rules and traffic forwarding for Services.

Why this answer

kube-proxy is the correct component because it runs on each worker node and is responsible for implementing Kubernetes Service concepts by maintaining network rules (iptables or IPVS) that allow network communication to Pods from inside or outside the cluster. It forwards traffic to the correct Pod by load-balancing across the endpoints of a Service, using the cluster IP and port.

Exam trap

The trap here is that candidates often confuse kube-proxy with kubelet, thinking the node agent manages networking, but kubelet only ensures Pods are running while kube-proxy specifically handles Service-to-Pod traffic rules.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for managing network rules or traffic forwarding. Option B is wrong because kubelet is the primary node agent that registers the node, manages Pod lifecycle, and reports node status, but it does not handle network rule maintenance or packet forwarding. Option D is wrong because kube-scheduler is a control plane component that assigns Pods to nodes based on resource availability and constraints; it has no role in network traffic forwarding on worker nodes.

Practice this question →

124

MCQmedium

An admin wants to check the expiration date of all certificates used by kubeadm components. Which command should be used?

A.kubeadm certs check-expiration

B.kubeadm upgrade plan

C.kubeadm certs renew

D.kubectl get certificates

AnswerA

This command checks certificate expiration.

Why this answer

The `kubeadm certs check-expiration` command is the correct tool to inspect the expiration dates of all certificates generated by kubeadm for cluster components, such as the API server, controller-manager, scheduler, and etcd. It reads the certificate files from the default kubeadm certificate directory (`/etc/kubernetes/pki`) and displays their remaining validity period in a human-readable table. This command is part of the kubeadm certificate management suite and is specifically designed for this purpose.

Exam trap

The trap here is that candidates confuse `kubeadm certs check-expiration` with `kubeadm upgrade plan` or `kubectl get certificates`, mistakenly thinking that upgrade planning or a generic kubectl command can reveal certificate expiry, when in fact only the kubeadm-specific subcommand provides this information.

How to eliminate wrong answers

Option B is wrong because `kubeadm upgrade plan` checks the feasibility of upgrading the cluster to a newer Kubernetes version and lists available versions, but it does not display certificate expiration dates. Option C is wrong because `kubeadm certs renew` is used to renew all or specific certificates, not to check their expiration status; running it without prior inspection could lead to unnecessary renewals. Option D is wrong because `kubectl get certificates` is not a valid command; Kubernetes does not have a built-in `certificates` resource type in the core API, and this command would return an error or no relevant output.

Practice this question →

125

MCQhard

An administrator runs 'kubectl get pods' and sees a pod stuck in 'Pending' state. Which of the following is NOT a typical cause?

A.Insufficient CPU or memory resources on any node

B.PersistentVolumeClaim is pending and not bound

C.A required ConfigMap does not exist

D.Node selector labels do not match any node

AnswerC

Why this answer

A missing ConfigMap does not prevent a pod from being scheduled; it only causes the pod to fail at runtime when it tries to mount or use the ConfigMap. The 'Pending' state specifically indicates that the pod has not been scheduled to a node, which is a scheduling issue, not a runtime configuration issue. Therefore, a missing ConfigMap is not a typical cause of a pod stuck in 'Pending'.

Exam trap

The trap here is that candidates confuse scheduling failures (which cause 'Pending') with runtime configuration errors (which cause 'CrashLoopBackOff' or 'Error'), leading them to incorrectly think a missing ConfigMap could prevent scheduling.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory resources on any node is a classic cause of 'Pending' — the scheduler cannot find a node with enough allocatable resources to satisfy the pod's resource requests. Option B is wrong because if a pod references a PersistentVolumeClaim that is pending (not bound to a PV), the scheduler will not schedule the pod until the PVC is bound, as the pod's volume requirements cannot be satisfied. Option D is wrong because if a pod uses a nodeSelector that does not match any node's labels, the scheduler will leave the pod in 'Pending' as no node meets the selection criteria.

Practice this question →

126

Multi-Selecthard

Which THREE of the following are valid options for the 'kubectl drain' command to safely evict pods from a node?

Select 3 answers

A.--grace-period=0

B.--timeout=30s

C.--force

D.--delete-emptydir-data

E.--ignore-daemonsets

AnswersC, D, E

Force eviction of pods that are not managed by a controller.

Why this answer

Option C is correct because the `--force` flag forces the drain to proceed even if there are pods not managed by a ReplicationController, ReplicaSet, Job, DaemonSet, or StatefulSet, or if there are unmanaged pods that would otherwise block the drain. This allows the node to be drained for maintenance even when some pods cannot be safely evicted through normal means.

Exam trap

The trap here is that candidates often confuse `kubectl drain` flags with `kubectl delete` flags, mistakenly thinking `--grace-period=0` or `--timeout` are primary drain options, when in fact the key flags for drain are `--force`, `--delete-emptydir-data`, and `--ignore-daemonsets`.

Practice this question →

127

Multi-Selectmedium

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

Select 2 answers

A.kubelet

B.etcd

C.kube-proxy

D.container runtime

E.kube-controller-manager

AnswersB, E

etcd is a control plane component storing cluster data.

Why this answer

etcd is a distributed key-value store that serves as the primary datastore for the Kubernetes cluster, storing all cluster state and configuration data. The kube-controller-manager runs controller processes that regulate the state of the cluster, such as the node controller, replication controller, and endpoints controller. Both are core control plane components that run on the master node(s).

Exam trap

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

Practice this question →

128

Multi-Selectmedium

Which TWO components run on worker nodes? (Select 2)

Select 2 answers

A.etcd

B.kubelet

C.kube-apiserver

D.kube-scheduler

E.kube-proxy

AnswersB, E

Runs on each node.

Why this answer

The kubelet is the primary node agent that runs on every worker node, responsible for managing pods and their containers as directed by the control plane. kube-proxy runs on each node (including workers) to maintain network rules and handle service-to-pod traffic routing via iptables or IPVS.

Exam trap

The trap here is that candidates often confuse control plane components (etcd, kube-apiserver, kube-scheduler) with node-level agents, especially since kube-proxy is sometimes mistakenly thought to be optional or only for network plugins, but it is a required component on every worker node.

Practice this question →

129

MCQmedium

You need to create a RoleBinding that grants a user access to read Pods in the 'dev' namespace. Which YAML manifest is correct?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: ServiceAccount name: dev-user roleRef: kind: Role name: pod-reader

B.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

C.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding ... subjects: - kind: User name: dev-user roleRef: kind: ClusterRole name: pod-reader

D.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: dev ... subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-reader

AnswerD

Correct: RoleBinding in namespace 'dev' references a Role named 'pod-reader'.

Why this answer

Option D is correct because it defines a RoleBinding in the 'dev' namespace that binds a User named 'dev-user' to a Role named 'pod-reader'. This grants the user read access to Pods within that specific namespace, which is exactly what the question requires. RoleBindings are namespace-scoped and must specify the target namespace in metadata.

Exam trap

CNCF often tests the distinction between RoleBinding and ClusterRoleBinding, and candidates mistakenly choose a ClusterRoleBinding when namespace-scoped access is required, or forget to include the namespace in the RoleBinding metadata.

How to eliminate wrong answers

Option A is wrong because it uses a ServiceAccount as the subject instead of a User, and the question explicitly asks to grant access to a user. Option B is wrong because it omits the namespace in metadata (RoleBindings are namespace-scoped and require a namespace), and it references a ClusterRole instead of a Role, which would work but is not the simplest correct answer; however, the missing namespace makes it invalid. Option C is wrong because it uses a ClusterRoleBinding, which grants cluster-wide access, not namespace-scoped access as required by the question.

Practice this question →

130

MCQeasy

Which command can you use to check the expiration date of certificates managed by kubeadm?

A.kubeadm certs check-expiration

B.kubectl get certificates

C.kubeadm certs list

D.kubeadm certs renew --check

AnswerA

This command shows the expiration dates for all certificates.

Why this answer

The correct command is `kubeadm certs check-expiration`, which is a dedicated kubeadm subcommand that inspects all certificates managed by kubeadm and displays their expiration dates, remaining validity, and renewal status. This command reads the certificate files from `/etc/kubernetes/pki/` and parses their X.509 metadata, providing a concise summary without requiring external tools like OpenSSL.

Exam trap

The trap here is that candidates confuse the `kubeadm certs` subcommands, often misremembering `list` or inventing flags like `--check`, when the actual command uses the precise verb `check-expiration` to separate inspection from renewal.

How to eliminate wrong answers

Option B is wrong because `kubectl get certificates` is not a valid kubectl command; kubectl interacts with Kubernetes API resources, not filesystem certificates, and there is no built-in 'certificates' resource type. Option C is wrong because `kubeadm certs list` does not exist; the correct subcommand for listing certificate details is `check-expiration`, not `list`. Option D is wrong because `kubeadm certs renew --check` is not a valid flag; the `renew` subcommand performs actual renewal, and there is no `--check` flag — the check functionality is separated into the `check-expiration` subcommand.

Practice this question →

131

MCQeasy

Which kubectl command is used to view the current context in the kubeconfig file?

A.kubectl config view

B.kubectl config use-context

C.kubectl config current-context

D.kubectl config get-contexts

AnswerC

This directly shows the name of the current context.

Why this answer

Option C is correct because `kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. This command directly queries the `current-context` field in the kubeconfig and outputs its value, allowing you to verify which cluster, user, and namespace combination is active without modifying any configuration.

Exam trap

The trap here is that candidates confuse `kubectl config get-contexts` (which lists all contexts and marks the current one) with `kubectl config current-context` (which outputs only the current context name), leading them to pick option D because they see the current context highlighted, but the question specifically asks for the command to 'view the current context' as a direct output.

How to eliminate wrong answers

Option A is wrong because `kubectl config view` displays the entire kubeconfig file contents, including all contexts, clusters, and users, but does not specifically show which context is currently active. Option B is wrong because `kubectl config use-context` is used to switch the active context, not to view it; it modifies the `current-context` field in the kubeconfig. Option D is wrong because `kubectl config get-contexts` lists all available contexts and marks the current one with an asterisk, but it does not directly output just the current context name; it shows the full list, which is not the same as the single command to view the current context.

Practice this question →

132

MCQmedium

You need to check the expiration date of certificates used by the kube-apiserver. Which command should you use?

A.kubeadm certs renew

B.kubectl get secrets -n kube-system

C.openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

D.kubeadm certs check-expiration

AnswerD

This command lists the expiration dates of certificates.

Why this answer

Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display the expiration dates of all certificates managed by kubeadm in the cluster, including the kube-apiserver certificate. This command reads the certificate files from `/etc/kubernetes/pki/` and outputs the remaining validity period for each, making it the most direct and accurate method for checking certificate expiration in a kubeadm-deployed cluster.

Exam trap

The trap here is that candidates may confuse `kubeadm certs check-expiration` with `kubeadm certs renew` (option A) or think that `openssl` (option C) is the only way to inspect certificates, but the CKA exam expects you to know the kubeadm-specific command for checking expiration as part of cluster maintenance tasks.

How to eliminate wrong answers

Option A is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration dates; it performs the renewal action without providing expiration information. Option B is wrong because `kubectl get secrets -n kube-system` retrieves Kubernetes secrets (which may contain certificate data as opaque or TLS secrets), but it does not decode or display the expiration dates of the certificates; it only shows metadata and base64-encoded values. Option C is wrong because while `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout` can indeed show the certificate details including expiration, it is a manual, file-level command that requires knowing the exact path and does not leverage kubeadm's cluster-aware certificate management; it is a valid alternative but not the recommended or most efficient command for this specific task in a kubeadm context.

Practice this question →

133

MCQeasy

Which command is used to initialize a Kubernetes cluster using kubeadm?

A.kubeadm init

B.kubeadm create cluster

C.kubeadm start

D.kubeadm bootstrap

AnswerA

kubeadm init initializes a Kubernetes control-plane node.

Why this answer

The correct command to initialize a Kubernetes cluster using kubeadm is `kubeadm init`. This command performs the bootstrap process by setting up the control plane components (e.g., API server, etcd, controller manager, scheduler) on the node, generating certificates, and creating the necessary configuration files in `/etc/kubernetes/`. It is the standard first step after installing kubeadm, kubelet, and a container runtime.

Exam trap

The trap here is that candidates confuse `kubeadm init` with non-existent commands like `kubeadm create cluster` or `kubeadm bootstrap`, assuming a more intuitive or verbose command exists, when in fact kubeadm's subcommands are deliberately minimal and specific.

How to eliminate wrong answers

Option B is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control plane initialization and `join` for worker nodes, not a generic 'create cluster'. Option C is wrong because `kubeadm start` does not exist; starting the cluster is handled by the kubelet service and systemd, not by kubeadm directly. Option D is wrong because `kubeadm bootstrap` is not a valid command; the bootstrap process is triggered by `kubeadm init` (or `kubeadm join` for nodes), and there is no separate 'bootstrap' subcommand.

Practice this question →

134

MCQmedium

An admin runs 'kubectl get pods' and sees a pod in 'Pending' state for a long time. 'kubectl describe pod' shows '0/1 nodes are available: 1 node has memory pressure'. Which is the most likely cause?

A.The node's disk is full.

B.The pod's image pull secret is missing.

C.The node is under memory pressure and cannot admit the pod.

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

AnswerC

Memory pressure prevents the scheduler from placing the pod on that node.

Why this answer

The '0/1 nodes are available: 1 node has memory pressure' message in `kubectl describe pod` indicates that the kubelet on the node has set a memory pressure condition, which triggers eviction thresholds. When a node is under memory pressure, the kubelet refuses to admit new pods (except those with QoS class Guaranteed) to prevent further resource exhaustion, leaving the pod stuck in Pending state. This matches option C exactly.

Exam trap

CNCF often tests the distinction between different node pressure conditions (memory vs. disk vs. PID) and their corresponding error messages, so candidates must recognize that 'memory pressure' is a specific kubelet condition, not a generic resource shortage.

How to eliminate wrong answers

Option A is wrong because a full disk would cause 'disk pressure', not 'memory pressure', and would be reported as '0/1 nodes are available: 1 node has disk pressure'. Option B is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node availability issues. Option D is wrong because insufficient CPU would be reported as 'Insufficient cpu' in the node conditions, not 'memory pressure', and the pod would still be schedulable if memory were available.

Practice this question →

135

MCQmedium

An administrator wants to use a ServiceAccount token that is mounted into a pod automatically. Which field enables token projection?

A.serviceAccountToken: true

B.enableToken: true

C.mountServiceAccountToken: true

D.automountServiceAccountToken: true

AnswerD

Why this answer

Option D is correct because the `automountServiceAccountToken` field, when set to `true` (the default), causes Kubernetes to automatically project the ServiceAccount token into the pod as a volume mount at `/var/run/secrets/kubernetes.io/serviceaccount/token`. This field can be set at the pod spec level or overridden at the ServiceAccount level, enabling token projection for authentication to the Kubernetes API server.

Exam trap

The trap here is that candidates confuse the `automountServiceAccountToken` field with similar-sounding but invalid options like `mountServiceAccountToken` or `serviceAccountToken`, or assume a generic `enableToken` field exists, when Kubernetes uses a specific boolean field with the 'automount' prefix.

How to eliminate wrong answers

Option A is wrong because `serviceAccountToken: true` is not a valid Kubernetes field; token projection is controlled by the `automountServiceAccountToken` boolean, not a `serviceAccountToken` field. Option B is wrong because `enableToken: true` is not a recognized Kubernetes field; there is no such parameter for enabling token projection in pod or ServiceAccount specs. Option C is wrong because `mountServiceAccountToken: true` is not a valid field; the correct field name is `automountServiceAccountToken`, and the 'mount' prefix is a common misremembering of the actual API field.

Practice this question →

136

MCQhard

A cluster was upgraded from v1.28 to v1.29 using kubeadm. After upgrading the control plane, nodes remain at v1.28. What is the correct next step to upgrade a worker node?

A.Drain the node, then run 'kubeadm upgrade node' on the worker node.

B.SSH into the worker node and run 'kubeadm upgrade node', then upgrade kubelet and kubectl, then restart kubelet.

C.Upgrade kubelet on the worker node using the package manager and restart kubelet.

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

AnswerB

This is the standard procedure for upgrading a worker node with kubeadm.

Why this answer

Option B is correct because after upgrading the control plane with kubeadm, worker nodes must be upgraded individually. The correct sequence is to SSH into the worker node, run 'kubeadm upgrade node' to upgrade the kubelet configuration and static pod manifests, then upgrade the kubelet and kubectl binaries (typically via the package manager), and finally restart the kubelet to pick up the new version. This ensures the node runs the same Kubernetes version as the control plane.

Exam trap

The trap here is that candidates often assume simply upgrading the kubelet binary via the package manager is sufficient, but the CKA exam tests the understanding that 'kubeadm upgrade node' must be run first to update the node's configuration and static pod manifests, ensuring a complete and consistent upgrade.

How to eliminate wrong answers

Option A is wrong because 'kubeadm upgrade node' is the correct command, but draining the node before running it is not strictly required as the first step; the standard procedure is to upgrade the node first, then drain and uncordon as needed for workload migration. Option C is wrong because upgrading only the kubelet binary without running 'kubeadm upgrade node' will not update the node's kubelet configuration or static pod manifests, leading to version mismatches and potential cluster instability. Option D is wrong because 'kubeadm upgrade apply' is used only on the control plane node to upgrade the cluster state; running it on a worker node is invalid and will fail.

Practice this question →

137

MCQmedium

Which kubectl command is used to mark a node as unschedulable for new pods without affecting existing running pods?

A.kubectl cordon <node-name>

B.kubectl uncordon <node-name>

C.kubectl drain <node-name>

D.kubectl taint nodes <node-name> key=value:NoSchedule

AnswerA

Cordon marks the node as unschedulable.

Why this answer

The `kubectl cordon` command marks a node as unschedulable by setting the `node.Spec.Unschedulable` field to `true`. This prevents the Kubernetes scheduler from placing new pods onto the node, while existing pods continue to run unaffected. It is the correct tool for this specific maintenance task.

Exam trap

The trap here is that candidates confuse `kubectl drain` (which evicts pods and then cordons) with `kubectl cordon` (which only prevents new scheduling), leading them to select drain when the question explicitly states 'without affecting existing running pods'.

How to eliminate wrong answers

Option B is wrong because `kubectl uncordon` reverses the effect of cordon, making a previously unschedulable node schedulable again, not marking it unschedulable. Option C is wrong because `kubectl drain` evicts all pods from a node (respecting PodDisruptionBudgets) and then cordons it, which affects existing running pods, not just preventing new ones. Option D is wrong because `kubectl taint nodes ...:NoSchedule` adds a taint that prevents pods without a matching toleration from being scheduled, but it does not mark the node as unschedulable globally; pods with the correct toleration can still be scheduled, and it does not set the `Unschedulable` field.

Practice this question →

138

MCQmedium

You run 'kubectl logs pod-name' and get an error: 'Error from server (Forbidden): pods "pod-name" is forbidden: User "dev-user" cannot list resource "pods/log" in API group "" in the namespace "default"'. What RBAC configuration is missing?

A.A ClusterRole with 'get' on 'pods'

B.A Role with 'get' on 'pods/log' in the 'default' namespace

C.A ClusterRoleBinding for the user to the 'view' ClusterRole

D.A RoleBinding with 'list' on 'pods'

AnswerB

pods/log is a subresource; get permission on it is required to access logs.

Why this answer

The error indicates that the user 'dev-user' is forbidden from listing 'pods/log' in the 'default' namespace. To access pod logs, you need a Role (or ClusterRole) that grants the 'get' verb on the 'pods/log' subresource, scoped to the specific namespace. Option B correctly specifies a Role with 'get' on 'pods/log' in the 'default' namespace, which is the minimal RBAC configuration required to resolve the Forbidden error.

Exam trap

The trap here is that candidates often confuse 'pods' with 'pods/log' and assume that permissions on the parent resource (pods) automatically extend to its subresources (pods/log), but Kubernetes RBAC requires explicit rules for each subresource.

How to eliminate wrong answers

Option A is wrong because a ClusterRole with 'get' on 'pods' grants access to the 'pods' resource, not the 'pods/log' subresource; logs require explicit permission on the subresource. Option C is wrong because the 'view' ClusterRole typically includes 'get' on 'pods' but does not include 'pods/log' (logs are considered a separate subresource with distinct RBAC rules). Option D is wrong because a RoleBinding with 'list' on 'pods' grants the 'list' verb on the 'pods' resource, not the required 'get' verb on the 'pods/log' subresource, and the error specifically demands 'get' on 'pods/log'.

Practice this question →

139

Multi-Selectmedium

You run 'kubectl cordon node1'. Which TWO statements describe the effect of this command? (Choose TWO.)

Select 2 answers

A.The node is removed from the cluster

B.All pods on node1 are deleted

C.Existing pods on node1 are immediately evicted

D.New pods will not be scheduled onto node1

E.The node is marked as unschedulable

AnswersD, E

Cordoning sets the node to unschedulable, so new pods will not be placed.

Why this answer

Option D is correct because `kubectl cordon` marks a node as unschedulable, preventing the Kubernetes scheduler from placing any new pods onto that node. This is achieved by setting the `node.kubernetes.io/unschedulable` taint or the `spec.unschedulable` field to true, which the scheduler checks during pod assignment. Existing pods on the node continue to run normally and are not affected by the cordon operation.

Exam trap

The trap here is that candidates often confuse `cordon` with `drain`, mistakenly thinking that cordon evicts or deletes existing pods, when in fact it only prevents new scheduling.

Practice this question →

140

Multi-Selectmedium

Which THREE of the following are components of the Kubernetes control plane? (Choose THREE.)

Select 3 answers

A.kube-apiserver

B.kube-scheduler

C.etcd

D.kubelet

E.kube-proxy

AnswersA, B, C

The API server is the front-end of the control plane.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API. All administrative tasks and component interactions (e.g., from kubectl, the scheduler, the controller manager) go through the API server, which validates and processes RESTful requests before persisting state to etcd.

Exam trap

CNCF often tests the distinction between control plane components and node-level agents, so candidates mistakenly select kubelet or kube-proxy because they are essential to cluster operation, but they are not part of the control plane itself.

Practice this question →

141

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.

Practice this question →

142

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.

Practice this question →

143

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.

Practice this question →

144

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.

Practice this question →

145

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.

Practice this question →

146

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.

Practice this question →

147

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.

Practice this question →

148

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.

Practice this question →

149

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

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.

Practice this question →

150

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.

Practice this question →