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

151

Multi-Selecthard

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

Select 2 answers

A.ClusterRoleBinding binding the ClusterRole to the ServiceAccount

B.ServiceAccount token secret

C.ClusterRole with rules for pods and services

D.RoleBinding in each namespace

E.Role in the 'monitoring' namespace

AnswersA, C

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

Why this answer

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

Exam trap

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

Practice this question →

152

MCQeasy

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

A.kubectl config merge config1 config2 > merged-config

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

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

D.kubectl merge-config config1 config2

AnswerB

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

153

MCQmedium

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

A.kubectl drain node01

B.kubectl taint nodes node01 key=value:NoSchedule

C.kubectl cordon node01

D.kubectl uncordon node01

AnswerC

cordon marks the node as unschedulable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

154

Multi-Selecteasy

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

Select 2 answers

A.kubectl taint

B.kubectl cordon

C.kubectl delete node

D.kubectl drain

E.kubectl get nodes

AnswersB, D

Why this answer

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

Exam trap

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

Practice this question →

155

MCQmedium

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

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

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

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

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

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

156

Multi-Selecthard

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

Select 3 answers

A.kubelet

B.kube-proxy

C.kube-controller-manager

D.etcd

E.kube-apiserver

AnswersC, D, E

Why this answer

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

Exam trap

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

Practice this question →

157

Multi-Selectmedium

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

Select 2 answers

A.kubectl config set-context my-context

B.kubectl config current-context

C.kubectl config use-context my-context

D.export KUBECONFIG=/path/to/config

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

AnswersC, D

Why this answer

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

Exam trap

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

Practice this question →

158

MCQmedium

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

A.kubectl logs test-pod

B.kubectl describe pod test-pod

C.kubectl exec -it test-pod -- /bin/bash

D.kubectl get events

AnswerB

The describe command shows events and conditions that explain why the pod is pending.

Why this answer

Option B is correct because `kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Exam trap

The trap here is that candidates often assume `kubectl logs` or `kubectl exec` can diagnose startup issues, but these commands only work on running containers, so they fail silently or with errors when the pod is still pending, wasting time and misdirecting troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl logs test-pod` retrieves container logs, but the pod is in 'Pending' state and has not started any containers, so there are no logs to fetch; this command would fail with an error like 'container is waiting to start'. Option C is wrong because `kubectl exec -it test-pod -- /bin/bash` attempts to execute a command inside a running container, but since the pod is not running (Pending), there is no container to attach to, and the command will fail. Option D is wrong because `kubectl get events` shows cluster-wide events, which may include relevant information but is less targeted than `kubectl describe pod`; it requires filtering through many events and may not show pod-specific details like scheduler failure reasons or volume binding errors as clearly.

Practice this question →

159

MCQeasy

Which kubectl command is used to mark a node as unschedulable so that no new pods are scheduled onto it?

A.kubectl taint <node>

B.kubectl uncordon <node>

C.kubectl drain <node>

D.kubectl cordon <node>

AnswerD

Cordon marks the node as unschedulable, preventing new pods from being scheduled.

Why this answer

The `kubectl cordon <node>` command marks a node as unschedulable by setting the `node.Spec.Unschedulable` field to `true`. This prevents the Kubernetes scheduler from placing any new pods onto that node, while existing pods continue to run unaffected. This is the correct command for the described task.

Exam trap

The trap here is confusing `cordon` with `drain`—candidates often pick `drain` because they think it makes the node unschedulable, but `drain` additionally evicts all pods, which is not what the question asks for.

How to eliminate wrong answers

Option A is wrong because `kubectl taint <node>` adds a taint to a node, which repels pods that do not have a matching toleration, but it does not directly make the node unschedulable for all new pods—pods with appropriate tolerations can still be scheduled. Option B is wrong because `kubectl uncordon <node>` does the opposite: it marks a node as schedulable by setting `node.Spec.Unschedulable` to `false`, allowing new pods to be scheduled. Option C is wrong because `kubectl drain <node>` evicts all pods from the node and then cordons it, but the primary action is pod eviction, not merely marking the node unschedulable; it is a more destructive operation that also terminates running workloads.

Practice this question →

160

MCQmedium

A cluster was installed using kubeadm. You need to upgrade the cluster from v1.28 to v1.29. Which of the following is the correct order of operations?

A.Drain each node, upgrade control plane, then upgrade worker nodes

B.Drain control plane node, upgrade kubeadm and kubelet on control plane, uncordon, then repeat for worker nodes

C.Upgrade worker nodes first, then control plane nodes

D.Upgrade all nodes simultaneously

AnswerB

Correct sequence: drain control plane, upgrade, uncordon, then similarly for workers.

Why this answer

Option B is correct because the kubeadm upgrade process requires the control plane node to be upgraded first, as it hosts the core cluster components (API server, scheduler, controller-manager). Draining the node ensures workloads are evicted, then kubeadm and kubelet are upgraded on the control plane, followed by uncordoning. Worker nodes are upgraded afterward to maintain cluster stability and compatibility.

Exam trap

The trap here is that candidates often assume all nodes can be upgraded in any order or simultaneously, but the CKA requires strict sequential upgrade of control plane first, then workers, with drain/uncordon steps.

How to eliminate wrong answers

Option A is wrong because it suggests draining all nodes before upgrading, but the control plane must be upgraded first, not simultaneously with workers. Option C is wrong because upgrading worker nodes before the control plane would break cluster coordination, as the API server version must be higher or equal to kubelet versions. Option D is wrong because upgrading all nodes simultaneously is not supported with kubeadm; it would cause version mismatches and potential cluster downtime.

Practice this question →

161

MCQmedium

A developer wants to create a ServiceAccount named 'app-sa' and mount its token into a pod. Which YAML snippet correctly configures the pod to use this ServiceAccount?

A.spec: serviceAccountName: app-sa automountServiceAccountToken: false

B.spec: serviceAccountName: app-sa automountServiceAccountToken: "true"

C.spec: serviceAccountName: app-sa automountServiceAccountToken: true

D.spec: serviceAccount: app-sa

AnswerC

Correct: serviceAccountName and automountServiceAccountToken true (default).

Why this answer

Option C is correct because it uses the `serviceAccountName` field to assign the 'app-sa' ServiceAccount to the pod and sets `automountServiceAccountToken: true` to explicitly mount the token. By default, Kubernetes mounts the token if `automountServiceAccountToken` is not set, but setting it to `true` ensures the token is mounted even if the ServiceAccount itself has `automountServiceAccountToken: false`.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field with the correct `serviceAccountName` field, or incorrectly use a string value for `automountServiceAccountToken` instead of a boolean, leading to silent failures or unexpected behavior.

How to eliminate wrong answers

Option A is wrong because `automountServiceAccountToken: false` explicitly disables token mounting, which contradicts the requirement to mount the token. Option B is wrong because `automountServiceAccountToken: "true"` uses a string value instead of the required boolean; Kubernetes expects a boolean, and a string may be ignored or cause an error. Option D is wrong because it uses the deprecated `serviceAccount` field instead of `serviceAccountName`; while it might work in older versions, it is not the correct modern syntax and does not include the `automountServiceAccountToken` field.

Practice this question →

162

MCQmedium

A ClusterRole named 'pod-reader' grants get, list, watch on pods. You want to bind it to a user 'john' cluster-wide. Which resource should you create?

A.Role

B.ClusterRoleBinding

C.RoleBinding in default namespace

D.ClusterRole

AnswerB

Correct for cluster-wide binding.

Why this answer

A ClusterRoleBinding is the correct resource because it grants cluster-wide permissions to a user. While a ClusterRole defines the permissions (get, list, watch on pods), a ClusterRoleBinding binds that ClusterRole to a subject (user 'john') across all namespaces. This is the only way to achieve cluster-scoped authorization in Kubernetes RBAC.

Exam trap

The trap here is that candidates often confuse ClusterRole (which defines permissions) with ClusterRoleBinding (which binds them to a user), or mistakenly think a RoleBinding can grant cluster-wide access if used with a ClusterRole.

How to eliminate wrong answers

Option A is wrong because a Role is a namespaced resource that grants permissions only within a specific namespace, not cluster-wide. Option C is wrong because a RoleBinding in the default namespace would only grant the permissions within that namespace, not across the entire cluster. Option D is wrong because a ClusterRole only defines the permissions (rules) but does not bind them to a user; a binding resource (ClusterRoleBinding) is required to associate the ClusterRole with a subject.

