Courseiva

CCNA Cluster Architecture, Installation & Configuration Questions

34 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

Correct flag to specify pod network CIDR for Flannel.

Why this answer

Option B is correct because `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

kubeadm join with --control-plane is used to add additional control plane nodes.

Why this answer

Option B is correct because 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
Multi-Selectmedium

Which TWO of the following are valid methods to configure the kubelet's node IP address?

Select 2 answers
A.Using the --hostname-override flag.
B.Setting the --node-ip flag in kubelet command line.
C.Setting the --address flag in kubelet command line.
D.Setting the node-ip in the kubeadm-config ConfigMap.
E.Configuring nodeIP in the kubelet configuration file (KubeletConfiguration).
AnswersB, E

This flag directly sets the node IP.

Why this answer

Option B is correct because the `--node-ip` flag explicitly sets the IP address that the kubelet uses to identify itself to the API server and other components. This flag directly configures the node's primary IP for kubelet-to-apiserver communication and is a standard method in both standalone kubelet and kubeadm-deployed clusters.

Exam trap

The trap here is confusing the kubelet's listening address (`--address`) with the node IP used for cluster registration (`--node-ip`), leading candidates to select the deprecated `--address` flag instead of the correct `--node-ip` or `KubeletConfiguration.nodeIP`.

Practice this question →
4
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, a pod network must be installed to enable communication between pods. Nodes remain NotReady until a CNI plugin is deployed.

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 →
5
MCQhard

You are tasked with upgrading a Kubernetes cluster from version 1.24 to 1.25. The cluster has one control plane node and three worker nodes, all running Ubuntu 20.04 with kubeadm. You have already upgraded the control plane node to v1.25.0 and it is healthy. You now need to upgrade the first worker node. On the worker node, you run 'kubeadm upgrade node' and it completes successfully. However, when you run 'kubectl drain worker1 --ignore-daemonsets', the node drain hangs indefinitely. You check the node and find that a DaemonSet pod named 'fluentd-*' is stuck in Terminating state. The DaemonSet is from the logging system and must remain running during the upgrade. You cannot delete the DaemonSet. What is the best course of action to complete the upgrade of this worker node?

A.Reinstall kubelet on the worker node and restart it
B.Skip draining the node and proceed with the kubelet upgrade
C.Add --delete-emptydir-data to the drain command
D.Cordon the node and then run kubectl drain with --force
AnswerD

Cordoning prevents new pods, and --force overrides the DaemonSet pod termination protection.

Why this answer

Option D is correct because the drain is hanging due to a DaemonSet pod stuck in Terminating state. Since DaemonSets are managed by the node controller and cannot be evicted by a normal drain, using `--force` bypasses the preflight checks that prevent drain when pods are not evictable. Cordoning the node first ensures no new workloads are scheduled, and `--force` allows the drain to proceed despite the stuck pod, which will be replaced by the DaemonSet controller on the upgraded node.

Exam trap

The trap here is that candidates think `--force` is only for pods with local data or that draining is optional, but the CKA exam tests the understanding that `--force` is necessary to bypass DaemonSet pod eviction failures during node maintenance.

How to eliminate wrong answers

Option A is wrong because reinstalling kubelet does not address the stuck DaemonSet pod; the drain hangs due to pod eviction failure, not a kubelet issue. Option B is wrong because skipping the drain can cause service disruption; the kubelet upgrade requires draining to safely terminate pods, and skipping it may leave pods running during the kubelet restart, leading to potential data loss or downtime. Option C is wrong because `--delete-emptydir-data` only allows eviction of pods with emptyDir volumes, but the DaemonSet pod is stuck in Terminating state due to the node controller's protection, not because of emptyDir volumes.

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

The conflict is due to the node being updated; retrying should resolve it.

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 →
7
Multi-Selecthard

Which THREE of the following are valid steps to enable audit logging in a Kubernetes cluster?

Select 3 answers
A.Store the audit policy in a ConfigMap and reference it via --audit-policy-configmap.
B.Create an audit policy file defining what events to log.
C.Add the --audit-log-path flag to the kube-apiserver.
D.Restart the kubelet on the control plane node.
E.Mount the audit policy file into the kube-apiserver container.
AnswersB, C, E

The policy file is required.

Why this answer

Option B is correct because audit logging in Kubernetes requires an audit policy file that defines which events (e.g., RequestResponse, Metadata) should be logged. This policy file must be created and then passed to the kube-apiserver via the --audit-policy-file flag. Without a policy file, the apiserver will not know what to log, even if other flags are set.

Exam trap

The trap here is that candidates may confuse the --audit-policy-configmap option (which does not exist) with the valid --audit-policy-file flag, or think that restarting the kubelet is necessary for apiserver changes, when in fact the kube-apiserver is a static Pod managed by the kubelet but its configuration is independent.

Practice this question →
8
MCQhard

Refer to the exhibit. An etcd pod on the master node shows repeated rejected connections from node2 (192.168.1.102) and node3 (192.168.1.103). The error indicates non-TLS traffic. What is the most likely cause?

A.The API server is using an incorrect etcd endpoint.
B.The etcd cluster is not configured for TLS, but clients are using TLS.
C.The etcd pod is not using the correct certificate authority.
D.Kube-proxy on node2 and node3 is incorrectly configured to connect directly to etcd using HTTP instead of HTTPS.
AnswerD

Correct. The error from nodes 2 and 3 suggests they are trying to connect to etcd without TLS. Since they are worker nodes, likely kube-proxy or kubelet is misconfigured to reach etcd directly.

Why this answer

The error 'first record does not look like a TLS handshake' means that non-TLS traffic is being sent to etcd's TLS-enabled port. In Kubernetes, components like kube-apiserver communicate with etcd over TLS. But kube-proxy or other components might be sending plain HTTP to the etcd client port.

The fact that node2 and node3 are worker nodes (no control-plane role) suggests that kube-proxy or kubelet is misconfigured to connect to etcd directly instead of via the API server.

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

Correct. The CSR must be approved to allow the node to obtain a certificate and join the cluster.

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 →
10
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 used for etcd client requests; blocking it would cause timeouts.

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

Expired token prevents CA certificate retrieval.

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

Dedicated nodes with fast storage are recommended for etcd performance and stability.

Why this answer

Option C is correct because 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 →
13
MCQeasy

An administrator needs to upgrade the kube-apiserver on a control plane node from version 1.22.0 to 1.23.0. Which of the following is the correct order of steps?

A.Upgrade kubelet, upgrade kubeadm, drain node, uncordon node.
B.Drain node, upgrade kubeadm, upgrade kubelet, uncordon node.
C.Upgrade kubeadm, drain node, upgrade kubelet, uncordon node.
D.Upgrade kubeadm, upgrade kubelet, drain node, uncordon node.
AnswerB

Draining first ensures no workloads are disrupted.

Why this answer

Option B is correct because when upgrading the kube-apiserver, the standard workflow is to first drain the node to evict pods, then upgrade kubeadm (which manages the control plane components), then upgrade kubelet (which runs on the node), and finally uncordon the node to make it schedulable again. This sequence ensures that the node is safely taken out of service before any changes are made, and that the upgrade tools are updated before the components they manage.

Exam trap

The trap here is that candidates often confuse the upgrade order for control plane components with the order for worker nodes, where draining is done after upgrading kubeadm but before upgrading kubelet, but for the control plane, draining must come first to avoid service disruption.

How to eliminate wrong answers

Option A is wrong because it starts with upgrading kubelet before kubeadm, but kubeadm must be upgraded first to ensure it can handle the new version of the control plane components. Option C is wrong because it drains the node after upgrading kubeadm, which risks disrupting running workloads if the upgrade process fails or requires a restart. Option D is wrong because it upgrades both kubeadm and kubelet before draining the node, leaving workloads running during the upgrade and potentially causing downtime or data loss.

Practice this question →
14
Matchingmedium

Match each Kubernetes resource to its primary function.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Smallest deployable unit, runs containers

Stable network endpoint for a set of Pods

HTTP/HTTPS routing to Services

Non-sensitive configuration data

Storage resource provisioned by an administrator

Why these pairings

These are fundamental Kubernetes objects with distinct roles.

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

Permission denied indicates the kubelet cannot read the config file.

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

kubeadm reset removes the cluster state and configuration.

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 →
17
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 CRI error indicates the runtime is not running.

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 →
18
MCQmedium

Based on the exhibit, what is the most likely cause of the worker2 node being NotReady?

A.The kubelet on worker2 has stopped reporting to the control plane
B.The node has insufficient memory
C.The node is experiencing disk pressure
D.The network plugin (Calico) is not running on worker2
AnswerA

The Ready condition is Unknown with message 'Kubelet stopped posting node status'.

Why this answer

The kubelet on worker2 has stopped reporting to the control plane, which is the most likely cause of the node being NotReady. The kubelet is responsible for periodically posting node status updates (including heartbeats) to the API server via the NodeStatus update mechanism. If the kubelet process is down, unresponsive, or cannot communicate with the control plane (e.g., due to network partition or certificate expiry), the node controller marks the node as NotReady after the `node-monitor-grace-period` (default 40 seconds) elapses.

Exam trap

CNCF often tests the distinction between node conditions (MemoryPressure, DiskPressure) and the overall Ready status; the trap here is that candidates confuse a node being under resource pressure (which still allows it to report Ready) with the node being completely unreachable due to kubelet failure.

How to eliminate wrong answers

Option B is wrong because insufficient memory would typically result in the node condition `MemoryPressure` being set to True, but the node would still report as Ready (unless the kubelet evicts pods or the node becomes unreachable). Option C is wrong because disk pressure is indicated by the `DiskPressure` condition, which does not directly cause the node to become NotReady; the node remains Ready but may evict pods. Option D is wrong because if the network plugin (Calico) is not running, the node would still report as Ready (the kubelet continues to report status), but pods would fail to start or have networking issues; the NotReady condition is specifically tied to the kubelet's heartbeat, not the CNI plugin.

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

The quota allows a total of 2, and 1 is already used, leaving only 1 available.

Why this answer

Option D is correct because 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 →
20
MCQmedium

A company wants to install Kubernetes on a set of bare-metal servers with no existing orchestration tools. They need a solution that supports high availability for the control plane and uses etcd operators for cluster management. Which tool should they use?

A.kube-spray
B.kubeadm
C.minikube
D.kops
AnswerB

kubeadm can bootstrap HA clusters and integrates with etcd operators.

Why this answer

kubeadm is the correct choice because it is the official Kubernetes tool for bootstrapping production-grade clusters on bare-metal servers, supporting high availability (HA) for the control plane via stacked or external etcd topologies. It integrates with etcd operators (e.g., etcdadm or the etcd-operator project) for cluster management, allowing automated etcd cluster lifecycle operations. Other tools either lack HA control plane support, are not designed for bare-metal, or do not use etcd operators.

Exam trap

The trap here is that candidates often confuse kubeadm as only a 'simple bootstrapper' and overlook its HA and operator integration capabilities, or they assume kops is suitable for bare-metal because it supports multiple cloud providers, but kops requires cloud-specific infrastructure APIs and does not manage etcd via operators.

How to eliminate wrong answers

Option A (kube-spray) is wrong because it is a deployment tool that uses Ansible to install Kubernetes, but it does not natively integrate etcd operators for cluster management; it manages etcd as a static pod or systemd service, not via operators. Option C (minikube) is wrong because it is designed for local development and testing on a single node, not for production bare-metal servers with HA control plane or etcd operator support. Option D (kops) is wrong because it is primarily for cloud-based Kubernetes deployments (e.g., AWS, GCP) and relies on cloud provider APIs for infrastructure, not for bare-metal servers; it also does not use etcd operators for cluster management.

Practice this question →
21
Matchingmedium

Match each security context setting to its effect.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Specifies the user ID for the container's process

Prevents running as root (UID 0)

Grants elevated privileges to the container

Makes the container's root filesystem read-only

Adds or drops Linux capabilities

Why these pairings

Security contexts define Pod or container privileges and restrictions.

Practice this question →
22
Drag & Dropmedium

Drag and drop the steps to create a Kubernetes cluster using kubeadm into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

kubeadm requires a container runtime first, then you initialize the control plane, configure kubectl, install a CNI plugin, and finally join workers.

Practice this question →
23
Drag & Dropmedium

Drag and drop the steps to deploy an application using a Deployment and expose it with a Service into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

First deploy the Deployment, then create and apply the Service, and finally verify endpoints.

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

Correct. The container runtime (containerd) is likely stopped or crashed. Restarting it should resolve the issue.

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 →
25
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 is the correct flag and value.

Why this answer

Option A is correct because `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 →
26
MCQmedium

