Courseiva

CCNA Cluster Architecture, Installation & Configuration Questions

19 questions · Cluster Architecture, Installation & Configuration · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A system administrator needs to install a Kubernetes cluster using kubeadm. The control plane node must be initialized with a specific Pod network CIDR of 10.244.0.0/16 for Flannel. Which command should be used?

A.kubeadm init --service-cidr 10.244.0.0/16
B.kubeadm init --pod-network-cidr 10.244.0.0/16
C.kubeadm init --network-cidr 10.244.0.0/16
D.kubeadm init --apiserver-advertise-address 10.244.0.0
AnswerB

The --pod-network-cidr flag is the correct kubeadm parameter for specifying the CIDR range from which pod IP addresses are allocated. It passes 10.244.0.0/16 to the API server and controller-manager, and CNI plugins like Flannel expect this exact range for their default configuration. This option directly enables pod networking, making it the right choice.

Why this answer

`kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for Pod IP addresses, which is required by Flannel and other CNI plugins to allocate subnets to nodes. The 10.244.0.0/16 range is the default Pod network CIDR for Flannel, ensuring proper network configuration without conflicts.

Exam trap

The trap here is that candidates confuse `--pod-network-cidr` with `--service-cidr` or invent non-existent flags like `--network-cidr`, because kubeadm has multiple CIDR-related options and the exam tests precise flag recall.

How to eliminate wrong answers

Option A is wrong because `--service-cidr` sets the IP range for Kubernetes services (default 10.96.0.0/12), not the Pod network; using it for Pod CIDR would misconfigure service networking. Option C is wrong because `--network-cidr` is not a valid `kubeadm init` flag; the correct flag is `--pod-network-cidr`. Option D is wrong because `--apiserver-advertise-address` specifies the IP address on which the API server advertises itself (e.g., the control plane node's IP), not a CIDR range for Pods.

Practice this question →
2
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 →
3
MCQhard

Refer to the exhibit. A Kubernetes cluster was initialized using kubeadm with the command shown. After initialization, the cluster nodes are in NotReady state. Which is the most likely missing step?

A.Increase the apiserver-advertise-address to match the node's external IP.
B.Install a pod network add-on such as Flannel.
C.Run kubeadm join on the control plane node.
D.Restart the kubelet service on all nodes.
AnswerB

Correct: After `kubeadm init`, the control plane node starts with a `NotReady` status because no Container Network Interface (CNI) plugin has been deployed to create the pod network. The kubelet's readiness condition depends on `NetworkReady` being true, which requires a CNI plugin like Flannel (or Calico, Cilium, etc.) to set up the pod CIDR, routing, and network interfaces. Until a CNI plugin is installed, the node's `Ready` condition remains `False` or `Unknown`, even though all control-plane pods (e.g., etcd, kube-apiserver) may be running. Flannel specifically configures an overlay network using the pod CIDR, enabling pod-to-pod communication, and once applied, the node should transition to `Ready` after the CNI pod starts and the kubelet detects the network is ready.

Why this answer

The kubeadm init command only initializes the control plane. To make the nodes ready, a pod network must be installed. The exhibit shows no pod network add-on being applied, and the --pod-network-cidr flag indicates a specific CIDR for the pod network (10.244.0.0/16) which is typically used with Flannel.

Without installing a CNI plugin, nodes remain NotReady.

Practice this question →
4
MCQhard

You are a cluster administrator managing a multi-node Kubernetes cluster version 1.22. The cluster runs critical applications in the 'production' namespace. You have been asked to upgrade the control plane node to version 1.23 while minimizing downtime. The cluster uses a single control plane node (not HA). You have already backed up etcd and verified the backup is valid. You have also reviewed the upgrade notes and there are no breaking changes that affect your workloads. You have drained the control plane node and ensured all pods are evicted. The node is now in 'Ready,SchedulingDisabled' state. You then run 'kubeadm upgrade plan' and see that upgrade to v1.23.0 is available. Next, you run 'kubeadm upgrade apply v1.23.0'. The command completes successfully. However, when you try to uncordon the node with 'kubectl uncordon <node>', you get an error: 'error: unable to update node: the object has been modified; please apply your changes to the latest version and try again'. What is the most likely cause and the correct next step?

A.Re-drain the node to reset its state, then uncordon again.
B.Re-run the 'kubectl uncordon' command; the conflict is transient due to concurrent updates.
C.Restart the kubelet on the control plane node to refresh the node object.
D.Generate a new bootstrap token and rejoin the node to the cluster.
AnswerB

`kubectl uncordon` performs a read-modify-write on the Node object; the API server rejects the write with 409 Conflict if the resourceVersion it sent is stale because the Node was concurrently updated by another actor (e.g., a controller or another admin). This is optimistic concurrency control to prevent lost updates—the conflict is transient, and re-running the command simply retrieves the latest resourceVersion and resubmits the `unschedulable=false` change. Unless the conflict persists repeatedly, no further node-level remediation is required.

Why this answer

The error 'the object has been modified' indicates a resource conflict due to concurrent updates to the node object, typically from the kubelet or controller manager updating the node status simultaneously. This is a transient optimistic locking conflict in Kubernetes, and simply retrying the 'kubectl uncordon' command will resolve it because the conflict is temporary and the node is already upgraded and ready to be scheduled.

Exam trap

The trap here is that candidates may think the node is in a broken state requiring a restart or rejoin, when in fact the error is just a transient API conflict that is resolved by retrying the uncordon command.

How to eliminate wrong answers

Option A is wrong because re-draining the node is unnecessary and would evict pods again, causing additional downtime; the node is already drained and the issue is just a conflict on the node object. Option C is wrong because restarting the kubelet does not resolve an API object conflict; the kubelet is already running and the node is in 'Ready,SchedulingDisabled' state, so restarting it would not refresh the node's resourceVersion or fix the conflict. Option D is wrong because generating a new bootstrap token and rejoining the node is a drastic step for a node that is already part of the cluster and upgraded; it would reinitialize the node and cause unnecessary disruption, and the conflict is not related to authentication or cluster membership.

Practice this question →
5
MCQhard

Refer to the exhibit. A new worker node (node2) has been added to the cluster. It shows NotReady status, and a CertificateSigningRequest (CSR) is pending. What step must the cluster administrator take to make node2 ready?

A.Approve the pending CSR using 'kubectl certificate approve csr-node2'.
B.Run 'kubeadm join' again with the correct token.
C.Add the node's IP to the API server's TLS certificate.
D.Restart the kubelet on node2.
AnswerA

The kubelet on node2 generated its own private key and submitted a CertificateSigningRequest (CSR) to the Kubernetes API server during the kubeadm join process. The cluster requires administrative approval before the kube-controller-manager can sign that CSR, which would give the node its client certificate for authenticating against the API server. Running 'kubectl certificate approve csr-node2' explicitly approves the pending request, triggering the signer to issue the certificate. Without this approval, the kubelet cannot complete its TLS bootstrapping and the node remains NotReady.

Why this answer

When a new node joins, the kubelet creates a CSR for its client certificate. The CSR must be approved by an administrator (or automatically via a controller). Until approved, the node cannot authenticate and remains NotReady.

Practice this question →
6
MCQhard

A Kubernetes cluster has three control plane nodes and five worker nodes. The kube-apiserver is failing to start on one control plane node with the error 'etcdserver: request timed out'. The etcd cluster is healthy with three members. Which of the following is the most likely cause?

A.A firewall is blocking traffic on port 2379 between the control plane and etcd
B.The etcd cluster has a leader election issue
C.The kube-apiserver is using the wrong etcd client port (2380 instead of 2379)
D.The etcd client certificate is expired
AnswerA

Port 2379 is the default port used by the kube-apiserver to communicate with the etcd database. If a network firewall or security group blocks traffic on this port, the API server's connection attempts will silently drop, resulting in connection timeout errors rather than immediate rejection or TLS handshaking failures.

Why this answer

The error 'etcdserver: request timed out' indicates that the kube-apiserver cannot establish a TCP connection to the etcd cluster within the timeout period. Since the etcd cluster is healthy with three members and leader election is functioning, the most likely cause is a firewall blocking port 2379 (the etcd client port) between the control plane node and the etcd members. This prevents the kube-apiserver from communicating with etcd, even though the etcd cluster itself is operational.

Exam trap

The trap here is that candidates often assume a timeout error implies an etcd cluster problem (like leader election or node failure), but the question explicitly states the etcd cluster is healthy, shifting the focus to network connectivity between the apiserver and etcd.

How to eliminate wrong answers

Option B is wrong because a leader election issue would cause etcd to be unavailable or return errors like 'etcdserver: no leader', not a simple timeout; the question states the etcd cluster is healthy with three members, implying leader election is working. Option C is wrong because using port 2380 (the etcd peer port) instead of 2379 would result in a connection refused error, not a timeout, as the kube-apiserver would attempt to connect to a port that is not listening for client requests. Option D is wrong because an expired etcd client certificate would cause a TLS handshake failure with an error like 'x509: certificate has expired or is not yet valid', not a generic timeout.

Practice this question →
7
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 →
8
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 →
9
MCQhard

A cluster administrator notices that nodes are not joining the cluster after a kubeadm init. The kubelet logs show: 'failed to run Kubelet: could not init service: open /var/lib/kubelet/config.yaml: permission denied'. What is the most likely cause?

A.The kubelet is running out of disk space.
B.The kubelet is not able to reach the API server.
C.The kubelet binary is missing.
D.The kubelet configuration file has incorrect ownership or permissions.
AnswerD

The kubelet service requires read access to its configuration file, typically located at `/var/lib/kubelet/config.yaml`. If this file has incorrect ownership or highly restrictive permissions (such as `0000`), the systemd service will fail to start, explicitly logging a 'permission denied' error when attempting to parse its startup parameters.

Why this answer

The error message 'open /var/lib/kubelet/config.yaml: permission denied' indicates that the kubelet process does not have the necessary read permissions to access its configuration file. This is typically caused by incorrect file ownership (e.g., owned by root instead of the kubelet user) or restrictive file permissions (e.g., 600 instead of 644). Since kubelet runs as a systemd service, it requires appropriate access to this file to initialize properly.

Exam trap

The trap here is that candidates often confuse 'permission denied' with network connectivity issues or resource exhaustion, but the specific file path in the error message directly points to a filesystem permission problem.

How to eliminate wrong answers

Option A is wrong because disk space issues would produce errors like 'no space left on device' or 'disk quota exceeded', not a permission denied error on a specific file. Option B is wrong because inability to reach the API server would manifest as connection timeout or refused errors in the kubelet logs, not a file permission error during initialization. Option C is wrong because a missing kubelet binary would result in a 'command not found' or 'executable file not found' error when systemd tries to start the service, not a permission denied error on a configuration file.

Practice this question →
10
MCQhard

An administrator runs 'kubeadm init' on a machine that previously had a Kubernetes cluster. The command fails with the above errors. What is the best course of action?

A.Run 'kubeadm reset' to clean up the previous installation and then re-run kubeadm init.
B.Manually delete the /etc/kubernetes/manifests/kube-apiserver.yaml file and kill the process using port 6443.
C.Use a different port for the API server by specifying --apiserver-bind-port.
D.Run kubeadm init with --force flag to override the errors.
AnswerA

Running 'kubeadm reset' is the best practice and official method to revert any changes made to the host by a previous 'kubeadm init' or 'kubeadm join' execution. It automatically stops and removes running containers, cleans up local directories like '/var/lib/etcd' and '/etc/kubernetes', and resets iptables rules. This ensures a clean slate, allowing a subsequent 'kubeadm init' command to succeed without encountering conflicting state or port conflicts.

Why this answer

When `kubeadm init` fails on a machine that previously hosted a Kubernetes cluster, it is typically because residual configuration files, certificates, and control plane static pod manifests from the prior installation conflict with the new initialization. Running `kubeadm reset` is the official cleanup command that removes these artifacts (e.g., `/etc/kubernetes/`, CNI configurations, and iptables rules), restoring the node to a pre-init state so that `kubeadm init` can succeed cleanly.

Exam trap

The trap here is that candidates may think a simple file deletion or port change is sufficient, but the CKA exam expects you to know that `kubeadm reset` is the only safe, comprehensive cleanup method for re-initializing a cluster on the same node.

How to eliminate wrong answers

Option B is wrong because manually deleting only the kube-apiserver.yaml manifest and killing its process does not remove other critical residual files (e.g., etcd data, kubelet config, CA certificates, or other static pod manifests), leaving the node in an inconsistent state that will still cause `kubeadm init` to fail. Option C is wrong because changing the API server port with `--apiserver-bind-port` does not address the root cause of leftover cluster state; it merely avoids the port conflict temporarily while other conflicts (e.g., existing etcd data, stale certificates) remain. Option D is wrong because `kubeadm init` does not support a `--force` flag; attempting to override errors without proper cleanup can lead to a corrupted or non-functional cluster.

Practice this question →
11
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 →
12
MCQeasy

An administrator is preparing a bare-metal node to join an existing kubeadm cluster. The node has containerd installed and running, swap disabled, and the required kernel modules loaded. Before running kubeadm join, which command should the administrator run to ensure the kubelet registers with the API server using the correct node name?

A.kubeadm config images pull
B.kubeadm join --discovery-token ... --discovery-token-ca-cert-hash ...
C.hostnamectl set-hostname <name> (or verify /etc/hostname) and confirm the kubelet --hostname-override setting matches.
D.kubeadm init --config kubeadm-config.yaml
AnswerC

The kubelet derives its node name from the system hostname unless --hostname-override is set. Ensuring the hostname is the intended unique name, or that the override in /var/lib/kubelet/kubeadm-flags.env matches, guarantees the node registers correctly and avoids duplicate or misleading node entries in the cluster.

Why this answer

The kubelet's node name comes from the system hostname or an explicit --hostname-override, so the administrator must confirm or set the hostname before joining. Pulling images, running init, or invoking join without checking the name risks registering the node under an unintended identity that later requires a reset.

Exam trap

The trap here is believing kubeadm join accepts a --node-name flag to rename the node, when the name is actually determined by the hostname or a kubelet override configured before the join.

Practice this question →
13
MCQmedium

A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?

A.The pod is requesting 2 CPUs as a request, but the quota limits requests.
B.The pod is being created in the wrong namespace.
C.The pod is trying to use more CPU than the node capacity.
D.The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.
AnswerD

This is correct because the namespace has a hard ResourceQuota limit of 2 CPUs (limits.cpu: 2) and currently has 1 CPU already allocated to existing pods. Attempting to create a new pod requesting a limit of 2 CPUs would bring the total requested limit to 3. This exceeds the hard quota of 2, causing the ResourceQuota admission controller to reject the pod creation request.

Why this answer

The ResourceQuota 'compute-quota' sets a hard limit of 2 CPUs for all pods in the namespace. If the current total CPU limit usage is already 1, adding a new pod with a limit of 2 would bring the total to 3, exceeding the quota. Kubernetes enforces ResourceQuota at admission time, rejecting the pod creation to prevent the namespace from exceeding its configured limits.

Exam trap

The trap here is that candidates confuse ResourceQuota enforcement with node capacity or scheduling constraints, but the error is specifically an admission-level quota violation, not a resource shortage on any node.

How to eliminate wrong answers

Option A is wrong because the error is about CPU limits, not requests; the quota specifically restricts limits.cpu, and the pod is requesting a limit of 2 CPUs, not a request. Option B is wrong because the error message does not indicate a namespace mismatch; ResourceQuota is namespace-scoped, but the pod is likely being created in the same namespace as the quota, and the error is about exceeding the quota, not a wrong namespace. Option C is wrong because the error is not about node capacity; node capacity is a scheduling concern handled by the kube-scheduler, while ResourceQuota is an admission control mechanism that rejects the pod before scheduling even considers node resources.

Practice this question →
14
MCQmedium

Refer to the exhibit. An administrator creates a token with TTL 0. What is the effect on the token?

A.The token will never expire.
B.The token will expire after the default TTL.
C.The token expires immediately.
D.The token is invalid and cannot be used.
AnswerA

When a token is created with a TTL (time-to-live) value of 0, Kubernetes treats that as an explicit request to disable expiration. The resulting token contains no `exp` claim or has an `exp` value far in the future, so the API server will not reject it based on time. It remains valid indefinitely until manually revoked, for example by deleting the Secret or Service Account.

Why this answer

Setting TTL to 0 means the token never expires (unless manually deleted). It will persist indefinitely.

Practice this question →
15
MCQmedium

Refer to the exhibit. The master node shows NotReady status. The kubelet is reporting 'container runtime is down'. Which command should be used to investigate and fix this issue?

A.kubectl delete node master && kubeadm reset
B.systemctl status kubelet && systemctl restart kubelet
C.systemctl status containerd && systemctl restart containerd
D.systemctl status docker && systemctl restart docker
AnswerC

In a kubeadm-provisioned cluster, the default and expected container runtime is containerd, with the CRI socket typically located at `/run/containerd/containerd.sock`. If the containerd service has stopped, crashed, or is unresponsive, the kubelet cannot communicate over CRI to create pods or static control-plane pods, causing it to report NotReady. Running `systemctl status containerd` confirms whether the service failed, and `systemctl restart containerd` restores the CRI endpoint so the kubelet can re-establish its connection and recover node status. After restarting, you can validate with `crictl ps` or check that the node becomes Ready within a few minutes.

Why this answer

The kubelet is unable to communicate with the container runtime. Since the master uses containerd (common in kubeadm), checking the containerd service status and restarting it is the first step.

Practice this question →
16
MCQeasy

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

A.kubeadm init --pod-network-cidr=10.244.0.0/16
B.kubeadm init --cidr=10.244.0.0/16
C.kubeadm init --network-cidr=10.244.0.0/16
D.kubeadm init --service-cidr=10.244.0.0/16
AnswerA

This option is correct because kubeadm's --pod-network-cidr flag defines the IPv4 CIDR range from which pod IP addresses are allocated. It is required when installing a pod network add-on such as Flannel, which commonly expects the 10.244.0.0/16 range. The kube-controller-manager then uses this range to assign per-node subnets, enabling cross-node pod communication.

Why this answer

`kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Exam trap