Practice this question →

163

MCQeasy

Which command is used to take a snapshot of etcd data for backup?

A.etcdctl export

B.etcdctl backup

C.etcdctl dump

D.etcdctl snapshot save

AnswerD

This command creates a snapshot file of the etcd data store.

Why this answer

The correct command to take a snapshot of etcd data for backup is `etcdctl snapshot save`. This command creates a point-in-time snapshot of the etcd key-value store, which can be used to restore the cluster state. The `snapshot save` subcommand is the official method for backing up etcd data in Kubernetes environments.

Exam trap

The trap here is that candidates may confuse `etcdctl backup` (a legacy v2 command) or `etcdctl dump` (a non-existent command) with the correct `etcdctl snapshot save`, especially since the word 'backup' is intuitive but not the actual command in etcd v3.

How to eliminate wrong answers

Option A is wrong because `etcdctl export` is not a valid subcommand; the correct subcommand for exporting data is `etcdctl get` with a prefix, but that does not create a consistent snapshot. Option B is wrong because `etcdctl backup` is not a valid subcommand; the legacy `etcdctl backup` was used in older etcd v2 but is deprecated and not available in etcd v3, which is the standard for Kubernetes. Option C is wrong because `etcdctl dump` is not a valid subcommand; there is no `dump` command in etcdctl, and it likely confuses with database dump tools.

Practice this question →

164

MCQeasy

Which component is responsible for maintaining network rules on worker nodes?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.kube-controller-manager

AnswerA

kube-proxy maintains network rules.

Why this answer

kube-proxy is the component responsible for maintaining network rules on worker nodes. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates iptables, IPVS, or userspace rules on the node to route traffic to the correct Pods. This ensures that network traffic directed at a Service's ClusterIP or NodePort is properly forwarded to the backend Pods.

Exam trap

The trap here is that candidates often confuse kubelet with kube-proxy because both run on worker nodes, but kubelet manages containers while kube-proxy manages network rules.

How to eliminate wrong answers

Option B (kube-scheduler) is wrong because it is responsible for assigning Pods to nodes based on resource availability and scheduling policies, not for maintaining network rules. Option C (kubelet) is wrong because it is the primary node agent that manages Pod lifecycle, container health, and mounts volumes, but it does not handle network rule enforcement. Option D (kube-controller-manager) is wrong because it runs controller processes such as the Node Controller, Replication Controller, and Endpoint Controller, but it does not implement per-node network rules.

Practice this question →

165

MCQeasy

Which command is used to mark a node as unschedulable and evict its pods?

A.kubectl delete node node-name

B.kubectl cordon node-name

C.kubectl drain node-name --ignore-daemonsets

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

AnswerC

Drain cordons and evicts all pods (except DaemonSets with flag).

Why this answer

Option C is correct because `kubectl drain` marks a node as unschedulable (similar to `cordon`) and then evicts all pods from the node, respecting PodDisruptionBudgets. The `--ignore-daemonsets` flag is required because DaemonSet pods cannot be evicted via drain (they are managed by the DaemonSet controller and would be immediately rescheduled on the same node), so the command would fail without this flag.

Exam trap

CNCF often tests the distinction between `cordon` (only prevents scheduling) and `drain` (prevents scheduling AND evicts pods), and candidates frequently pick `cordon` because they forget that eviction is required for the node to be truly empty for maintenance.

How to eliminate wrong answers

Option A is wrong because `kubectl delete node` removes the node object from the cluster entirely, which does not evict pods gracefully and is not the intended way to perform maintenance. Option B is wrong because `kubectl cordon` only marks the node as unschedulable (prevents new pods from being scheduled) but does not evict existing pods. Option D is wrong because `kubectl taint` with `NoSchedule` prevents new pods from being scheduled on the node but does not evict existing pods; it also does not mark the node as unschedulable in the same way as `cordon` or `drain`.

Practice this question →

166

MCQeasy

You are setting up a new Kubernetes cluster using kubeadm. After running 'kubeadm init', you want to start using the cluster with kubectl. Which of the following commands should you run to configure kubectl for the admin user?

A.mkdir -p $HOME/.kube && sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config

B.sudo kubeadm reset --force

C.sudo cp /etc/kubernetes/admin.conf /root/.kube/config

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

AnswerA

This copies the admin kubeconfig to the user's kubeconfig directory and sets appropriate ownership.

Why this answer

Option A is correct because after running 'kubeadm init', the admin kubeconfig file is generated at /etc/kubernetes/admin.conf. To use kubectl as a regular (non-root) user, you must copy this file to the user's $HOME/.kube/config directory and then change its ownership to the current user. This ensures kubectl can authenticate to the cluster using the admin certificate and key embedded in the config file.

Exam trap

The trap here is that candidates might mistakenly copy the admin.conf to /root/.kube/config (option C) thinking it works for any user, or confuse the admin.conf location with the pki directory (option D), while the correct approach requires copying to the current user's home directory and fixing ownership.

How to eliminate wrong answers

Option B is wrong because 'kubeadm reset --force' is used to tear down a cluster or reinitialize it, not to configure kubectl; running it would destroy the cluster state. Option C is wrong because it copies the admin.conf to /root/.kube/config, which only configures kubectl for the root user, not for the current admin user; the CKA environment typically expects non-root usage. Option D is wrong because it references /etc/kubernetes/pki/admin.conf, which does not exist — the admin kubeconfig is located at /etc/kubernetes/admin.conf, not in the pki directory.

Practice this question →

167

MCQeasy

Which component is responsible for assigning pods to nodes?

A.kube-scheduler

B.kubelet

C.kube-apiserver

D.kube-controller-manager

AnswerA

The scheduler selects a node for each pod based on resource availability and policies.

Why this answer

The kube-scheduler is responsible for assigning pods to nodes based on resource requirements, constraints, and policies. It watches for newly created pods that have no node assignment and selects an optimal node for each pod to run on.

Exam trap

The trap here is that candidates often confuse the kubelet's role of running pods with the scheduler's role of assigning pods to nodes, or think the API server handles scheduling because it processes pod creation requests.

How to eliminate wrong answers

Option B is wrong because kubelet is the agent that runs on each node and ensures containers are running in a pod, but it does not decide which node a pod should be scheduled on. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane and handles API requests, but it does not perform scheduling decisions. Option D is wrong because kube-controller-manager runs controller processes like replication controller and node controller, but pod-to-node assignment is the scheduler's responsibility.

Practice this question →

168

Multi-Selectmedium

Which TWO are true about taints and tolerations? (Select 2)

Select 2 answers

A.Taints prevent all pods from scheduling on a node

B.A node can have multiple taints

C.Taints are applied to pods

D.Tolerations are set on nodes

E.Tolerations allow pods to schedule on tainted nodes

AnswersB, E

Yes.

Why this answer

Option B is correct because a node can indeed have multiple taints applied to it, each with different effects (NoSchedule, PreferNoSchedule, or NoExecute). This allows fine-grained control over pod placement, such as dedicating nodes for specific workloads or isolating sensitive pods. Option E is correct because tolerations are applied to pods and allow them to be scheduled on nodes that have matching taints, effectively overriding the taint's restriction.

Exam trap

The trap here is that candidates often confuse which object (node vs. pod) receives taints versus tolerations, leading them to incorrectly select options C or D.

Practice this question →

169

MCQmedium

A developer wants to run a one-time batch job that processes data and then exits. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

Jobs run a pod until successful completion.

Why this answer

A Job is the correct Kubernetes resource for a one-time batch task that runs to completion and then exits. It ensures a specified number of Pods terminate successfully, making it ideal for processing data and exiting without requiring continuous availability.

Exam trap

The trap here is that candidates often confuse a CronJob with a Job, assuming any batch-like task requires scheduling, but the question explicitly says 'one-time,' which eliminates the need for a schedule.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, providing continuous background services like logging or monitoring, not a one-time batch job. Option B is wrong because a CronJob is used for scheduling recurring tasks at specified times (e.g., every hour), not for a single execution. Option C is wrong because a Deployment manages a set of replica Pods intended to run indefinitely, maintaining a desired state with rolling updates, not a finite task that exits.

Practice this question →

170

MCQeasy

Which component is responsible for running containers on a node and reporting their status to the control plane?

A.kubelet

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

C.kube-proxy

D.kube-scheduler

AnswerA

kubelet is the primary node agent that manages pods and reports node and container status.

