CCNA Cluster Architecture, Installation & Configuration Questions

MCQmedium

A Kubernetes cluster is running with a single control plane node. The administrator wants to add a second control plane node for high availability. What is the first step after the new node has been provisioned with the required software?

A.Create a bootstrap token on the existing control plane node.

B.Run kubeadm join with the --control-plane flag on the new node.

C.Run kubeadm init on the new node.

D.Take a snapshot of etcd using etcdctl.

AnswerB

To expand a single control plane Kubernetes cluster into a highly available multi-control plane setup, the `kubeadm join` command is the correct utility. Specifically, including the `--control-plane` flag instructs `kubeadm` to not only join the new node to the cluster but also to install and configure all necessary control plane components (API server, scheduler, controller-manager, etcd member) on that node. This command orchestrates the secure integration and replication of critical cluster services, ensuring the new node can participate as a full control plane member.

Why this answer

The first step to add a second control plane node to an existing cluster is to run `kubeadm join` with the `--control-plane` flag on the new node. This command uses the existing control plane's API server to join the new node as a control plane member, automatically distributing certificates and configuring the etcd cluster. The `--control-plane` flag signals kubeadm to set up the additional control plane components (e.g., kube-apiserver, kube-controller-manager, kube-scheduler) and join the etcd cluster as a learner or voting member, depending on the etcd configuration.

Exam trap

The trap here is that candidates often confuse the process of adding a worker node (which uses `kubeadm join` without `--control-plane`) with adding a control plane node, or mistakenly think that `kubeadm init` or manual etcd backup steps are required first, when in fact the `--control-plane` flag handles the entire control plane join process automatically.

How to eliminate wrong answers

Option A is wrong because creating a bootstrap token on the existing control plane node is not the first step; bootstrap tokens are typically generated automatically by `kubeadm init` or can be created later, but the immediate prerequisite for joining a control plane node is to run `kubeadm join` with the `--control-plane` flag, which itself can use an existing token or a pre-created one. Option C is wrong because running `kubeadm init` on the new node would attempt to initialize a new, separate cluster, not join the existing one, and would cause a conflict with the existing control plane. Option D is wrong because taking a snapshot of etcd using `etcdctl` is a backup procedure, not a step required for adding a control plane node; the etcd cluster will be extended automatically by `kubeadm join --control-plane`.

Practice this question →

MCQhard

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

A.The kubelet configuration file has incorrect node IP.

B.The node's RBAC permissions are misconfigured.

C.The API server is not running.

D.The bootstrap token used for TLS bootstrapping has expired.

AnswerD

Bootstrap tokens used in TLS bootstrapping are intentionally short-lived and can expire, especially if they were created for a one-time node registration. When a token expires, the API server rejects the kubelet's authentication attempt, returning a 401 Unauthorized, and the kubelet cannot complete the bootstrap sequence or download the CA certificate. This precisely matches the observed symptom of a bootstrap CA retrieval failure, making it the correct root cause.

Why this answer

The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.

Exam trap

CNCF often tests the distinction between authentication failures (expired token) and authorization failures (RBAC), leading candidates to incorrectly select RBAC misconfiguration when the actual issue is token expiry.

How to eliminate wrong answers

Option A is wrong because an incorrect node IP would cause connectivity or identity issues, but the specific error 'Failed to get bootstrap CA certificate' points to a TLS bootstrap authentication failure, not an IP misconfiguration. Option B is wrong because RBAC permissions are enforced after authentication; the kubelet cannot even authenticate with an expired token, so RBAC misconfiguration is not the root cause. Option C is wrong because if the API server were not running, the kubelet would likely report a connection refused or timeout error, not a bootstrap CA certificate retrieval failure.

Practice this question →

MCQmedium

A DevOps engineer is designing a Kubernetes cluster for a production environment. Which of the following is a best practice for etcd deployment?

A.Deploy etcd on exactly 2 nodes for simplicity.

B.Deploy etcd on all worker nodes to maximize redundancy.

C.Deploy etcd on dedicated nodes with SSD storage.

D.Deploy etcd on the same nodes as GPU-accelerated workloads.

AnswerC

Deploying etcd on dedicated nodes with SSD storage is the recommended best practice for production Kubernetes clusters. Dedicated nodes ensure etcd has exclusive access to CPU, memory, and network resources, preventing interference from other workloads. Furthermore, etcd is highly sensitive to disk I/O latency, making fast SSD storage crucial for maintaining low write latencies, high throughput, and overall cluster stability and responsiveness.

