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

MCQhard

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

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

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

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

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

AnswerA

A Kubernetes Secret, including one used for image pull credentials, must reside in the same namespace as the Pod that attempts to consume it. While this is a fundamental requirement for secret access, the primary issue indicated by the correct answer is that the ServiceAccount itself isn't configured to *use* any image pull secret. Therefore, the error would not specifically point to a cross-namespace secret issue, but rather a lack of credentials being presented at all.

Why this answer

Secrets in Kubernetes are namespace-scoped. When you configure `imagePullSecrets` on a ServiceAccount, the ServiceAccount admission controller automatically injects these secrets into any Pod referencing that ServiceAccount. However, because Secrets are namespace-scoped, the secret must exist in the same namespace as the ServiceAccount and the Pod.

If the secret was created in a different namespace, the Pod will fail to pull the image with an authentication error (ImagePullBackOff).

Exam trap

Candidates often forget that Secrets are namespace-scoped. Even if a ServiceAccount correctly references an image pull secret by name, the secret must be created in the same namespace as the ServiceAccount and the Pod using it.

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config current-context

D.kubectl config view

AnswerC

kubectl config current-context is the dedicated subcommand that reads the kubeconfig file and prints the name of the currently active context to standard output. It returns exactly one line—the context name—with no additional formatting, making it ideal for scripting and automation. This directly satisfies the admin's need to view the current context, so it is the correct command.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Client certificate

B.ServiceAccount token

C.Secrets

D.RBAC

E.Node authorization

AnswersA, B

Kubernetes authenticates users via X.509 client certificates presented during the TLS handshake. The certificate's Common Name (CN) is mapped to the username, and organization fields become groups. This is a primary method for external users and components like the kubelet to authenticate to the API server.

Why this answer

Option A (Client certificate) is correct because the Kubernetes API server natively supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O fields become group memberships. Option B (ServiceAccount token) is correct because pods authenticate to the API server using automatically mounted ServiceAccount tokens (JWTs) presented as Bearer tokens, validated by the API server against the service account signing key. Option C (Secrets) is not an authentication method itself — Secrets are objects that may store credentials such as tokens, but they do not authenticate a client to the API server.

Option D (RBAC) is an authorization mechanism that determines what an authenticated identity may do, not how it proves its identity. Option E (Node authorization) is an authorization mode (Node authorizer) that governs what kubelets may access, not an authentication method.

Exam trap

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerC

The admin.conf file holds the cluster's certificate authority data and admin credentials, so copying it into the regular user's $HOME/.kube/config gives kubectl the endpoint and authentication it needs. This satisfies the requirement to let kubectl communicate with the freshly initialised cluster.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.kubeadm certs renew apiserver

B.kubeadm certs check-expiration

C.kubeadm certs renew all

D.kubeadm upgrade apply

AnswerC

This is the correct command to renew all control plane certificates managed by kubeadm at once. It automatically regenerates the certificates under the PKI directory and updates the embedded client certificates within the administrative kubeconfig files.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selecthard

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

Select 2 answers

A.etcdctl endpoint health

B.etcdctl snapshot save backup.db

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

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

E.etcdctl snapshot status snapshot.db

AnswersC, D

After restoring a snapshot to a new directory, you must point etcd at that directory by modifying the --data-dir flag or the corresponding etcd manifest environment variable. If you omit this step, etcd will start using its original data directory and the restored data will be ignored. Additionally, you may need to update the --initial-cluster and --initial-cluster-token to match the restore's --name and new cluster ID to avoid conflicts.

Why this answer

Option D is correct because 'etcdctl snapshot restore snapshot.db --data-dir=/var/lib/etcd-restore' is the actual command that rebuilds the etcd data directory from the saved snapshot, writing a fresh member's data into the specified --data-dir. Option C is correct because after restoring the snapshot to a new data directory, the etcd member's configuration (for example the --data-dir flag in the etcd unit file or manifest) must be pointed at that restored directory and the etcd service restarted so the new member starts from the restored state. Option A ('etcdctl endpoint health') only checks cluster endpoint health and does not perform any restore action.

Option B ('etcdctl snapshot save backup.db') creates a new snapshot rather than restoring one. Option E ('etcdctl snapshot status snapshot.db') only reports metadata such as hash, revision, and total keys in the snapshot file and does not restore it.

Exam trap

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

Practice this question →

MCQeasy

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

A.kubectl config get-contexts

B.kubectl cluster-info

C.kubectl config view

D.kubectl config current-context

AnswerD