A cluster is running on a cloud provider that supports load balancers. An administrator needs to expose a service externally using a cloud load balancer. However, the service remains in 'Pending' state. The cloud provider requires the cluster to be configured with the correct cloud provider flag. Which kube-controller-manager flag is required for this integration?

A.--cloud-provider
B.--cloud-controller-manager
C.--configure-cloud-routes
D.--cloud-config
AnswerA

This flag enables the cloud provider integration.

Why this answer

The `--cloud-provider` flag on the kube-controller-manager tells Kubernetes which cloud provider integration to use (e.g., `aws`, `gce`, `azure`). Without this flag set to the correct provider, the cloud controller manager cannot provision a load balancer for a Service of type LoadBalancer, leaving it in 'Pending' state because the external IP allocation never completes.

Exam trap

The trap here is that candidates confuse `--cloud-provider` with `--cloud-config` or think `--cloud-controller-manager` is a flag, when in fact the cloud-controller-manager is a separate component that requires `--cloud-provider=external` on the kube-controller-manager to delegate control.

How to eliminate wrong answers

Option B is wrong because `--cloud-controller-manager` is not a flag for the kube-controller-manager; it is a separate binary (cloud-controller-manager) that runs as a pod or static pod when cloud provider integration is enabled. Option C is wrong because `--configure-cloud-routes` controls whether the controller manages cloud provider routing tables (e.g., for pod network CIDRs), not the provisioning of load balancers for Services. Option D is wrong because `--cloud-config` specifies the path to a cloud provider configuration file (e.g., for credentials or region), but it is used alongside `--cloud-provider` and does not by itself enable cloud provider integration.

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