Why this answer

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd) to start, stop, and monitor containers. The kubelet then reports the status of the node and its Pods back to the control plane via the Kubernetes API server, using heartbeats (NodeStatus updates) and Pod status updates.

Exam trap

The trap here is that candidates often confuse the container runtime with the kubelet, because both are involved in running containers, but the kubelet is the agent that reports status to the control plane, while the runtime only executes containers locally.

How to eliminate wrong answers

Option B (container runtime) is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually pulling images and managing container lifecycle, but it does not report status to the control plane; the kubelet communicates with the runtime via the CRI (Container Runtime Interface) and then reports to the API server. Option C (kube-proxy) is wrong because kube-proxy is a network proxy that runs on each node, handling network rules for Services (e.g., iptables/IPVS), but it does not manage containers or report their status to the control plane. Option D (kube-scheduler) is wrong because the kube-scheduler runs on the control plane (or master node) and is responsible for assigning Pods to nodes based on resource availability and constraints; it does not run on worker nodes and does not report container status.

Practice this question →

171

MCQmedium

An administrator creates a ServiceAccount named 'monitor' in the 'default' namespace. They want any pod using this ServiceAccount to be able to list pods cluster-wide. Which RBAC resource should be created and bound to this ServiceAccount?

A.ClusterRole and RoleBinding in the default namespace

B.ClusterRole and RoleBinding in kube-system

C.ClusterRole and ClusterRoleBinding

D.Role and RoleBinding in the default namespace

AnswerC

ClusterRoleBinding grants permissions cluster-wide regardless of namespace.

Why this answer

A ClusterRole is required because listing pods cluster-wide is a cluster-scoped operation, not limited to a single namespace. A ClusterRoleBinding is needed to bind the ClusterRole to the ServiceAccount 'monitor' at the cluster level, granting permissions across all namespaces. RoleBindings can only grant permissions within a single namespace, so they cannot achieve cluster-wide access.

Exam trap

The trap here is that candidates often confuse namespace-scoped RoleBindings with cluster-scoped ClusterRoleBindings, assuming a RoleBinding can grant cluster-wide permissions if the Role is a ClusterRole, but the binding type determines the scope of the grant.

How to eliminate wrong answers

Option A is wrong because a RoleBinding can only grant permissions within the namespace where it is created, so it cannot provide cluster-wide pod listing. Option B is wrong because a RoleBinding in kube-system would only grant permissions within the kube-system namespace, not cluster-wide. Option D is wrong because both a Role and a RoleBinding are namespace-scoped, limiting the ServiceAccount to only the default namespace.

Practice this question →

172

MCQmedium

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

A.kubectl logs mypod --previous

B.kubectl exec -it mypod -- sh

C.kubectl delete pod mypod && kubectl create -f mypod.yaml

D.kubectl describe pod mypod

AnswerA

Why this answer

The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

Exam trap

The trap here is that candidates assume `kubectl logs` shows all available logs, forgetting that a crashed container's output is only accessible via the `--previous` flag, leading them to choose `kubectl describe pod` or exec instead.

How to eliminate wrong answers

Option B is wrong because `kubectl exec -it mypod -- sh` attempts to start an interactive shell in a running container, but the pod is in `CrashLoopBackOff` and the container is not running, so exec will fail with an error like 'cannot exec into a container in a crashed state'. Option C is wrong because deleting and recreating the pod will lose the previous container's logs and crash history, making debugging harder; it is a reactive restart, not a diagnostic step. Option D is wrong because `kubectl describe pod mypod` shows pod events and status but does not provide the application-level error output from the crashed container; it is useful for infrastructure issues but not for application crash logs.

Practice this question →

173

MCQhard

You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?

A.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io

B.kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io

C.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io

D.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: default rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io

AnswerA

This correctly creates a namespace-scoped Role and RoleBinding in the 'app' namespace.

Why this answer

Option A is correct because it creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Exam trap

CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly use a ClusterRole when a namespaced Role is sufficient, or misplace the Role in the wrong namespace, thinking the RoleBinding can reference it across namespaces.

How to eliminate wrong answers

Option B is wrong because it uses a ClusterRole and ClusterRoleBinding, which grant permissions cluster-wide (across all namespaces), not just in the 'app' namespace as required. Option C is wrong because it uses a ClusterRole with a RoleBinding; while a RoleBinding can reference a ClusterRole, the binding itself is namespaced, but the ClusterRole's scope is still cluster-wide, which is unnecessarily broad and not the minimal required RBAC for a single namespace. Option D is wrong because the Role is defined in the 'default' namespace, not in the 'app' namespace, so the RoleBinding in 'app' cannot reference a Role from a different namespace; Role and RoleBinding must be in the same namespace.

Practice this question →

174

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

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

B.Delete the namespace and redeploy all workloads

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

D.Increase the CPU request for the container

AnswerA

Directly addresses the OOMKilled cause.

Why this answer

The pod is in a CrashLoopBackOff state with an 'OOMKilled' message, which indicates that the container's memory usage exceeded its configured memory limit, causing the kernel's Out-Of-Memory (OOM) killer to terminate the process. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Exam trap

CNCF often tests the misconception that restarting or recreating the pod will resolve a CrashLoopBackOff caused by resource limits, but the trap here is that the OOMKilled error is a resource constraint issue, not a transient failure, so only adjusting the memory limit or removing the limit will stop the crash loop.

How to eliminate wrong answers

Option B is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime for all workloads in the namespace. Option C is wrong because deleting and recreating the pod will only restart the container with the same memory limit, resulting in the same OOMKilled crash and continued CrashLoopBackOff. Option D is wrong because increasing the CPU request does not affect memory constraints; the OOMKilled error is caused by exceeding the memory limit, not CPU resources.

Practice this question →

175

MCQeasy

Which component on a worker node is responsible for maintaining network rules and enabling service abstraction?

A.kube-scheduler

B.kube-proxy

C.container runtime

D.kubelet

AnswerB

Correct: kube-proxy maintains network rules.

Why this answer

kube-proxy is the component on each worker node that maintains network rules (e.g., iptables, IPVS) and enables service abstraction by proxying traffic to the correct Pods. It watches the Kubernetes API server for Service and EndpointSlice changes, then updates the node's packet filtering rules to route cluster IP traffic to healthy backend Pods.

Exam trap

CNCF often tests the distinction between kubelet (Pod lifecycle) and kube-proxy (network rules), so the trap here is that candidates confuse kubelet's role in managing containers with the network abstraction provided by kube-proxy.

How to eliminate wrong answers

Option A is wrong because kube-scheduler runs on the control plane, not worker nodes, and is responsible for assigning Pods to nodes based on resource requirements, not for maintaining network rules or service abstraction. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for implementing network policies or proxying service traffic. Option D is wrong because kubelet is the primary node agent that manages Pod lifecycle (e.g., ensuring containers are running) and reports node status, but it does not handle network rule maintenance or service proxying.

Practice this question →

176

Multi-Selectmedium

You are applying the following RBAC manifest: --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] Which TWO statements are true about this Role? (Choose TWO.)

Select 2 answers

A.It also grants access to secrets in the 'development' namespace

B.It allows reading pod details in the 'development' namespace

C.It grants permissions across all namespaces

D.It grants permissions only within the 'development' namespace

E.It allows creating pods in the 'development' namespace

AnswersB, D

The verbs 'get', 'watch', 'list' are read operations on pods.

Why this answer

Option B is correct because the Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that namespace.

Exam trap

The trap here is that candidates often confuse a Role with a ClusterRole, mistakenly thinking a Role can grant permissions across all namespaces, or they assume that granting access to 'pods' implicitly grants access to related resources like secrets or logs.

Practice this question →

177

MCQhard

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

A.The pod is missing resource requests.

B.The pod does not tolerate the node's taint.

C.The node is cordoned.

D.The kubelet is not running on the node.

AnswerB

The taint is preventing scheduling unless the pod has a toleration.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node that satisfies its scheduling constraints. The 'kubectl describe pod' output explicitly states that 1 node has a taint (node-role.kubernetes.io/master) that the pod does not tolerate. By default, pods do not tolerate the master taint, so they are not scheduled onto master nodes unless a toleration is added.

This is the direct cause of the pending state.

Exam trap

The trap here is that candidates may confuse taints with node cordoning or resource constraints, but the specific error message about 'taint that the pod didn't tolerate' directly points to a toleration mismatch, not a resource or node readiness issue.

How to eliminate wrong answers