The trap here is confusing `--pod-network-cidr` with `--service-cidr` or inventing flags like `--cidr` or `--network-cidr`, leading candidates to pick options that either do not exist or configure the wrong network range.

How to eliminate wrong answers

Option B is wrong because `--cidr` is not a valid flag for `kubeadm init`; it is used by other tools like `kube-proxy` or `kubectl` but not for initializing the control plane. Option C is wrong because `--network-cidr` is not a recognized flag in kubeadm; the correct flag is `--pod-network-cidr`. Option D is wrong because `--service-cidr` specifies the CIDR for Kubernetes services (default 10.96.0.0/12), not the pod network; using it for pod CIDR would misconfigure the cluster.

Practice this question →
17
MCQhard

A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?

A.The kubelet is not configured with the correct node IP.
B.The new node does not have enough disk space for container images.
C.There is a network connectivity issue between the new node and the control plane.
D.The API server is overloaded and cannot handle the node update request.
AnswerC

A 'context deadline exceeded' error explicitly indicates that a gRPC or HTTP request timed out before receiving a response. In this scenario, network latency, packet loss, or misconfigured firewalls/security groups between the new node and the control plane prevent the kubelet from successfully posting its lease updates to the API server within the allocated timeframe.

Why this answer

The 'context deadline exceeded' error in the kubelet logs indicates that the kubelet on the new node is unable to communicate with the API server within the expected timeout. This is typically caused by network connectivity issues between the node and the control plane, such as firewall rules, incorrect DNS resolution, or a broken CNI plugin. Without successful node-to-API-server communication, the kubelet cannot post its status, leaving the node in 'NotReady' state.