Context deadline exceeded indicates timeout reaching the API server.

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 →
28
MCQmedium

A cluster administrator has configured a PodSecurityPolicy (PSP) that requires all pods to run with read-only root filesystem. However, a newly deployed pod is failing to start with the error 'container has runAsNonRoot and image will run as root'. The PSP is designed to prevent running as root. What is the most likely cause?

A.The PodSecurityPolicy admission controller is not enabled.
B.The PSP is not set to enforce read-only root filesystem.
C.The container image is configured to run as root user.
D.The PSP is not being applied to the pod's service account.
AnswerC

The PSP requires runAsNonRoot, but the image runs as root.

Why this answer

The error message 'container has runAsNonRoot and image will run as root' indicates that the PodSecurityPolicy (PSP) is configured with `runAsNonRoot: true`, but the container image itself is built to run as the root user (UID 0). The PSP enforces that the container must not run as root, but the image's default user is root, causing the admission controller to reject the pod. Option C correctly identifies this mismatch as the most likely cause.

Exam trap

The trap here is that candidates confuse the 'read-only root filesystem' constraint with the 'runAsNonRoot' constraint, or assume the error is about PSP not being applied, when in fact the error message directly points to the image running as root despite the PSP requiring non-root execution.

How to eliminate wrong answers

Option A is wrong because if the PodSecurityPolicy admission controller were not enabled, the PSP would not be enforced at all, and the pod would start without the error (the error specifically comes from PSP enforcement). Option B is wrong because the error message is about runAsNonRoot, not read-only root filesystem; the read-only root filesystem setting is a separate PSP constraint that would produce a different error (e.g., 'read-only root filesystem' violation). Option D is wrong because PSPs are applied based on the pod's service account only when the PSP has a `spec.runAsUser.rule` or similar that references the service account; the error here is a direct conflict between the image's user and the `runAsNonRoot` setting, not a missing binding.

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