kubectl config current-context is the dedicated kubectl subcommand that prints exactly the name of the context currently selected for use, reading the current-context field from your kubeconfig. It is the most direct, script-friendly way to determine which cluster and user your kubectl commands will target, and it returns a nonzero exit status if no current context is set.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

Which command is used to backup etcd data using etcdctl?

A.etcdctl backup

B.etcdctl export

C.etcdctl snapshot save

D.etcdctl dump

AnswerC

etcdctl snapshot save <filename> is the canonical etcd backup operation: it connects to the etcd endpoint (default https://127.0.0.1:2379), takes a consistent point-in-time snapshot of the keyspace, and writes it to the specified file. The resulting snapshot is the input used by etcdctl snapshot restore to rebuild a cluster, and it should be created with endpoint, CA, cert, and key flags when TLS is enabled.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kube-apiserver

B.kubelet

C.kube-controller-manager

D.kube-scheduler

AnswerC

The kube-controller-manager runs core control loops, such as the Deployment and ReplicaSet controllers, which continuously monitor the cluster's actual state against the desired state declared in etcd. When discrepancies are detected, these controllers issue commands to make corrective changes, ensuring the cluster converges on the target configuration.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubeadm certs status

B.kubeadm certs check-expiration

C.kubeadm certs list

D.kubeadm certs renew

AnswerB

`kubeadm certs check-expiration` is the dedicated subcommand that inspects certificates under /etc/kubernetes/pki and prints a table with each certificate's expiration date and time remaining before it expires. It also flags certificates that are externally managed and warns when renewal should happen. This read-only command is the standard way to verify certificate validity on a kubeadm-created cluster.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.etcdctl snapshot restore /backup/snapshot.db

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

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

D.etcdctl snapshot save /backup/snapshot.db

AnswerC

This is the correct command because it explicitly sets the environment variable to use the v3 API and specifies the snapshot save subcommand. It also correctly provides the secure loopback endpoint along with the mandatory CA certificate, client certificate, and private key required to authenticate against a TLS-secured etcd cluster.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerC

The kube-proxy is the essential component on each worker node responsible for implementing the Kubernetes Service abstraction. It continuously watches the Kubernetes API server for Service and EndpointSlice objects and translates them into network rules, typically using iptables or IPVS, within the node's kernel. This ensures that requests directed to a Service IP are correctly routed and load-balanced to the healthy Pods backing that Service, effectively maintaining the data plane for cluster networking.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubeadm certs check-expiration

B.kubeadm upgrade plan

C.kubeadm certs renew

D.kubectl get certificates

AnswerA

The kubeadm certs check-expiration command is specifically designed to scan the /etc/kubernetes/pki directory and the kubeconfig files in /etc/kubernetes to determine the validity and expiration dates of all control plane certificates. It displays a clear, tabular summary showing the residual lifetime, expiration date, and authority of each certificate. This is the standard, built-in tool for administrators to proactively manage cluster certificate lifecycles.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.Insufficient CPU or memory resources on any node

B.PersistentVolumeClaim is pending and not bound

C.A required ConfigMap does not exist

D.Node selector labels do not match any node

AnswerC

A required ConfigMap that does not exist causes the kubelet to fail when it tries to start the container, because it cannot retrieve the referenced keys for environment variables or volume mounts. The typical event is: "Error: configmap \"<name>\" not found" and the Pod status may be CreateContainerConfigError or ContainerCreating. This is exactly the scenario described: the Pod appears stuck, yet the underlying cause is a configuration object that is missing, not a scheduling or resource issue. Therefore, this is the correct answer.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.kubelet

B.etcd

C.kube-proxy

D.container runtime

E.kube-controller-manager

AnswersB, E

etcd is a distributed, strongly consistent key-value store that holds the authoritative state of the entire Kubernetes cluster, including all objects, configs, and secrets. It is a foundational control plane component because every API read/write is persisted there, and control plane controllers rely on its data. Without a healthy etcd quorum, the cluster cannot function correctly.

Why this answer

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

Exam trap

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.etcd

B.kubelet

C.kube-apiserver

D.kube-scheduler

E.kube-proxy

AnswersB, E

The kubelet is the primary node agent that runs on every node and is responsible for ensuring that containers described in PodSpecs are running and healthy. It registers the worker node with the cluster API server and continuously monitors the status of Pods, executing actions such as starting, stopping, or restarting containers as needed. It directly manages the container runtime (like containerd) and enforces resource limits and probes.

Why this answer

kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles via the container runtime. kube-proxy (E) is also correct because it runs on each worker node to maintain network rules (iptables/IPVS) that implement Kubernetes Service load balancing and pod networking. etcd (A) is incorrect because it is the cluster's distributed key-value datastore, typically running on control plane nodes. kube-apiserver (C) is incorrect because it is the control plane's front-end REST API server, not a worker node component. kube-scheduler (D) is incorrect because it is a control plane component that assigns pods to nodes rather than running on the worker nodes themselves.

Exam trap

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

Practice this question →

MCQmedium

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

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

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

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

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

AnswerD

This is the correct answer. The RoleBinding is defined with 'namespace: dev', which confines the authorization to the dev namespace. The subject uses 'kind: User' and 'name: dev-user', correctly identifying the human user who needs access. The roleRef points to a Role named 'pod-reader' in the same namespace, which is the appropriate binding structure for granting namespace-scoped permissions to a named user. This combination satisfies the requirement of granting the user access to pod-reader only in the dev namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kubeadm certs check-expiration

B.kubectl get certificates

C.kubeadm certs list

D.kubeadm certs renew --check

AnswerA

The `kubeadm certs check-expiration` command is the official kubeadm subcommand for inspecting the validity of all certificates managed by kubeadm. It reads the certificate files from the default PKI directory (usually /etc/kubernetes/pki) and from the kubeconfig files in /etc/kubernetes, then prints a table showing the remaining validity period for each certificate. This is the canonical way to audit certificate expiration on a cluster bootstrapped with kubeadm, and it also displays the CA certificates separately from the leaf certificates.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kubectl config view

B.kubectl config use-context

C.kubectl config current-context

D.kubectl config get-contexts

AnswerC

This command specifically queries the active kubeconfig file and outputs only the name of the currently active context to stdout. It is the most direct and precise way to programmatically or visually verify which cluster, user, and namespace combination your kubectl commands will target by default.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubeadm certs renew

B.kubectl get secrets -n kube-system

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

D.kubeadm certs check-expiration

AnswerD

This is the correct and standard administrative command used to inspect the expiration status of all Kubernetes control plane certificates managed by kubeadm. It scans the /etc/kubernetes/pki directory and the embedded certificates within the kubeconfig files, outputting a clean, tabular summary of the residual lifetime, expiration date, and authority for each certificate.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kubeadm init

B.kubeadm create cluster

C.kubeadm start

D.kubeadm bootstrap

AnswerA

kubeadm init is the correct command because it initializes a Kubernetes control-plane node, performing preflight checks, generating PKI certificates, kubeconfig files, and etcd cluster configuration. It is the standard bootstrap mechanism for building a new cluster and is the only valid 'initialization' subcommand in kubeadm's CLI.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.The node's disk is full.

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

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

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

AnswerC

The scheduler's filter plugin rejects nodes reporting MemoryPressure, so the pod stays Pending with the '0/1 nodes are available' message. The node cannot admit new pods until memory pressure clears or the pod requests are reduced.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.kubectl cordon <node-name>

B.kubectl uncordon <node-name>

C.kubectl drain <node-name>

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

AnswerA

This command directly sets the .spec.unschedulable field of the specified Node object to true. This prevents the Kubernetes scheduler from assigning any new pods to the node, while leaving existing running pods completely unaffected. It is the most direct and lightweight way to temporarily halt scheduling on a specific node.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.The node is removed from the cluster

B.All pods on node1 are deleted

C.Existing pods on node1 are immediately evicted

D.New pods will not be scheduled onto node1

E.The node is marked as unschedulable

AnswersD, E

Setting `spec.unschedulable` to true on node1 makes the scheduler skip the node during the scheduling cycle, so no new pods are placed there. This is the intended functional outcome of cordoning: to preserve the current pod set while blocking future placements. The scheduler re-evaluates this field on every scheduling decision.

Why this answer

Option D is correct because 'kubectl cordon node1' sets the node's spec.unschedulable field to true, which causes the Kubernetes scheduler to skip node1 when placing new pods, so no new pods will be scheduled onto it. Option E is correct because cordoning is precisely the operation that marks a node as unschedulable, which is reflected in the node's status and taints the scheduler's view of that node. The unmarked options do not belong: option A is wrong because cordoning does not remove the node from the cluster (that would require 'kubectl delete node'), option B is wrong because cordoning does not delete any pods, and option C is wrong because existing pods are not evicted by cordon—eviction requires 'kubectl drain' (with appropriate flags such as --ignore-daemonsets and --delete-emptydir-data).

Exam trap

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

Practice this question →

100

Multi-Selectmedium

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

Select 3 answers

A.kube-apiserver

B.kube-scheduler

C.etcd

D.kubelet

E.kube-proxy

AnswersA, B, C

The kube-apiserver is the front-end of the Kubernetes control plane: it exposes the Kubernetes REST API and handles all read/write operations to the cluster's desired state. Every request—whether from kubectl, pods, or other components—passes through it for authentication, authorization, admission control, and validation before it is persisted. It is the only component that communicates directly with etcd, making it the central gateway for all cluster interactions.

Why this answer

The Kubernetes control plane consists of the components that make global cluster decisions and store cluster state. kube-apiserver (A) is correct because it exposes the Kubernetes API and serves as the front end of the control plane, handling all REST requests and validating/updating objects in etcd. kube-scheduler (B) is correct because it watches for newly created Pods with no assigned node and selects a suitable node for them to run on. etcd (C) is correct because it is the consistent, highly-available key-value store that persists all cluster data and is the backing store for the API server. kubelet (D) is not a control plane component; it is a node agent that runs on each worker node and manages Pods and containers on that node. kube-proxy (E) is also not a control plane component; it is a node-level network proxy that implements Service networking rules on each node.

Exam trap

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

Practice this question →

101

MCQmedium

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

A.kubectl delete node node1

B.kubectl cordon node1

C.kubectl taint node node1 key=value:NoSchedule

D.kubectl drain node1

AnswerD

`kubectl drain node1` first marks the node unschedulable (cordon) and then evicts all non-daemonset, non-mirror Pods via the Eviction API, gracefully terminating them while respecting PodDisruptionBudgets. It is the correct way to prepare a node for maintenance because it actually removes the Pods and reschedules them on other available nodes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

102

MCQhard

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

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

B.The etcdctl version is incompatible with etcd

C.The etcd cluster is not running

D.The snapshot file already exists and is locked

AnswerA

When etcdctl attempts to connect to the etcd cluster without a specified --endpoints flag, it defaults to localhost:2379. In many Kubernetes environments, etcd runs on a dedicated control plane node, often with a different IP address, or behind a firewall, or even on a non-standard port. If the client cannot establish a connection to the default or specified endpoint within the configured timeframe, the operation will result in a "context deadline exceeded" or similar timeout error, indicating that the server did not respond to the connection attempt. This is distinct from an active refusal.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

103

MCQmedium

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

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

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

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

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

AnswerA

The `kubectl cordon node1` command initially marks `node1` as unschedulable, preventing the Kubernetes scheduler from placing any new pods on it. Subsequently, `kubectl drain node1` proceeds to gracefully evict all existing pods from the node. By default, or with the `--ignore-daemonsets` flag, pods managed by DaemonSets are typically not evicted during a drain operation, as they are designed to run one instance per node. This combined action prepares the node for maintenance without disrupting critical system services.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

104

MCQmedium

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

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

B.etcdctl snapshot save /backup/snapshot.db

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

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

AnswerD

This command correctly sets the ETCDCTL_API=3 environment variable to use the modern v3 API required for snapshots. It also provides the necessary loopback endpoint and references the correct CA certificate, client certificate, and private key paths to successfully authenticate via mutual TLS (mTLS) against the secure etcd member.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

105

MCQhard

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

A.--context

B.--user

C.--cluster

D.--kubeconfig

AnswerA

The `--context` flag allows you to temporarily override the active context defined in your kubeconfig for a single `kubectl` execution. This is highly useful for executing commands against a different environment (like production or staging) without permanently changing your active context via `kubectl config use-context`. It targets the specific combination of cluster, user, and namespace defined under that named context.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

106

MCQeasy

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

A.kubeadm certs check-expiration

B.kubeadm alpha certs check-expiration

C.kubeadm certs list

D.kubectl get certificates

AnswerA

kubeadm certs check-expiration is the official command that reads the X.509 certificates under /etc/kubernetes/pki and prints a table containing each certificate's common name, expiry date, and residual time. It also highlights certificates that are already expired or about to expire, allowing administrators to plan a kubeadm certificate renew or upgrade. This is the only command that directly answers the question of certificate expiration for kubeadm-managed clusters.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

107

MCQhard

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

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

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

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

AnswerD

This is the correct backup command: it forces the v3 API, explicitly connects to the local etcd endpoint via HTTPS, and supplies the CA certificate and client certificate/key from the standard kubeadm PKI paths. Those credentials satisfy etcd's mutual TLS requirement and allow a verified snapshot to be written to /backup/etcd-snapshot.db.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

108

MCQeasy

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

A.kube-controller-manager

B.CoreDNS

C.kube-proxy

D.kubelet

AnswerC

kube-proxy is the network agent running on each node that implements the Kubernetes Service abstraction. It watches the API server for changes to Service and EndpointSlice objects, translating them into local OS-level network rules using backends like iptables, IPVS, or eBPF to forward traffic to the correct backend Pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

109

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

A ClusterRoleBinding is required to apply the permissions defined in a ClusterRole to a subject, such as a ServiceAccount, globally across the entire Kubernetes cluster. This binding mechanism ensures that the ServiceAccount can access resources like pods and services in all namespaces without needing individual namespace-scoped RoleBindings. It is the standard RBAC resource for granting cluster-wide authorization.

Why this answer

Option C is correct because reading Pods and Services across all namespaces requires a ClusterRole, which is a cluster-scoped resource whose rules (e.g., apiGroups: [""], resources: ["pods", "services"], verbs: ["get", "list", "watch"]) apply across the entire cluster. Option A is correct because a ClusterRole alone grants nothing; a ClusterRoleBinding must bind that ClusterRole to the ServiceAccount subject (kind: ServiceAccount, name: monitor-sa, namespace: monitoring) to actually confer the permissions cluster-wide. Option B is not needed because token secrets are only for obtaining a long-lived bearer token and are unrelated to RBAC authorization.

Option D is wrong because a RoleBinding is namespace-scoped and would have to be created in every namespace individually, which does not satisfy the 'across all namespaces' requirement. Option E is wrong because a Role in the 'monitoring' namespace only grants permissions within that single namespace, not cluster-wide.

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 →

110

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

The KUBECONFIG environment variable accepts a colon-separated list of kubeconfig paths; with it set, kubectl loads and merges all listed files according to its precedence rules. kubectl config view outputs that merged in-memory configuration, and --flatten expands any file references (such as certificate-authority or client-key) into their base64-encoded inline data, producing a portable, self-contained kubeconfig. Redirecting the output into a file captures that single merged configuration.

Why this answer

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 →

111

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

kubectl cordon node01 sets the node's unschedulable field to true, which causes the node to be marked as SchedulingDisabled in the output of kubectl get nodes. This prevents new pods from being scheduled onto the node while leaving all existing pods running, making it the safe and targeted way to remove a node from usage without disruption. The node remains fully Ready and can be re-enabled later with kubectl uncordon.

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 →

112

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

The Role is namespaced, so scoping it to `dev` via `metadata.namespace` confines the grant to that namespace alone. `apiGroups: [""]` correctly targets the core API group, where pods reside, and `verbs: ["list"]` matches the required action. ClusterRole would be needed only for cluster-wide access.

Why this answer

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 →

113

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

The kube-controller-manager bundles the core control loops that reconcile the cluster's actual state toward the desired state, such as node lifecycle, replication, and endpoint management. It is essential for a HA control plane because in that setup you run multiple replicas with leader election, so only one instance actively runs controllers while the others stand by, but at least one must be reachable via the API server. Without it, no automated corrections would be made to workloads, making it an indispensable control-plane component.

Why this answer

In a highly available Kubernetes control plane, the three essential components are the kube-controller-manager (C), etcd (D), and kube-apiserver (E). The kube-apiserver (E) is the central management endpoint that all clients and internal components communicate with, and it must be replicated behind a load balancer for HA. etcd (D) is the distributed key-value store that holds all cluster state; running it as an odd-numbered quorum across multiple nodes provides fault tolerance. The kube-controller-manager (C) runs the control loops that reconcile cluster state, and in HA it is typically deployed on multiple control-plane nodes with leader election so one active instance drives reconciliation. kubelet (A) and kube-proxy (B) are node-level components that run on every worker node, not control-plane HA components, so they are not required for a high-availability control plane setup.

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 →

114

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

This explicitly sets the current-context field to my-context in the kubeconfig file, making kubectl use that context for subsequent commands. It performs the validation-free update needed to switch a running session from one context to another, and is the standard command for changing the active context. This makes it a valid configuration method.

Why this answer

Option C, `kubectl config use-context my-context`, is correct because it directly switches the current context in the kubeconfig file, making all subsequent kubectl commands target that context's cluster, user, and namespace. Option D, `export KUBECONFIG=/path/to/config`, is correct because setting the KUBECONFIG environment variable tells kubectl which kubeconfig file(s) to load, thereby selecting the context defined in that file (or the file's current-context). Option A is not a valid way to select a context because `kubectl config set-context my-context` creates or modifies a context entry but does not activate it.