Option A is wrong because missing resource requests would cause the scheduler to fail with a different error message, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option C is wrong because a cordoned node would show 'node(s) were cordoned' or 'node(s) had taint node.kubernetes.io/unschedulable' in the describe output, not a taint about node-role.kubernetes.io/master. Option D is wrong because if the kubelet were not running, the node would show as 'NotReady' and the scheduler would report '0/1 nodes are available: 1 node(s) were not ready', not a taint-related message.

Practice this question →

178

MCQeasy

Which component is responsible for running containers on a Kubernetes node?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.kube-controller-manager

AnswerC

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., Docker, containerd, CRI-O) via the Container Runtime Interface (CRI). It receives Pod specifications from the API server and manages the lifecycle of the containers accordingly.

Exam trap

The trap here is that candidates often confuse the kubelet with the kube-scheduler or kube-controller-manager, thinking that scheduling or managing controllers is equivalent to running containers, but the kubelet is the only component that directly interacts with the container runtime to execute containers on a node.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic to Pods (e.g., via iptables or IPVS), not running containers. Option B is wrong because kube-scheduler is a control plane component that assigns Pods to nodes based on resource availability and constraints, but it does not execute or manage containers on any node. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not directly run containers on nodes.

Practice this question →

179

MCQmedium

You initialize a cluster with 'kubeadm init' and want to join a worker node. What is the correct command to generate the join command?

A.kubeadm token create --print-join-command

B.kubeadm join --token <token> <control-plane>:6443

C.kubeadm init phase upload-config kubelet

D.kubeadm token list

AnswerA

This generates and prints the full join command with token and CA hash.

Why this answer

Option A is correct because `kubeadm token create --print-join-command` generates a new bootstrap token and immediately outputs the full `kubeadm join` command, including the token, control-plane endpoint, and discovery token CA cert hash. This is the recommended way to obtain a ready-to-use join command after initializing the cluster with `kubeadm init`.

Exam trap

The trap here is that candidates often assume `kubeadm token list` (Option D) is sufficient to get the join command, but it only shows existing tokens without the required CA cert hash, leading to an incomplete or insecure join attempt.

How to eliminate wrong answers

Option B is wrong because it is an incomplete join command — it lacks the `--discovery-token-ca-cert-hash` flag, which is required for secure discovery of the control plane's CA certificate. Option C is wrong because `kubeadm init phase upload-config kubelet` only uploads the kubelet configuration to a ConfigMap; it does not generate or print a join command. Option D is wrong because `kubeadm token list` only displays existing tokens without printing the full join command, and it does not create a new token if none exist.

Practice this question →

180

MCQmedium

Which kubeconfig context is currently active?

A.kubectl config view

B.kubectl cluster-info

C.kubectl config get-contexts

D.kubectl config current-context

AnswerD

Directly shows current context.

Why this answer

Option D is correct because `kubectl config current-context` is the dedicated kubectl command that displays the name of the currently active context from the kubeconfig file. The active context determines which cluster, user, and namespace are used by default for kubectl commands, making this the precise way to identify the active context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which shows all contexts with an asterisk on the active one) with a command that directly outputs only the active context, leading them to choose option C instead of the more precise D.

How to eliminate wrong answers

Option A is wrong because `kubectl config view` displays the entire kubeconfig file contents (clusters, users, contexts) but does not explicitly indicate which context is currently active; it requires manual inspection to find the `current-context` field. Option B is wrong because `kubectl cluster-info` shows information about the cluster the current context points to (e.g., control plane endpoints), not the name of the active context itself. Option C is wrong because `kubectl config get-contexts` lists all available contexts and marks the active one with an asterisk (*) in the output, but it does not directly output just the active context name; it requires parsing the list.

Practice this question →

181

MCQmedium

You need to back up etcd data for a cluster running Kubernetes v1.29. Which command correctly creates a snapshot?

A.kubectl etcd snapshot save /backup/snapshot.db

B.etcdctl backup /backup/snapshot.db

C.ETCDCTL_API=2 etcdctl snapshot save /backup/snapshot.db

D.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db

AnswerD

Correct API version and command.

Why this answer

Option D is correct because etcd v3 is the default and supported version in Kubernetes v1.29, and the `ETCDCTL_API=3` environment variable ensures the etcdctl client uses the v3 API, which provides the `snapshot save` command for creating consistent backups. The command `ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db` correctly captures a point-in-time snapshot of the etcd data store, which is essential for disaster recovery.

Exam trap

The trap here is that candidates confuse the deprecated etcd v2 API (which uses `etcdctl backup`) with the v3 API (which uses `etcdctl snapshot save`), and they may forget to set `ETCDCTL_API=3` or incorrectly assume `kubectl` can manage etcd snapshots.

How to eliminate wrong answers

Option A is wrong because `kubectl etcd snapshot save` is not a valid kubectl command; kubectl does not have an `etcd` subcommand—etcd operations must be performed using the etcdctl binary directly. Option B is wrong because `etcdctl backup` is not a valid command in either etcd v2 or v3; the correct command for creating a snapshot is `etcdctl snapshot save`, and the `backup` subcommand does not exist. Option C is wrong because `ETCDCTL_API=2` forces the use of the deprecated etcd v2 API, which does not support the `snapshot save` command—the v2 API only offers `etcdctl backup` (which is a different, less reliable mechanism) and is not compatible with Kubernetes v1.29 clusters that use etcd v3.

Practice this question →

182

MCQmedium

To check the expiration date of all certificates managed by kubeadm, which command should you run?

A.kubectl get certificates

B.kubeadm certs check-expiration

C.kubeadm certs renew

D.kubeadm alpha certs check-expiration

AnswerB

Correct: displays expiration dates of kubeadm-managed certificates.

Why this answer

Option B is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all certificates managed by kubeadm in the cluster. This command reads the certificate files from the default kubeadm certificate directory (typically `/etc/kubernetes/pki`) and parses their `NotAfter` field to show remaining validity.

Exam trap

The trap here is that candidates confuse `kubeadm certs check-expiration` with `kubeadm alpha certs check-expiration` (option D) from older kubeadm versions, or mistakenly think `kubectl` can inspect filesystem certificates (option A), when in fact only the `kubeadm` CLI with the correct subcommand can perform this check.

How to eliminate wrong answers

Option A is wrong because `kubectl get certificates` does not exist; `kubectl` manages Kubernetes API resources, not filesystem certificates, and there is no built-in resource named 'certificates' for this purpose. Option C is wrong because `kubeadm certs renew` is used to renew certificates, not to check their expiration dates; it performs the renewal action but does not display current expiration information. Option D is wrong because `kubeadm alpha certs check-expiration` was a legacy command from older kubeadm versions (pre-1.15) that used the `alpha` subcommand, but the `alpha` prefix was removed in later releases; the correct command is `kubeadm certs check-expiration` without `alpha`.

Practice this question →

183

MCQeasy

Which of the following is NOT a control plane component?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerD

kubelet runs on each node, not the control plane.

Why this answer

The kubelet is the primary node agent that runs on each worker node, not on the control plane. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., containerd or CRI-O). Control plane components are those that manage the cluster's state and scheduling decisions, which run on the control plane nodes.

Exam trap

The trap here is that candidates confuse the kubelet's presence on control plane nodes (since it runs there too) with being a control plane component, but the kubelet is a node agent, not a control plane service.

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 and handling all RESTful requests to validate and configure cluster objects. Option B is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state by watching the API server for changes. Option C is wrong because kube-scheduler is responsible for assigning newly created Pods to nodes based on resource availability, policies, and constraints, making it a core control plane component.

Practice this question →

184

MCQhard

A user reports that they can't authenticate to the cluster using a kubeconfig file. Running 'kubectl config view' shows the current context points to a user with client certificate and key. Which command checks the expiration date of the client certificate?

A.kubeadm upgrade plan --certificate-expiration

B.kubectl config view --raw | grep client-certificate

C.openssl x509 -in /etc/kubernetes/admin.conf -text -noout

D.kubeadm certs check-expiration

AnswerD

This command displays expiration dates for all certificates managed by kubeadm.

Why this answer

Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all PKI certificates in the cluster, including the client certificate used by the user's kubeconfig. This command parses the certificates directly from the `/etc/kubernetes/pki` directory and shows remaining validity, making it the precise tool for this scenario.

Exam trap