Why this answer

Etcd is the Kubernetes cluster's primary data store, and its performance directly impacts the entire cluster's stability and responsiveness. Dedicated nodes prevent resource contention from other workloads, while SSD storage provides the low-latency, high-IOPS performance required for etcd's frequent write operations (especially with the default 1 MB write-ahead log). This isolation is a recommended best practice in the official Kubernetes documentation for production clusters.

Exam trap

The trap here is that candidates often assume 'more nodes = more redundancy' (Option B) or that 'simplicity is better' (Option A), without understanding that etcd's Raft consensus requires an odd number of members and that dedicated, fast storage is non-negotiable for production reliability.

How to eliminate wrong answers

Option A is wrong because etcd requires an odd number of members (typically 3, 5, or 7) to maintain a quorum for the Raft consensus algorithm; exactly 2 nodes cannot achieve a majority (quorum requires > N/2, so 2 nodes would need both to agree, creating a single point of failure). Option B is wrong because deploying etcd on all worker nodes introduces severe performance risks due to resource contention with application pods, and it violates the principle of separating the control plane from data plane components. Option D is wrong because GPU-accelerated workloads are typically compute-intensive and can cause unpredictable I/O and CPU spikes, which would degrade etcd's latency-sensitive operations and risk cluster instability.

Practice this question →

MCQeasy

An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?

A.Ensure that containerd is installed and running on the worker node.

B.Verify that the control plane node is healthy.

C.Check if the join token has expired.

D.Install a network plugin like Calico on the control plane.

AnswerA

The kubelet on the worker node communicates with the container runtime through the Container Runtime Interface (CRI), typically over a Unix socket such as /run/containerd/containerd.sock. If containerd is not installed, the service is stopped, or the socket is missing, kubelet will fail with a CRI connection error and never start pods. Run `systemctl status containerd` and check the socket path configured in kubelet (--container-runtime-endpoint) to confirm the runtime is active.

Why this answer

The error 'container runtime is not running' on the worker node indicates that the CRI (Container Runtime Interface) implementation, typically containerd, is not active. Since kubelet relies on a running container runtime to manage pods, the administrator must first check that containerd is installed and running on the worker node using commands like 'systemctl status containerd' or 'systemctl start containerd'.

Exam trap

The trap here is that candidates often assume the error is related to the control plane or networking, but the CRI error specifically points to a missing or stopped container runtime on the node attempting to join.

How to eliminate wrong answers

Option B is wrong because the control plane node's health is irrelevant to a preflight error on the worker node; the worker node's kubelet cannot even start without a runtime. Option C is wrong because a token expiration would produce an authentication error (e.g., 'error: failed to request certificate'), not a CRI runtime error. Option D is wrong because a network plugin like Calico is installed after nodes have joined and is not required for the join process; the preflight check fails before any network plugin is considered.

Practice this question →

MCQhard

A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?

A.Use LUKS to encrypt the disk partition where etcd data is stored.

B.Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.

C.Use TLS certificates to encrypt communication between etcd and the API server.

D.Configure etcd to use encryption at rest by setting --experimental-encryption-provider.

AnswerB

An EncryptionConfiguration resource defines the order and type of providers (such as aescbc, aesgcm, secretbox, or kms) for protecting specific API resource types. The kube-apiserver must be started with --encryption-provider-config=/path/to/encryption-config.yaml, and when it writes data like Secrets to etcd it encrypts that data using the chosen provider (aescbc uses AES-CBC with a randomly generated IV and a 32-byte key). This is the canonical, Kubernetes-native mechanism for encryption at rest and is exactly what the CKA objectives expect.

Why this answer

Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

Exam trap

The trap here is confusing encryption at rest (data on disk) with encryption in transit (TLS), leading candidates to select TLS-based options, or assuming that etcd itself handles encryption at rest when it is actually the kube-apiserver that performs the encryption before writing to etcd.

How to eliminate wrong answers

Option A is wrong because LUKS encrypts the entire disk partition at the filesystem level, which is a valid approach for encrypting etcd data at rest, but the question asks which approach the team should use in the context of a Kubernetes cluster; the recommended and Kubernetes-native method is to use the EncryptionConfiguration resource, not an OS-level disk encryption tool. Option C is wrong because TLS certificates encrypt data in transit between etcd and the API server, not at rest; encryption at rest protects data when it is stored on disk, not during network communication. Option D is wrong because etcd does not have an --experimental-encryption-provider flag; encryption at rest is configured on the kube-apiserver side, not on etcd itself.

Practice this question →