Option B, `kubectl config current-context`, only displays the currently active context and does not configure or change it. Option E, `kubectl --config /path/to/config get pods`, is invalid because kubectl has no `--config` flag; the correct flag is `--kubeconfig`.

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 →

115

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 `kubectl describe pod` command provides a comprehensive, human-readable summary of a specific pod's current state, including its status, conditions, and a chronological list of *events* directly associated with it. For a pending pod, this command is invaluable as it surfaces critical information such as scheduler decisions, volume attachment issues, image pull failures, or resource constraints directly within the 'Events' section, clearly indicating the root cause of the pending state.

Why this answer

`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 →

116

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

The kubectl cordon command is the precise administrative tool used to toggle a node's status to unschedulable by updating its spec.unschedulable field to true. This action prevents the scheduler from assigning any new pods to the node while safely leaving existing, currently running workloads completely unaffected.

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 →

117

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

This is the exact procedure recommended by the official kubeadm upgrade documentation: for the control plane node, run `kubectl drain` (with `--ignore-daemonsets`), upgrade the `kubeadm` binary, run `kubeadm upgrade apply`, upgrade `kubelet`, restart it, then `uncordon` the node. Repeating the same drain-upgrade-uncordon cycle for worker nodes ensures they remain within the supported version skew and maintains cluster availability throughout the rolling upgrade.

Why this answer

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 →

118

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 is the official and recommended command under the etcd v3 API to create a point-in-time, consistent backup of the keyspace. It securely writes the active database state to a specified file path on the local disk. For a successful execution in a secure Kubernetes cluster, this command must be accompanied by the appropriate CA certificate, client certificate, and private key flags.

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 →

119

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 is the component that directly maintains network rules on each node. It watches the Kubernetes API for Service and EndpointSlice objects, then programs iptables rules (or IPVS entries) to translate a Service's ClusterIP to the IP addresses of its backing Pods. This provides load-balanced, virtual-IP connectivity to Pods without a traditional proxy process in the data path.

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 →

120

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

This is the correct command because it first cordons the node to prevent new scheduling and then safely evicts all active pods to other nodes in the cluster. The --ignore-daemonsets flag is required because DaemonSet-managed pods cannot be rescheduled elsewhere and would otherwise block the drain operation from completing.

Why this answer

`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 →