The trap here is that candidates confuse the kubeconfig file (a YAML configuration) with a certificate file, leading them to incorrectly use `openssl` directly on the kubeconfig or grep for the certificate data without parsing its expiration.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade plan --certificate-expiration` is not a valid flag; `kubeadm upgrade plan` shows upgrade options, not certificate expiration. Option B is wrong because `kubectl config view --raw | grep client-certificate` only outputs the path or base64-encoded certificate data, not the expiration date; it does not decode or parse the certificate. Option C is wrong because `openssl x509 -in /etc/kubernetes/admin.conf -text -noout` attempts to read a kubeconfig file as a certificate, but `admin.conf` is a YAML file, not a PEM-encoded certificate; the command would fail or produce garbage.

Practice this question →

185

Multi-Selectmedium

Your cluster has three control plane nodes. You suspect the etcd cluster has a leader election issue. Which TWO commands can help diagnose the etcd cluster health and membership? (Choose TWO.)

Select 2 answers

A.etcdctl cluster-status

B.etcdctl version

C.etcdctl endpoint health --cluster

D.etcdctl snapshot save snapshot.db

E.etcdctl member list

AnswersC, E

Checks health of all endpoints in the cluster.

Why this answer

Option C is correct because `etcdctl endpoint health --cluster` queries the health status of all etcd endpoints in the cluster, which directly reveals if any node is unreachable or unhealthy—a common symptom of leader election issues. Option E is correct because `etcdctl member list` displays the current cluster membership, including each member's ID, name, peer URLs, and client URLs, allowing you to verify that all expected control plane nodes are properly joined and that no split-brain or quorum loss has occurred.

Exam trap

The trap here is that candidates may confuse `etcdctl cluster-status` (which does not exist) with the valid `etcdctl endpoint status` command, or they may think snapshot commands are diagnostic tools rather than backup utilities.

Practice this question →

186

MCQhard

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

A.kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db

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

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

D.etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db

AnswerC

This uses the correct API version, endpoint, and certificates to create a snapshot.

Why this answer

Option C is correct because it uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Exam trap

The trap here is that candidates assume 'kubectl exec' into the etcd pod (Option A) is sufficient, but they forget that etcdctl inside the pod still needs explicit TLS flags and endpoint specification, or they mistakenly use an insecure HTTP endpoint (Option D) without realizing that production etcd requires HTTPS.

How to eliminate wrong answers

Option A is wrong because 'kubectl exec' into the etcd container runs etcdctl inside the pod, but it does not automatically provide the necessary TLS certificates or endpoint, and the command lacks the required --cacert, --cert, --key flags, so it will fail to authenticate. Option B is wrong because it runs etcdctl on the host without specifying an endpoint or TLS credentials, so it defaults to the local unix socket or insecure connection, which will not reach the etcd server running as a static pod with TLS enabled. Option D is wrong because it uses an HTTP endpoint (http://localhost:2379) instead of HTTPS, and etcd in a production cluster (including static pods) requires TLS encryption; the connection will be refused or fail authentication.

Practice this question →

187

MCQmedium

You have a kubeconfig file with multiple contexts. How do you switch to the context named 'prod-cluster'?

A.kubectl config set-cluster prod-cluster

B.kubectl config set-context prod-cluster

C.kubectl config view prod-cluster

D.kubectl config use-context prod-cluster

AnswerD

This command sets the current context to prod-cluster.

Why this answer

Option D is correct because `kubectl config use-context` is the command specifically designed to switch the current context in a kubeconfig file. It updates the `current-context` field in the kubeconfig to point to the specified context, which then determines which cluster, user, and namespace are used by default for subsequent `kubectl` commands.

Exam trap

The trap here is that candidates confuse `set-context` (which defines a context) with `use-context` (which activates it), leading them to pick option B instead of D.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-cluster` only modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, it does not change the active context. Option B is wrong because `kubectl config set-context` creates or modifies a context entry (associating a cluster, user, and namespace) but does not switch to it; it only defines the context. Option C is wrong because `kubectl config view` displays the contents of the kubeconfig file (or a merged view) and does not alter the current context.

Practice this question →

188

Multi-Selectmedium

A CKA candidate is troubleshooting a control plane node that was upgraded using kubeadm from v1.28 to v1.29. After the upgrade, the kube-apiserver pod fails to start. Which TWO actions should the candidate take to diagnose and resolve the issue? (Select TWO.)

Select 2 answers

A.Run 'kubeadm upgrade apply v1.29.0' again after resetting the node with 'kubeadm reset'

B.Downgrade etcd to a version compatible with Kubernetes 1.28

C.Immediately upgrade the worker nodes to match the control plane version

D.Check the kubelet logs on the control plane node using 'journalctl -u kubelet'

E.Run 'kubeadm upgrade plan' to verify the target version

AnswersA, D

Resetting the node cleans up previous state and allows a fresh upgrade application.

Why this answer

Option A is correct because if the kube-apiserver pod fails to start after a kubeadm upgrade, a clean re-application of the upgrade using 'kubeadm upgrade apply v1.29.0' after resetting the node with 'kubeadm reset' can resolve corrupted or mismatched configuration files, certificates, or static pod manifests. This process reinitializes the control plane components from scratch while preserving the target version, ensuring all manifests and certificates are regenerated correctly.

Exam trap

The trap here is that candidates may think 'kubeadm upgrade plan' (Option E) is a diagnostic step for a failed upgrade, but it only validates the upgrade path before execution and does not troubleshoot a post-upgrade failure.

Practice this question →

189

MCQhard

A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?

A.Create a ClusterRole with 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa

B.Add the ServiceAccount to the cluster-admin group

C.Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

D.Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

AnswerD

Why this answer

Option D is correct because a Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

Exam trap

The trap here is that candidates often confuse the scope of Roles versus ClusterRoles, mistakenly using a ClusterRole when a namespace-scoped Role is sufficient, or creating a Role in the wrong namespace and assuming a RoleBinding can bridge namespaces.

How to eliminate wrong answers

Option A is wrong because a ClusterRole with 'get' and 'list' verbs on pods, bound via a ClusterRoleBinding, would grant these permissions cluster-wide (across all namespaces), which is excessive for a requirement limited to the 'monitoring' namespace. Option B is wrong because adding the ServiceAccount to the 'cluster-admin' group grants full cluster-wide administrative privileges, violating the principle of least privilege and far exceeding the need to only list pods. Option C is wrong because a Role created in the 'default' namespace cannot grant permissions in the 'monitoring' namespace; RoleBindings only apply within the namespace of the Role, so the binding in 'monitoring' would have no effect.

Practice this question →

190

MCQmedium

A developer created a ClusterRole named 'pod-reader' with rules to get and list pods. They created a ClusterRoleBinding 'read-pods-global' binding this ClusterRole to a service account 'sa-pod-reader' in the 'default' namespace. Which of the following is true about the permissions of this service account?

A.The service account can only read pods in the 'default' namespace

B.The service account can read pods in all namespaces

C.The service account can only list pods, not get them

D.The service account cannot read pods in any namespace

AnswerB

A ClusterRoleBinding grants the ClusterRole's permissions across all namespaces.

Why this answer

ClusterRoleBindings are cluster-scoped, meaning they grant permissions across all namespaces. Since the ClusterRoleBinding 'read-pods-global' binds the 'pod-reader' ClusterRole to the service account 'sa-pod-reader', the service account can get and list pods in every namespace, not just the 'default' namespace.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, mistakenly thinking the service account's permissions are limited to the namespace where the binding or the service account is defined.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding grants permissions cluster-wide, not limited to the namespace of the service account or the binding. Option C is wrong because the ClusterRole 'pod-reader' includes both 'get' and 'list' verbs, so the service account can perform both operations. Option D is wrong because the binding successfully grants the permissions defined in the ClusterRole, so the service account can read pods in all namespaces.

Practice this question →

191

MCQeasy

Which control plane component stores the entire cluster state?

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.etcd

AnswerD

etcd stores cluster state.

Why this answer

The correct answer is etcd because it is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects, configurations, and secrets. The kube-apiserver is the only component that directly interacts with etcd, but it does not store the state itself—it reads from and writes to etcd on behalf of other components.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage layer because it is the only component that interacts with etcd, but the apiserver is merely a gateway and does not persist data itself.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the kube-apiserver and makes changes to move the current state toward the desired state, but it does not store the cluster state. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it reads node and pod information from the kube-apiserver but does not persist any state. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes RESTful API requests, but it is stateless and relies on etcd for persistent storage of the cluster state.

Practice this question →

192

MCQmedium