Without a CNI plugin, node condition stays NotReady.

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

This is the standard Kubernetes method for encrypting secrets at rest.

Why this answer

Option B is correct because 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 →
31
MCQmedium

Refer to the exhibit. A pod named nginx-pod is stuck in Pending state. Based on the describe output, what is the most likely cause?

A.The pod's resource requests exceed available capacity.
B.All nodes have taints that the pod does not tolerate.
C.The pod has a node selector that doesn't match any node.
D.The scheduler is not running properly.
AnswerB

Correct. The event message explicitly states that all nodes have untolerated taints, preventing scheduling.

Why this answer

The pod cannot be scheduled because all nodes have taints that the pod does not tolerate. The events show both 'not-ready' and 'unreachable' taints. However, 'kubectl get nodes' shows all nodes as Ready.

This suggests a mismatch: the node conditions may have changed after the pod was created, or the scheduler's cache is stale. But the immediate reason is the taints.

Practice this question →
32
Multi-Selectmedium

Which TWO of the following are valid commands to upgrade a kubeadm cluster from version 1.22.x to 1.23.x on the control plane node? Assume the node is already drained.

Select 2 answers
A.kubeadm upgrade apply v1.23.0
B.kubeadm upgrade node
C.kubeadm upgrade plan v1.23.0
D.kubeadm upgrade plan
E.kubeadm upgrade diff
AnswersA, D