121

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 is the correct sequence: `mkdir -p $HOME/.kube` ensures the default kubeconfig directory exists, `sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config` copies the cluster-admin kubeconfig generated by kubeadm into the current user's home, and `sudo chown $(id -u):$(id -g) $HOME/.kube/config` makes the file readable/writable by the current user. Because the admin.conf file is owned by root (readable only by root), sudo is required for the copy; without the chown, kubectl would fail to read the kubeconfig. The resulting `~/.kube/config` is discovered automatically by kubectl, granting full cluster-admin privileges to the local user.

Why this answer

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 →

122

MCQeasy

Which component is responsible for assigning pods to nodes?

A.kube-scheduler

B.kubelet

C.kube-apiserver

D.kube-controller-manager

AnswerA

kube-scheduler is the control plane component that selects the optimal node for each newly created pod. It subscribes to the API server's watch stream for pending pods, filters nodes according to resource requirements, taints/tolerations, node selectors, and affinity rules, then scores the feasible candidates to choose the best match. The decision is written back as a binding object, which sets the pod's nodeName field, so this component alone is responsible for assigning pods to nodes.

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 →

123

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

A node can have multiple taints in its spec.taints list, each defined by a key, value, and effect (NoSchedule, PreferNoSchedule, or NoExecute). For a pod to be schedulable, it must tolerate every taint present on the node; if any taint lacks a matching toleration, the pod will not be scheduled there. This allows fine-grained control over node isolation.