After upgrading the control plane using kubeadm, you need to update the kubelet configuration on the node. Which command should you run on the node?

A.kubeadm upgrade apply

B.kubectl upgrade node

C.kubeadm upgrade node

D.kubeadm upgrade plan

AnswerC

Correct command to upgrade node configuration.

Why this answer

Option C is correct because `kubeadm upgrade node` is the command used on worker nodes (or secondary control-plane nodes) after the primary control plane has been upgraded. It upgrades the kubelet configuration and other node-specific components to match the new cluster version, ensuring the node can rejoin the upgraded cluster.

Exam trap

The trap here is that candidates confuse `kubeadm upgrade apply` (for the first control-plane node) with `kubeadm upgrade node` (for worker nodes), or they invent a non-existent `kubectl upgrade node` command because they expect kubectl to manage node upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade apply` is run on the first control-plane node to initiate the cluster upgrade, not on a worker node to update its kubelet configuration. Option B is wrong because `kubectl upgrade node` is not a valid kubectl command; kubectl does not have an 'upgrade' subcommand for nodes. Option D is wrong because `kubeadm upgrade plan` is used to check available versions and plan the upgrade, not to perform the actual upgrade or update kubelet configuration on a node.

Practice this question →

193

MCQmedium

An administrator runs 'kubectl get pods' and sees a pod in 'Pending' state. The output of 'kubectl describe pod pod-name' shows '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate'. What is the most likely cause?

A.The pod's container image is not found

B.The node has a taint that repels the pod, and the pod lacks the corresponding toleration

C.The pod has a resource request that exceeds available resources

D.The pod's namespace does not exist

AnswerB

Taints with NoSchedule effect prevent scheduling unless tolerated.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that satisfies the pod's scheduling constraints. The 'kubectl describe pod' output explicitly states '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate', which means the node has a taint (e.g., a key-value pair with an effect like NoSchedule) and the pod does not have a matching toleration in its spec. This prevents the pod from being scheduled onto that node, leaving it stuck in Pending.

Exam trap

CNCF often tests the distinction between taints/tolerations and node affinity/anti-affinity — candidates may confuse the 'taint that the pod didn't tolerate' message with a resource shortage or node selector issue, but the exact phrase in 'kubectl describe' is the key diagnostic clue.

How to eliminate wrong answers

Option A is wrong because a missing container image would cause the pod to enter 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending' — the pod would be scheduled first, then fail at the container runtime level. Option C is wrong because insufficient resources (e.g., CPU/memory requests exceeding node capacity) would produce a different scheduler message like '0/1 nodes are available: 1 Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option D is wrong because a non-existent namespace would cause the pod creation to fail immediately with an error like 'namespaces "x" not found' when running 'kubectl run' or 'kubectl apply', not a 'Pending' state after the pod object exists.

Practice this question →

194

MCQmedium

You need to restore an etcd snapshot taken with 'etcdctl snapshot save'. You have a single control plane node. Which sequence of commands is correct?

A.Run 'etcdctl import /backup/snapshot.db' and restart the API server

B.Stop the API server, run 'etcdctl snapshot restore /backup/snapshot.db --data-dir /var/lib/etcd-restored', then start etcd with the restored data

C.Stop the API server, run 'etcdctl restore /backup/snapshot.db', then restart etcd

D.Run 'etcdctl snapshot restore /backup/snapshot.db' while etcd is running, then restart etcd

AnswerB

This is the standard restore process.

Why this answer

Option B is correct because restoring an etcd snapshot requires stopping the API server first to prevent data corruption, then using 'etcdctl snapshot restore' to create a new data directory, and finally starting etcd with the restored data. The API server depends on etcd, so it must be stopped before the restore, and the restored data directory must be specified to avoid overwriting the existing etcd data.

Exam trap

The trap here is that candidates confuse the 'snapshot restore' command with a generic 'restore' command, or assume the API server can remain running during the restore, leading to corruption or invalid command choices.

How to eliminate wrong answers

Option A is wrong because 'etcdctl import' is not a valid command; the correct command is 'etcdctl snapshot restore', and the API server should be stopped before restoring, not restarted after. Option C is wrong because 'etcdctl restore' is not a valid command; the correct subcommand is 'etcdctl snapshot restore', and the restored data directory must be explicitly specified with '--data-dir'. Option D is wrong because restoring a snapshot while etcd is running can cause data corruption or inconsistency; etcd must be stopped before performing the restore.

Practice this question →

195

MCQmedium

A kubeadm cluster was initialized with a custom certificate validity. You need to check the expiration date of the kube-apiserver certificate. Which command should you use?

A.kubeadm alpha certs check-expiration

B.kubectl get secret -n kube-system

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

D.kubeadm certs check-expiration

AnswerD

Why this answer

Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command introduced in v1.20+ to display the expiration dates of all certificates managed by kubeadm, including the kube-apiserver certificate. This command reads the certificate files from `/etc/kubernetes/pki/` and outputs the remaining validity period in a human-readable format, making it the standard and recommended way to check certificate expiration in a kubeadm cluster.

Exam trap

The trap here is that candidates often confuse the deprecated `kubeadm alpha certs check-expiration` (option A) with the stable `kubeadm certs check-expiration` (option D), or they assume that any generic certificate inspection tool like `openssl` (option C) is the correct answer, ignoring the kubeadm-specific context of the question.

How to eliminate wrong answers

Option A is wrong because `kubeadm alpha certs check-expiration` uses the deprecated `alpha` subcommand, which was removed in kubeadm v1.20; the correct command is `kubeadm certs check-expiration` without `alpha`. Option B is wrong because `kubectl get secret -n kube-system` retrieves Kubernetes secrets (e.g., for service accounts or bootstrap tokens), not the raw certificate files; it does not parse or display certificate expiration dates. Option C is wrong because while `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates` can technically show the certificate dates, it is not the kubeadm-specific command the question asks for, and the path may vary in custom setups; the question explicitly references a kubeadm cluster initialized with custom certificate validity, so the kubeadm tool is the appropriate choice.

Practice this question →

196

MCQhard

You run 'kubeadm certs check-expiration' and see that the 'apiserver' certificate expires in 30 days. What is the correct way to renew just that certificate using kubeadm?

A.kubeadm alpha certs renew apiserver

B.kubeadm certs renew apiserver

C.kubeadm init phase certs apiserver --renew

D.kubectl create certificate apiserver

AnswerB

Renews the specific certificate.

Why this answer

Option B is correct because `kubeadm certs renew apiserver` is the standard command in modern kubeadm (v1.15+) to renew a specific certificate without affecting others. It regenerates the apiserver certificate using the existing CA key, updating the expiration date while keeping the same Subject and SANs.

Exam trap

The trap here is that candidates confuse the deprecated `kubeadm alpha` subcommand with the current `kubeadm certs` subcommand, or mistakenly think `kubectl` can manage kubeadm certificates, leading them to pick options that are either outdated or nonexistent.

How to eliminate wrong answers

Option A is wrong because `kubeadm alpha certs renew` was deprecated in v1.15 and removed in v1.20; the `alpha` subcommand no longer exists in current kubeadm versions. Option C is wrong because `kubeadm init phase certs apiserver --renew` is not a valid command; `kubeadm init phase` is used for generating certificates during initial cluster setup, not for renewal, and there is no `--renew` flag. Option D is wrong because `kubectl create certificate apiserver` does not exist; `kubectl` manages Kubernetes resources, not certificate renewal, and the apiserver certificate is a file-based X.509 certificate managed by kubeadm, not a Kubernetes API object.

Practice this question →

197

MCQmedium

You need to allow a specific user to create and manage deployments in the 'development' namespace only. Which RBAC resources should you create?

A.ClusterRole and ClusterRoleBinding

B.Role and ClusterRoleBinding

C.Role and RoleBinding

D.ClusterRole and RoleBinding

AnswerC

A Role defines permissions within a namespace, and a RoleBinding grants those permissions to a user in that namespace.

Why this answer

Option C is correct because a Role grants permissions within a specific namespace, and a RoleBinding binds that Role to a user or service account within the same namespace. To restrict a user to creating and managing deployments only in the 'development' namespace, you need a Role (scoped to that namespace) and a RoleBinding (also scoped to that namespace). ClusterRole and ClusterRoleBinding are cluster-scoped and would grant permissions across all namespaces, which is not desired here.

Exam trap

CNCF often tests the distinction between namespace-scoped and cluster-scoped resources, and the trap here is that candidates mistakenly think a ClusterRole is required for any 'management' task, or they confuse the scope of RoleBinding vs ClusterRoleBinding, leading them to pick options that grant permissions beyond the intended namespace.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is cluster-scoped and, when combined with a ClusterRoleBinding, grants permissions across all namespaces, not just the 'development' namespace. Option B is wrong because a Role is namespace-scoped, but a ClusterRoleBinding is cluster-scoped; this combination would either fail (if the Role is referenced by a ClusterRoleBinding, which is not allowed) or require a ClusterRole, making the Role irrelevant. Option D is wrong because a ClusterRole is cluster-scoped, and while a RoleBinding can bind it to a namespace, the ClusterRole itself still has cluster-wide scope; using a ClusterRole here is unnecessary and could grant unintended permissions if not carefully scoped, whereas a simple Role is the correct namespace-scoped resource.

Practice this question →

198

MCQeasy

Which kubeconfig context field defines the set of users, clusters, and namespaces for kubectl operations?

A.contexts

B.namespaces

C.clusters

D.users

AnswerA

Contexts group cluster, user, and namespace.

Why this answer

The `contexts` field in a kubeconfig file defines a named context that bundles together a specific cluster, user, and default namespace. When you run `kubectl` commands, the current context determines which cluster to authenticate against, which user credentials to use, and which namespace to operate in by default. This is why option A is correct.

Exam trap

The trap here is that candidates confuse the `contexts` field with the `current-context` field or think that `namespaces`, `clusters`, or `users` individually define the full operational scope, when in fact only the context object combines all three.

How to eliminate wrong answers

Option B (namespaces) is wrong because a namespace is a Kubernetes resource that provides scope for objects within a cluster, not a kubeconfig field that defines the set of users, clusters, and namespaces. Option C (clusters) is wrong because the `clusters` field in kubeconfig only defines cluster endpoints and certificate authority data, not the user or namespace binding. Option D (users) is wrong because the `users` field only stores client credentials (e.g., client certificates, tokens), not the cluster or namespace association.

Practice this question →

199

MCQhard

You need to back up the etcd database for a kubeadm-created cluster. Which directory contains the etcd data?

A./etc/kubernetes/pki/etcd

B./var/lib/etcd

C./var/lib/kubelet

D./etc/etcd

AnswerB

Default etcd data directory.

Why this answer

For a kubeadm-created cluster, etcd runs as a static Pod, and its data directory is mounted from the host path `/var/lib/etcd`. This is the default data directory used by etcd when started via kubeadm, and it stores all cluster state and configuration data. The CKA exam expects you to know this path for backup and restore operations.

Exam trap

The trap here is that candidates confuse the etcd data directory with the certificate directory (`/etc/kubernetes/pki/etcd`) because both are etcd-related and located under `/etc/kubernetes`, but only the data directory holds the actual database files.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/pki/etcd` contains the TLS certificates and keys for etcd communication, not the database files. Option C is wrong because `/var/lib/kubelet` is the kubelet's working directory for pod volumes, plugin state, and other kubelet data, not etcd data. Option D is wrong because `/etc/etcd` is not a standard directory in a kubeadm cluster; etcd configuration is typically embedded in the static Pod manifest or passed as command-line arguments, not stored in a dedicated `/etc/etcd` directory.

