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

Multi-Selecteasy

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

Select 2 answers

A.etcd

B.kubelet

C.kube-proxy

D.container runtime

E.kube-apiserver

AnswersA, E

etcd is the store for cluster state.

Why this answer

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

Exam trap

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

Practice this question →

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 →

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 →

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 →

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 →