Why this answer

Option B is correct because a Kubernetes node can carry multiple taints simultaneously, each expressed as key=value:effect, and a pod must tolerate every NoSchedule/NoExecute taint on that node to be scheduled there. Option E is correct because tolerations are declared in a pod's spec (spec.tolerations) and let the scheduler place that pod on a node whose taints it matches, effectively overriding the taint's scheduling restriction. Option A is wrong because taints only repel pods that lack matching tolerations, not all pods; pods with appropriate tolerations can still schedule.

Option C is wrong because taints are applied to nodes (via kubectl taint nodes), not to pods. Option D is wrong because tolerations are set on pods, not on nodes.

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 →

124

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

A Kubernetes Job creates one or more pods and ensures that a specified number of them successfully terminate, tracking the overall completion. It is the ideal controller for a one-time batch task because the pod runs to completion and the Job status becomes Complete, without any automatic restart of the finished pod. If the pod fails, the Job can restart it according to the backoffLimit, ensuring the task eventually succeeds.

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 →

125

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

As the primary node agent, the kubelet is responsible for ensuring that containers described in PodSpecs are running and healthy on its node. It acts as the bridge between the control plane and the container runtime, translating declarative pod specifications into runtime commands via the Container Runtime Interface (CRI).

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 →

126

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