Practice this question →

200

MCQmedium

An administrator needs to grant a service account 'sa-monitor' in namespace 'monitoring' the ability to read pods and services cluster-wide. Which RBAC configuration is correct?

A.Create a Role with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring

B.Create a ClusterRole with rules for pods and services (verbs: create) and a ClusterRoleBinding binding it to sa-monitor

C.Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a ClusterRoleBinding binding it to sa-monitor

D.Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring

AnswerC

ClusterRole + ClusterRoleBinding grants cluster-wide permissions.

Why this answer

Option C is correct because the service account 'sa-monitor' needs to read pods and services across all namespaces (cluster-wide). A ClusterRole with verbs get, watch, list for pods and services, combined with a ClusterRoleBinding, grants these permissions cluster-wide, which is the only way to achieve cross-namespace read access for a service account.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, thinking a ClusterRole bound via a RoleBinding still grants cluster-wide access, but in reality, the RoleBinding scopes the permissions to its namespace.

How to eliminate wrong answers

Option A is wrong because a Role and RoleBinding are namespace-scoped and cannot grant permissions cluster-wide; they would only apply within the 'monitoring' namespace. Option B is wrong because it uses the verb 'create' instead of 'get, watch, list', which grants write access (create) rather than read access; also, the requirement is to read, not create resources. Option D is wrong because a ClusterRole bound with a RoleBinding only grants permissions within the namespace of the RoleBinding, not cluster-wide, defeating the purpose of the ClusterRole.

Practice this question →

201

Multi-Selecthard

Which THREE of the following are valid methods to configure a pod to use a specific ServiceAccount? (Select THREE.)

Select 3 answers

A.Create a ClusterRoleBinding that binds the ServiceAccount to a ClusterRole

B.Set spec.serviceAccountName in the pod spec

C.Set spec.template.spec.serviceAccountName in a Deployment

D.Set automountServiceAccountToken: false and manually mount the token as a volume

E.Use the serviceAccount field in the pod spec

AnswersB, C, D

Directly sets the ServiceAccount for the pod.

Why this answer

Option B is correct because setting `spec.serviceAccountName` in a Pod spec directly assigns a specific ServiceAccount to that Pod. When the Pod is created, the API server uses this field to bind the ServiceAccount's token and permissions to the Pod's containers, overriding the default 'default' ServiceAccount in the namespace.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field (which still exists in older documentation) with the correct `serviceAccountName` field, or think that a ClusterRoleBinding directly assigns a ServiceAccount to a Pod, when it only grants permissions to that ServiceAccount.

Practice this question →

202

MCQeasy

Which of the following is a core control plane component of Kubernetes?

A.kubelet

B.CoreDNS

C.kube-apiserver

D.CRI-O

AnswerC

The kube-apiserver is the front-end of the Kubernetes control plane and exposes the API.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the only component that directly interacts with the etcd datastore. It validates and processes all REST API requests, making it the core control plane component responsible for exposing the Kubernetes API and managing the cluster state.

Exam trap

The trap here is that candidates often confuse node-level components (kubelet, CRI-O) or cluster add-ons (CoreDNS) with core control plane components, because all are essential for a working cluster but only the kube-apiserver, kube-controller-manager, kube-scheduler, and etcd are considered core control plane components.

How to eliminate wrong answers

Option A is wrong because kubelet is a node-level agent that runs on each worker node, not a control plane component; it communicates with the API server to ensure containers are running in pods. Option B is wrong because CoreDNS is a cluster add-on that provides DNS-based service discovery, but it is not part of the core control plane (it runs as a Deployment in the kube-system namespace). Option D is wrong because CRI-O is a container runtime interface implementation that runs on nodes to manage containers, not a control plane component.

Practice this question →

203

Multi-Selecteasy

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

Select 2 answers

A.etcd

B.kubelet

C.kube-proxy

D.container runtime

E.kube-apiserver

AnswersA, E

etcd is the store for cluster state.

Why this answer

etcd is a distributed key-value store that holds the cluster's state and configuration data. It is a core component of the Kubernetes control plane because the kube-apiserver reads from and writes to etcd to maintain cluster consistency, and without it the control plane cannot function.

Exam trap

The trap here is that candidates often confuse node-level components like kubelet and kube-proxy with control plane components, because they are essential for cluster operation but run on worker nodes, not on the control plane nodes.

Practice this question →

204

MCQeasy

Which command creates a kubeconfig file that can be used to authenticate as a specific user?

A.kubectl config set-context

B.kubectl config set-credentials

C.kubectl config create-user

D.kubectl config set-cluster

AnswerB

set-credentials adds a user with authentication details.

Why this answer

The `kubectl config set-credentials` command creates or updates a user entry in a kubeconfig file, allowing you to specify authentication credentials such as a client certificate, token, or username/password for a specific user. This is the correct way to define a user identity that can later be associated with a context via `kubectl config set-context`.

Exam trap