This applies the upgrade to the specified version.

Why this answer

Option A is correct because `kubeadm upgrade apply v1.23.0` is the explicit command to upgrade the control plane to a specific version (v1.23.0) in a kubeadm cluster. It validates the upgrade path, uploads the new configuration, and applies the upgrade to the control plane components. The node is already drained, so this command proceeds directly with the upgrade.

Exam trap

The trap here is that candidates confuse `kubeadm upgrade plan` (which only shows available upgrades) with an actual upgrade command, or they incorrectly add a version argument to `kubeadm upgrade plan`, which is syntactically invalid.

Practice this question →
33
Multi-Selecthard

A cluster uses etcd with TLS encryption. Which THREE of the following are valid etcd client certificate authentication flags?

Select 3 answers
A.--client-cert-auth
B.--trusted-ca-file
C.--cert-file
D.--key-file
E.--peer-cert-file
AnswersB, C, D

Specifies the trusted CA certificate for verifying client certificates.

Why this answer

Option B is correct because `--trusted-ca-file` specifies the CA certificate used to validate client certificates when client certificate authentication is enabled. This flag is required for etcd to trust incoming client connections that present a certificate signed by the specified CA, forming the basis of mutual TLS (mTLS) authentication.

Exam trap

The trap here is that candidates confuse the flags for enabling client certificate authentication (`--client-cert-auth`) with the flags that supply the actual certificate files (`--cert-file`, `--key-file`, `--trusted-ca-file`), or mix up peer communication flags with client-facing ones.

Practice this question →
34
Multi-Selectmedium

Which TWO of the following are valid methods to add a worker node to an existing Kubernetes cluster that was initialized with kubeadm?

Select 2 answers
A.Use kubeadm token create and then kubeadm join with the token
B.Use kubectl create node command from the control plane
C.Copy the kubeconfig file and manually configure kubelet with the cluster CA and bootstrap token
D.Install kubelet on the worker node and it will automatically join the cluster
E.Run kubeadm init on the worker node and then join
AnswersA, C

This is the standard method to join a worker node.

Why this answer

Option A is correct because `kubeadm token create` generates a bootstrap token that is used by `kubeadm join` to authenticate the new node with the control plane. This is the standard, documented method for adding worker nodes to a cluster initialized with kubeadm, leveraging TLS bootstrap and the Bootstrap Token Authentication protocol.

Exam trap

The trap here is that candidates often confuse `kubeadm init` (for control plane nodes) with `kubeadm join` (for worker nodes), and assume that simply installing kubelet is sufficient for automatic cluster discovery without any authentication configuration.

Practice this question →

Ready to test yourself?

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

Start 20-question session