CCNA Cka Cluster Arch Questions — Page 3 of 3

151

Multi-Selecteasy

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

Select 2 answers

A.etcd

B.kubelet

C.kube-proxy

D.container runtime

E.kube-apiserver

AnswersA, E

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. The API server reads and writes every object through it, making etcd a required control plane component rather than a worker node process.

Why this answer

Option A, etcd, is correct because it is the control plane's distributed key-value store that persistently holds all cluster state and configuration data, which the API server reads and writes. Option E, kube-apiserver, is correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the entry point through which all other components interact with the cluster. The unmarked options do not belong: kubelet (B) is a node agent that runs on each worker node to manage pods and containers, kube-proxy (C) is a node-level network proxy implementing Service networking rules, and the container runtime (D) is the node software (e.g., containerd or CRI-O) that actually runs containers — all three are node components, not control plane components.

Exam trap

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

Practice this question →

152

MCQeasy

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

A.kubectl config set-context

B.kubectl config set-credentials

C.kubectl config create-user

D.kubectl config set-cluster

AnswerB

This is the correct command because it creates or updates the user entry in the kubeconfig with the necessary authentication credentials, such as --client-certificate, --client-key, --token, or --username/--password. Running this command ensures that a named user with valid credentials is available for contexts to reference. Without it, you only have cluster and context definitions but no authenticated identity to actually connect to the API server.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

153

MCQeasy

Which component is responsible for running containers on a node?

A.kubelet

B.kube-scheduler

C.container runtime

D.kube-proxy

AnswerC

The container runtime is the low-level software that actually runs containers on a node. It implements the Kubernetes CRI (e.g., containerd, CRI-O) and uses an OCI-compliant runtime like runc to create namespaces, set up cgroups, and execute container processes as the kernel sees them. When the kubelet requests a pod sandbox or container, the runtime pulls images, mounts filesystems, and starts the user process — making it the direct executor of container workloads.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

154

MCQeasy

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

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerD

etcd is the consistent, highly-available distributed key-value store that acts as the cluster’s single source of truth. It persists every Kubernetes object — Secrets, ConfigMaps, Pod specs, and cluster configuration — using the Raft consensus algorithm to replicate writes across all etcd members. This is the only core control-plane component that actually stores data, making it critical for backup and disaster recovery.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

155

MCQhard

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

A.The scheduler is not running.

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

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

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

AnswerD

Control-plane and master nodes are typically configured with taints like node-role.kubernetes.io/control-plane:NoSchedule to prevent user workloads from running on them. Because the Pod lacks the corresponding tolerations in its specification, the scheduler filters out these nodes, leaving the Pod in a Pending state with a taint-related scheduling failure event.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

156

MCQmedium

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

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

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

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

D.kubeadm upgrade node; kubectl uncordon <node>

AnswerC

This is the correct per-node upgrade sequence: kubectl drain <node> first cordons the node and evicts its workloads—typically using --ignore-daemonsets in practice—then kubeadm upgrade node applies the new kubeadm and kubelet configuration to the node's local files, and finally kubectl uncordon <node> marks it schedulable again so new pods can be placed. Without draining, the kubelet may be restarted while pods are still running, and there is no graceful transition for the workloads. The uncordon step is essential after the upgrade, otherwise the node would remain unschedulable and workloads would not be scheduled back to it.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

157

Multi-Selectmedium

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

Select 2 answers

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

B.Run 'kubectl create token build-bot'

C.Use the TokenRequest API to generate a token

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

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

AnswersD, E

The foundational step is to create a ServiceAccount object, which you can do with `kubectl create serviceaccount build-bot` or by applying a YAML manifest with `kind: ServiceAccount` and the desired name. Kubernetes does not automatically carve out a ServiceAccount for you—it must be explicitly created before any pod or process can assume that identity. Once the ServiceAccount exists, the controller-manager automatically provisions a long-lived token secret for it (unless you explicitly opt out), so the ServiceAccount immediately has a usable credential. Without this object, all other claims about generating or attaching tokens are invalid because there is no identity to bind them to.

Why this answer

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

Exam trap

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

Practice this question →

158

Multi-Selecteasy

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

Select 2 answers

A.kubeadm upgrade plan

B.kubectl get certificates

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

D.kubeadm certs renew --all

E.kubeadm certs check-expiration

AnswersC, E

The openssl x509 command reads the actual X.509 certificate file at /etc/kubernetes/pki/apiserver.crt and decodes it. With -noout it suppresses the base64 PEM output, and -text prints the structured certificate fields; piping to grep -A2 'Validity' extracts the Not Before and Not After dates, which directly reveal the expiration timestamp. This method works at the filesystem level and is independent of kubeadm's state, making it a reliable diagnostic for any certificate file.

Why this answer

Option E, `kubeadm certs check-expiration`, is correct because it is the dedicated kubeadm subcommand that lists all kubeadm-managed certificates (in /etc/kubernetes/pki and /etc/kubernetes/pki/etcd) along with their expiration dates, residual time, and CA certificate validity. Option C, `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity`, is correct because it directly parses the X.509 certificate file and prints its Validity period (Not Before / Not After), which is a valid way to inspect the expiration of any individual kubeadm-managed certificate. Option A, `kubeadm upgrade plan`, is not correct because it reports available Kubernetes version upgrades and only incidentally warns about certificate expiry, not as its purpose.

Option B, `kubectl get certificates`, is not correct because there is no built-in `certificates` resource in Kubernetes (that would require cert-manager CRDs, which are unrelated to kubeadm PKI). Option D, `kubeadm certs renew --all`, is not correct because it renews certificates rather than checking their expiration.

Exam trap

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

Practice this question →