Exam trap

The trap here is that candidates often confuse 'context deadline exceeded' with a resource exhaustion issue (like disk or memory) or a kubelet configuration error, when in fact it is a classic symptom of network connectivity failure between the node and the control plane.

How to eliminate wrong answers

Option A is wrong because an incorrect node IP would cause the kubelet to bind to the wrong interface, but the error 'context deadline exceeded' specifically points to a timeout in reaching the API server, not a local binding issue. Option B is wrong because insufficient disk space for container images would manifest as image pull failures or eviction, not as a kubelet status update timeout. Option D is wrong because an overloaded API server would affect all nodes and clients, not just a single new node, and the error message is specific to the kubelet's update request timing out, not a server-side rejection.

Practice this question →
18
MCQeasy

During a 'kubeadm init', the administrator sees the message 'Your Kubernetes control-plane has been initialized successfully!' but the 'kubectl get nodes' shows the control plane node as 'NotReady'. What is the most likely missing step?

A.Generate a join token for worker nodes.
B.Install a CNI plugin such as Calico or Flannel.
C.Copy the kubeconfig to the user's home directory.
D.Check that the kubelet is running on the control plane node.
AnswerB

Kubernetes requires a Container Network Interface (CNI) plugin to establish the pod network. Until a CNI provider like Calico or Flannel is deployed, CoreDNS pods will remain in a Pending state, and the control plane node will report a status of NotReady due to the missing network configuration.

Why this answer

The 'NotReady' status indicates that the kubelet on the control plane node is running but cannot report readiness because the node's network is not configured. A CNI plugin (e.g., Calico, Flannel, Weave) must be installed to set up the pod network, which is required for the kubelet to register the node as 'Ready'. Without a CNI plugin, the node's network conditions remain unmet, and the control plane cannot function properly.

Exam trap

The trap here is that candidates often assume 'kubeadm init' success means the cluster is fully functional, but they overlook the mandatory post-init step of installing a CNI plugin to make the node 'Ready'.

How to eliminate wrong answers

Option A is wrong because generating a join token for worker nodes is only needed after the control plane is fully operational and ready to accept worker nodes; it does not affect the control plane node's own readiness. Option C is wrong because copying the kubeconfig to the user's home directory enables 'kubectl' access but does not resolve the underlying network issue causing the node to be 'NotReady'. Option D is wrong because the 'kubeadm init' success message implies the kubelet is running; if it were not, the initialization would have failed or the node would show a different status (e.g., 'Unknown').

Practice this question →
19
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 →

Ready to test yourself?

Try a timed practice session using only Cluster Architecture, Installation & Configuration questions.

Start 20-question session
CCNA Cluster Architecture, Installation & Configuration Questions | Courseiva