To grant cluster-wide permissions to a ServiceAccount, you must pair a ClusterRole with a ClusterRoleBinding. Because a ClusterRoleBinding is a non-namespaced resource, it applies the permissions defined in the ClusterRole across all namespaces in the cluster, as well as to cluster-scoped resources like Nodes and PersistentVolumes.

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 →

127

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 is the correct solution as it precisely meets the requirements. It creates a `ServiceAccount` named `deployer` in the `app` namespace. A `Role` is then defined in the `app` namespace, granting the specific permission to create `deployments`. Finally, a `RoleBinding` in the `app` namespace associates this namespaced `Role` with the `deployer` `ServiceAccount`, ensuring permissions are confined strictly to the 'app' namespace.

Why this answer

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

A common pitfall is the misconception that a RoleBinding can only bind a Role, but in fact a RoleBinding can bind a ClusterRole, granting the ClusterRole's permissions only within the RoleBinding's namespace. Therefore, option C is technically valid and would also satisfy the requirement. However, the exam's expected answer is option A because it uses a namespaced Role, adhering to the principle of least privilege.

Option B is incorrect because it uses a ClusterRoleBinding, which grants permissions cluster-wide. Option D is incorrect because the Role is created in the 'default' namespace instead of 'app'.

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 →

128

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