The trap here is that candidates confuse `set-credentials` with `set-context`, thinking that creating a context automatically includes user credentials, when in fact the user must be defined separately before being referenced in a context.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-context` only defines a context (cluster, namespace, and user association) but does not create or store user credentials. Option C is wrong because `kubectl config create-user` is not a valid kubectl command; kubectl does not have a `create-user` subcommand. Option D is wrong because `kubectl config set-cluster` only configures cluster details (e.g., server URL, CA certificate) and has nothing to do with user authentication.

Practice this question →

205

MCQeasy

Which component is responsible for running containers on a node?

A.kubelet

B.kube-scheduler

C.container runtime

D.kube-proxy

AnswerC

The container runtime actually runs the containers.

Why this answer

The container runtime is the software responsible for actually running containers on a node. It pulls container images, creates container namespaces, and manages the container lifecycle (start, stop, delete). In Kubernetes, the kubelet delegates container execution to the container runtime via the CRI (Container Runtime Interface), but the runtime itself performs the low-level operations using technologies like runc or containerd.

Exam trap

The trap here is that candidates often confuse the kubelet's role as the node agent with the actual execution of containers, but the kubelet only orchestrates the runtime — it does not run containers itself.

How to eliminate wrong answers

Option A is wrong because the kubelet is the node agent that communicates with the control plane and manages pod lifecycle, but it does not directly run containers — it instructs the container runtime to do so. Option B is wrong because the kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, not a component that runs containers on a node. Option D is wrong because kube-proxy is a network proxy that maintains network rules and handles service-to-pod traffic routing on each node, not container execution.

Practice this question →

206

Multi-Selecthard

Which THREE are valid methods to restore an etcd cluster from a snapshot? (Select 3)

Select 3 answers

A.Restore snapshot on a new node and add it as a member, then remove old

B.kubeadm reset and re-init

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

D.Stop etcd, replace data directory with restored snapshot, start etcd

E.kubectl apply -f snapshot.yaml

AnswersA, C, D

Common procedure.

Why this answer

Option A is correct because it describes the standard procedure for replacing a failed etcd member using a snapshot: you restore the snapshot on a new node (using `etcdctl snapshot restore`), start the new etcd instance, add it as a member to the existing cluster, and then remove the old, failed member. This ensures the new node joins with the correct data and the cluster quorum is maintained.

Exam trap

The trap here is that candidates often think `kubeadm reset` followed by `kubeadm init` can restore an etcd snapshot, but this actually creates a brand-new cluster with no prior data, while the correct method involves restoring the snapshot into a separate directory and then adding the node as a new member.

Practice this question →

207

MCQeasy

Which of the following is a core control plane component responsible for persisting cluster state?

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerD

etcd is the consistent and highly-available key-value store for cluster data.

Why this answer

etcd is the core control plane component responsible for persisting cluster state. It is a distributed, consistent key-value store that stores all cluster data, including configuration, state, and metadata. The kube-apiserver is the only component that interacts directly with etcd, ensuring that all state changes are recorded durably.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage component because it is the only component that talks to etcd, but the actual persistence layer is etcd itself.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the API and validates requests, but it does not persist data itself; it reads from and writes to etcd. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option C is wrong because kube-controller-manager runs controller processes that regulate cluster state (e.g., ensuring desired replicas), but it relies on the API server to read/write state from etcd and does not persist data directly.

Practice this question →

208

MCQhard

A Pod is stuck in Pending state. Running 'kubectl describe pod' shows '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 2 node(s) had taint {node-role.kubernetes.io/master: }'. The Pod does not have tolerations. What is the most likely cause?

A.The scheduler is not running.

B.The Pod requests more CPU than any node can provide.

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

D.The Pod does not have tolerations for the control-plane or master taints.

AnswerD

The nodes have taints that repel Pods without matching tolerations.

Why this answer

The Pod is stuck in Pending state because it does not have tolerations for the taints present on the nodes. The error message explicitly states that 1 node has the control-plane taint and 2 nodes have the master taint. By default, Pods without matching tolerations cannot be scheduled onto tainted nodes.

Since all available nodes are tainted, the scheduler has no eligible node to place the Pod, leaving it in Pending.

Exam trap

The trap here is that candidates may confuse taints/tolerations with node selectors or resource constraints, but the error message explicitly lists taints as the reason, making it a direct match to the toleration requirement.

How to eliminate wrong answers

Option A is wrong because if the scheduler were not running, the Pod would remain in Pending with a different error message (e.g., 'no matching node' or 'scheduler error'), not the specific taint-based message shown. Option B is wrong because the error message does not mention insufficient CPU or memory; it explicitly lists taints as the reason for node unavailability. Option C is wrong because the error message does not mention a node selector mismatch; if a node selector were the issue, the message would indicate '0/3 nodes are available: 3 node(s) didn't match node selector', not taint-related messages.

Practice this question →

209

MCQmedium

You need to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. After upgrading the control plane, what should you do on each worker node?

A.kubeadm upgrade node config --kubelet-version v1.29.0

B.kubectl delete node <node>; kubeadm upgrade node

C.kubectl drain <node>; kubeadm upgrade node; kubectl uncordon <node>

D.kubeadm upgrade node; kubectl uncordon <node>

AnswerC

Drain the node, upgrade, then uncordon.

Why this answer

Option C is correct because the standard kubeadm upgrade workflow for worker nodes requires first draining the node to safely evict all pods, then running 'kubeadm upgrade node' to upgrade the kubelet and kube-proxy configuration, and finally uncordoning the node to make it schedulable again. This sequence ensures minimal disruption to workloads and follows the official Kubernetes upgrade documentation.

Exam trap

The trap here is that candidates may assume 'kubeadm upgrade node' alone handles pod eviction, but it only upgrades the node's components and does not automatically drain pods, making the drain step essential to avoid workload disruption.

How to eliminate wrong answers

Option A is wrong because 'kubeadm upgrade node config --kubelet-version v1.29.0' is not a valid command; kubeadm does not support a --kubelet-version flag for the upgrade node subcommand, and the correct approach is to use 'kubeadm upgrade node' which automatically handles the kubelet configuration. Option B is wrong because deleting the node object with 'kubectl delete node' is unnecessary and disruptive; it removes the node from the cluster's control plane, requiring re-registration, whereas the correct process uses drain and uncordon to maintain node membership. Option D is wrong because it omits the critical 'kubectl drain' step before upgrading the node; upgrading without draining can cause running pods to be terminated abruptly, leading to service disruption and potential data loss.

Practice this question →

210

Multi-Selectmedium

You need to create a Kubernetes ServiceAccount named 'build-bot' and ensure that pods using this ServiceAccount can authenticate to the Kubernetes API using a long-lived token. Which TWO steps are necessary? (Choose TWO.)

Select 2 answers

A.Create a Secret of type 'Opaque' with the token data

B.Run 'kubectl create token build-bot'

C.Use the TokenRequest API to generate a token

D.Create a ServiceAccount object named 'build-bot'

E.Create a Secret with type 'kubernetes.io/service-account-token' and reference the ServiceAccount via annotation

AnswersD, E

The ServiceAccount must exist first.

Why this answer

Option D is correct because creating a ServiceAccount named 'build-bot' is the foundational step; without the ServiceAccount object, no pods can be assigned a service account identity. Option E is correct because a Secret of type 'kubernetes.io/service-account-token' with an annotation referencing the ServiceAccount causes the Kubernetes controller manager to automatically generate and populate a long-lived token, which pods can mount and use to authenticate to the API server.

Exam trap

CNCF often tests the distinction between long-lived tokens (created via the legacy Secret-based mechanism) and short-lived tokens (generated via the TokenRequest API or 'kubectl create token'), leading candidates to incorrectly select options that produce ephemeral credentials.

Practice this question →

211

Multi-Selecteasy

Which TWO commands can be used to check the expiration of certificates managed by kubeadm?

Select 2 answers

A.kubeadm upgrade plan

B.kubectl get certificates

C.openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity

D.kubeadm certs renew --all

E.kubeadm certs check-expiration

AnswersC, E

Directly inspects certificate file validity period.

Why this answer

Option C is correct because `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity` directly reads the X.509 certificate file on disk and displays its validity period (Not Before and Not After dates). This is a manual, low-level method to check certificate expiration without relying on kubeadm utilities. Option E is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command that lists all certificates managed by kubeadm along with their remaining validity, providing a comprehensive and automated check.

Exam trap

The trap here is that candidates confuse `kubeadm certs renew --all` (which performs renewal) with `kubeadm certs check-expiration` (which only checks expiration), or they mistakenly think `kubectl get certificates` is a valid command for checking kubeadm-managed certificates, when in fact Kubernetes has a `CertificateSigningRequest` resource but not a generic `certificates` resource for PKI files.

Practice this question →