kube-proxy runs on every worker node and is responsible for implementing the Kubernetes Service abstraction by maintaining network rules that govern traffic forwarding to backend pods. It watches the API server for Service and Endpoint changes and programs iptables, IPVS, or userspace rules to route packets correctly. This directly matches the task of maintaining network rules on a worker node, making it the correct answer.

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 →

129

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

This Role grants the verbs "get," "watch," and "list" for the "pods" resource, which are all read-only operations in Kubernetes RBAC. "get" retrieves a single pod's details, "list" enumerates pods, and "watch" streams pod changes. Because the rule is scoped to the development namespace via a Role and the verbs are read-only, this correctly describes the permission to read pod details in that namespace.

Why this answer

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 →

130

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 scheduler rejected every node because the control-plane node carries the `node-role.kubernetes.io/master:` taint with no matching toleration in the pod spec. Without a toleration for that specific key and effect, the scheduler cannot bind the pod, leaving it Pending indefinitely.

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 →

131

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

The kubelet is the core node agent that takes PodSpecs from the API server or local manifests and uses the Container Runtime Interface to instruct a runtime such as containerd or CRI-O to pull images, create sandboxes, and start containers. It also monitors container health, enforces pod resources, and reports status back to the control plane. Because it is the component that directly drives the runtime, the kubelet is responsible for running containers.

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 →

132

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 command is the standard way to generate a new bootstrap token and immediately print the complete `kubeadm join` command, including the API server endpoint, the token, and the `--discovery-token-ca-cert-hash`. It simplifies node provisioning by outputting a ready-to-run command for worker nodes.

Why this answer

`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 →

133

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

This subcommand reads the kubeconfig's current-context field and prints the name of the context kubectl will use by default, directly answering which context is active. It queries configuration state rather than cluster resources, so no API server call is needed.

Why this answer

`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 →

134

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

This is the correct command because it explicitly sets the API version to 3 using the ETCDCTL_API=3 environment variable, which is required to access the modern etcd v3 storage engine features. The snapshot save subcommand is the standard, officially supported method to generate a consistent, non-disruptive backup of the cluster's state.

Why this answer

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 →

135

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

`kubeadm certs check-expiration` is the canonical command for inspecting the lifecycle of all certificates generated by kubeadm. It reads the PKI files under `/etc/kubernetes/pki` and the embedded etcd certificates, and outputs each certificate's name, remaining validity, and expiration date. This stable subcommand is the direct way to verify expiration before planning renewals.

Why this answer

`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 →

136

MCQeasy

Which of the following is NOT a control plane component?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerD

The kubelet is the primary node agent that runs on every worker node in the cluster, rather than being a control plane component. It is responsible for registering the node with the apiserver and ensuring that the containers described in PodSpecs are running and healthy. It acts as the execution agent on individual nodes, bridging the gap between control plane instructions and container runtimes.

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 →

137

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 subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.

Why this answer

`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 →

138

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

`etcdctl endpoint health --cluster` queries every endpoint listed in the cluster's member information and reports each endpoint's health and latency. The `--cluster` flag tells the client to read the member list from an existing endpoint and check all members, not just a single address. A healthy response from all endpoints indicates the cluster is operational and has quorum, making this an effective first diagnostic.

Why this answer

`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 →

139

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 command is the correct approach for backing up an etcd database on a Kubernetes control plane. It explicitly sets `ETCDCTL_API=3` for compatibility with modern etcd versions, specifies the secure HTTPS endpoint `https://127.0.0.1:2379`, and provides all required TLS certificates (`--cacert`, `--cert`, `--key`) for mutual authentication with the etcd server. This ensures a secure and successful connection, allowing `etcdctl` to perform the snapshot operation reliably.

Why this answer

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 →

140

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

kubectl config use-context prod-cluster is the correct command because it explicitly writes the name prod-cluster to the current-context field in the kubeconfig file. After this runs, kubectl commands resolve the current context to prod-cluster and load its associated cluster and user credentials. It is the direct counterpart to the question's intent of switching the active context.

Why this answer

`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 →

141

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

A namespaced Role scoped to 'monitoring' grants only the 'get' and 'list' verbs on pods, satisfying least privilege. Binding it with a RoleBinding in the same namespace restricts monitor-sa's permissions to that namespace, which is exactly the constraint the stem requires.

Why this answer

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 →

142

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

This is correct because a ClusterRoleBinding grants the permissions defined in the ClusterRole to the specified subject (the service account) cluster-wide. The pod-reader ClusterRole includes the 'get' and 'list' verbs on 'pods', and those permissions apply to pods in all namespaces. Therefore, the service account can read pod objects from any namespace, including metadata, specs, and statuses.

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 →

143

MCQeasy

Which control plane component stores the entire cluster state?

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.etcd

AnswerD

etcd is a strongly consistent, highly available, distributed key-value store used as Kubernetes' secure registry for all cluster data. Every single object, configuration, and status detail in the cluster is persisted within etcd. It serves as the single source of truth, ensuring that the cluster state can be reliably recovered in the event of a control plane failure.

Why this answer

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 →

144

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

Once the primary control plane node is upgraded, you must run this command on all other control plane nodes and worker nodes to upgrade their local configurations. This command fetches the cluster configuration from the API server and updates the local kubelet configuration files and certificates accordingly.

Why this answer

`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 →

145

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

When a node is configured with a taint using the NoSchedule or NoExecute effect, the Kubernetes scheduler will actively reject any pods that do not possess a matching toleration. Consequently, if no other eligible nodes are available, the pod remains stuck in the Pending state with a scheduling failure event logged in its description.

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 →

146

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

The kubeadm certs renew apiserver command renews only the API server serving certificate, leaving other control plane certificates untouched. It satisfies the stem's constraint of renewing just that certificate, whereas renew all would regenerate every certificate authority-signed certificate.

Why this answer

`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 →

147

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 the permitted verbs on deployments, while a RoleBinding grants that Role to the specific user within the development namespace. Namespace-scoped RoleBinding confines the permissions to that namespace only, satisfying the requirement to manage deployments there alone.

Why this answer

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 →

148

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

In a kubeconfig file, the `contexts` field is a list of named context objects, each holding three keys: `cluster`, `user`, and optionally `namespace`. The context is the only construct that binds a specific user to a specific cluster, and it can also set a default namespace for kubectl commands. Therefore, the `contexts` field is what defines the full set of user-to-cluster associations.

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 →

149

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

/var/lib/etcd is the default etcd data directory for kubeadm-created clusters, configured as the hostPath mount for the etcd static pod and defined by the `--data-dir` flag. This directory contains the etcd member's key-value store, WAL (write-ahead log), and snapshots, representing the authoritative persistence layer for all cluster state. To back up etcd data, you would typically run `etcdctl snapshot save` while the cluster is running, or stop etcd and copy this directory for a cold backup; in either case, this path is the correct source of the data.

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 →

150

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 central administrative hub of the Kubernetes control plane, exposing the HTTP API that lets users, external components, and internal parts communicate. It validates and configures data for state objects, processes REST operations, and acts as the sole gateway to the etcd datastore.

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 →