Cluster Architecture, Installation and Configuration practice questions

--grace-period=0

Why wrong: This flag controls the duration in seconds given to pods to terminate gracefully before being forcefully terminated. While setting it to zero forces immediate deletion of the evicted pods, it does not bypass or resolve the block caused by pods utilizing local storage. Therefore, it cannot be used to safely prevent or force the eviction of local-data pods during a drain operation.

--pod-selector='app=critical'

Why wrong: The kubectl drain command does not support a --pod-selector flag to filter which pods are evicted during a node drain. Instead, the command targets all non-daemonset pods on the specified node to ensure it can be safely decommissioned. To exclude specific pods from eviction, administrators must use other mechanisms like PodDisruptionBudgets or controller configurations.

--evict-unscheduled-pods

Why wrong: This parameter is entirely fabricated and does not exist in the Kubernetes CLI toolset. Unscheduled pods do not reside on any active node and therefore do not need to be evicted during a node maintenance operation. The kubectl drain command only targets active, running, or scheduled pods currently assigned to the node being drained.

ClusterRole and RoleBinding in the default namespace

Why wrong: While a ClusterRole defines cluster-wide permissions, binding it with a RoleBinding restricts those permissions strictly to the namespace where the RoleBinding is created. In this case, creating the RoleBinding in the default namespace limits the monitor service account's access solely to resources within default, failing to provide cluster-wide access.

ClusterRole and RoleBinding in kube-system

Why wrong: Utilizing a RoleBinding within the kube-system namespace to bind a ClusterRole localizes the granted permissions exclusively to kube-system. The monitor service account would be unable to view or manage resources in any other namespace, such as default or user-defined namespaces, defeating the requirement for cluster-wide monitoring capabilities.

Role and RoleBinding in the default namespace

Why wrong: Both Roles and RoleBindings are strictly namespace-scoped Kubernetes resources. Creating a Role and a corresponding RoleBinding in the default namespace confines the monitor service account's permissions entirely to default, making it impossible to access cluster-scoped resources or resources in other namespaces.

kubeadm upgrade apply v1.29.0

Why wrong: While `kubeadm upgrade apply` is the actual command used to execute the control plane upgrade to a specific version, running it directly without first executing `kubeadm upgrade plan` is a violation of recommended operational practices. The planning phase is critical to verify the upgrade path, check API compatibility, and ensure the cluster state is healthy. Skipping the plan step can lead to unexpected failures during the live upgrade execution.

kubeadm upgrade node

Why wrong: The `kubeadm upgrade node` command is specifically designed to upgrade secondary control plane instances and worker nodes after the primary control plane node has already been successfully upgraded. It does not perform the initial cluster-wide upgrade planning or apply the main control plane configuration changes. Attempting to run this command first on the primary control plane node will fail to initiate the overall cluster upgrade.

kubeadm upgrade diff

Why wrong: There is no `diff` subcommand under `kubeadm upgrade` in the standard Kubernetes administration toolset. While tools like `kubectl diff` exist to compare local manifests with live cluster states, `kubeadm` does not offer a native `diff` command to preview upgrade changes. To see the proposed changes and version differences before upgrading, administrators must rely on the output of `kubeadm upgrade plan`.

etcdctl backup --data-dir /var/lib/etcd

Why wrong: The `etcdctl backup` command is a legacy command that relies on the deprecated etcd v2 API. Modern Kubernetes clusters utilize etcd v3, which manages data differently and requires the `snapshot` command instead of `backup` to ensure consistent state capture.

etcdctl export --data-dir /var/lib/etcd

Why wrong: The `etcdctl` command-line utility does not possess an `export` subcommand for backing up or migrating data. Attempting to run this command will result in a command-line syntax error, as etcd relies strictly on the `snapshot` subcommand for creating database backups.

etcdctl snapshot save --endpoints=http://127.0.0.1:2379 /backup/snapshot.db

Why wrong: Without explicitly setting the `ETCDCTL_API=3` environment variable, the `etcdctl` tool defaults to using the v2 API on many systems. Because the `snapshot` subcommand is exclusive to the v3 API, this command will fail with a command-line syntax error.

Completed

Why wrong: "Completed" is not a valid value for the Pod's status.phase field. The Kubernetes API only defines Pending, Running, Succeeded, Failed, and Unknown as valid phases. When a container exits with code 0 under restartPolicy: Never, the kubelet marks the phase as Succeeded, not "Completed," so this label is incorrect.

Failed

Why wrong: "Failed" describes a Pod phase where a container exits with a non-zero exit code or where the scheduler/kubelet cannot start the container (e.g., image pull failure). In this scenario, the container has exited with status 0, which is a successful termination; thus the phase cannot be Failed. Only a non-zero exit would transition the pod to Failed under restartPolicy Never.

Running

Why wrong: "Running" is a transient phase that means at least one container is still executing or is in the process of starting or restarting. For a Pod with restartPolicy: Never, once the container exits, even with status 0, the phase immediately moves away from Running to a terminal phase. Because the container has already exited, the Running phase is impossible, so this option is wrong.

Username/password via HTTP Basic Auth

Why wrong: Username/password authentication via HTTP Basic Auth is not a valid method because the -basic-auth-file flag was removed from the API server as of Kubernetes v1.19. Even when it existed, it encoded credentials in base64 and transmitted them with every request, offering no protection against interception. It has been replaced by token-based and certificate-based mechanisms that provide stronger identity guarantees.

Static password file

Why wrong: A static password file is not a valid authentication method because the API server no longer supports the --basic-auth-file and --token-auth-file flags; they were deprecated with basic auth and removed before v1.19. Static passwords in a CSV file are stored in plaintext and do not support rotation or expiry, making them insecure and inadequate for production clusters. Kubernetes now only accepts token-based authentication, either via a configured webhook, OIDC, or service account tokens.

Upgrade all worker nodes first, then upgrade the control plane nodes.

Why wrong: Upgrading worker nodes before the control plane violates Kubernetes version skew policies. The kubelet on a worker node must not be newer than the kube-apiserver, as the control plane components cannot manage newer worker node APIs. Therefore, the control plane must always be upgraded to the target version before any worker nodes are updated.

Upgrade all nodes simultaneously by running kubeadm upgrade apply on all nodes at once.

Why wrong: Attempting a simultaneous upgrade across all nodes will cause severe cluster downtime and database corruption within the etcd quorum. The kubeadm upgrade apply command is designed to run exclusively on the first control plane node to bootstrap the upgrade. Other nodes must be upgraded sequentially using kubeadm upgrade node to maintain high availability.

Upgrade worker nodes, then upgrade the control plane nodes, then drain the worker nodes.

Why wrong: This strategy incorrectly sequences the node upgrades and performs the node draining too late. Nodes must be drained before they are upgraded to safely evict running workloads and prevent application disruption. Additionally, upgrading the workers prior to the control plane violates the Kubernetes API compatibility guarantees.

etcdctl dump

Why wrong: The dump subcommand does not exist in the etcdctl CLI utility for the purpose of database backups. While some database systems use the term dump to export schemas or data, etcd relies on point-in-time snapshotting of its underlying keyspace. Attempting to run this command will result in a command-line syntax error.

etcdctl snapshot create

Why wrong: Although create is a common verb in Kubernetes and other CLI tools for generating resources, it is not a valid subcommand under etcdctl snapshot. Using snapshot create will fail with an error indicating that the command is unrecognized. The utility strictly expects the save verb to initiate a backup of the keyspace.

etcdctl backup

Why wrong: The backup subcommand was used in the legacy etcd v2 API but has been completely deprecated and removed in etcd v3. Since modern Kubernetes clusters exclusively use etcd v3, attempting to run etcdctl backup will fail. Instead, the modern API requires using the snapshot subcommand hierarchy to perform backups.

kubectl uncordon <node-name>

Why wrong: This command performs the exact opposite action by setting the Node's .spec.unschedulable field back to false. It allows the scheduler to resume placing new workloads onto the node. While related to node scheduling state, it is used to restore schedulability rather than marking a node as unschedulable.

kubectl drain <node-name>

Why wrong: While this command does implicitly cordon the node first, its primary purpose is to safely evict or delete all running pods from the node so it can be taken down for maintenance. Using this command goes beyond simply marking a node as unschedulable, as it actively disrupts and migrates existing workloads, which may not be the desired outcome.

kubectl taint nodes <node-name> key=value:NoSchedule

Why wrong: Applying a NoSchedule taint prevents pods from being scheduled on the node unless they possess a matching toleration. This does not strictly mark the node as globally unschedulable, because pods with the correct toleration can still be scheduled there. In contrast, cordoning a node is an absolute restriction that applies to all pods regardless of their tolerations.

kube-scheduler

Why wrong: The kube-scheduler is a control plane component that runs on the control plane nodes and selects which worker node will run a newly created pod by evaluating resource requirements, affinity rules, and other constraints. It is not a worker-node process like kubelet, and its decision-making role is essential to cluster orchestration. Thus, it is not the correct answer.

etcd

Why wrong: etcd is the distributed, consistent key-value store that holds the entire cluster state, including all Kubernetes objects, configuration, and metadata. It runs as a control plane component, and the kube-apiserver is the only component that interacts with it directly, ensuring strong consistency for cluster data. Because it resides on control plane nodes, it qualifies as a control plane component.

kube-apiserver

Why wrong: The kube-apiserver is the front end of the control plane and exposes the Kubernetes REST API, validating and processing all requests from clients, including kubectl commands and controller operations. It stores cluster state in etcd and coordinates other control plane components, making it a core control plane component. Therefore, choosing it would be incorrect.

container runtime

Why wrong: The container runtime (for example, containerd or CRI-O) is responsible for executing containers, managing image pulls, and enforcing cgroups and namespaces for isolation. While it may invoke CNI plugins to give a Pod a network interface, it does not program the cluster network rules for Services. Those forwarding rules—such as iptables or IPVS rules for ClusterIP—are installed by kube-proxy, not by the container runtime.

kubelet

Why wrong: The kubelet is the node agent that communicates with the control plane to ensure Pods are running; it starts or restarts containers, mounts volumes, and reports node and pod status. As part of pod synchronization it can prepare the pod's network namespace at the node level, but it does not maintain Service-level network rules. When a Service is created, kube-proxy reacts to API changes and creates the connection-forwarding rules, while the kubelet only supervises the local pod lifecycle.

kube-scheduler

Why wrong: The kube-scheduler is a control-plane component that selects a node for a newly created Pod based on resource requirements, taints and tolerations, and affinity or anti-affinity constraints. Once it chooses, it creates a Binding object so the kubelet can start the Pod. It never inspects network policies or Service rules, nor does it modify iptables or IPVS; its sole concern is placement, so it cannot be responsible for managing network rules.

kubeadm upgrade plan

Why wrong: While kubeadm upgrade plan does perform a check on the current cluster state, its primary purpose is to analyze whether the cluster can be upgraded to a newer Kubernetes version. It checks the local kubeadm configuration, the versions of control plane components, and lists the available upgrade targets. It does not provide a comprehensive breakdown of certificate expiration dates for the active control plane components.

kubeadm certs renew

Why wrong: The kubeadm certs renew command is used to actively regenerate and extend the validity of Kubernetes control plane certificates, either individually or all at once. While it modifies the certificates to prevent expiration, it is an action-oriented command rather than an informational query tool. Running this without assessing the current expiration status first is not a safe or standard way to inspect certificate health.

kubectl get certificates

Why wrong: Out of the box, Kubernetes does not have a native core resource type named certificates that can be queried via kubectl get. While third-party tools like cert-manager introduce a Certificate Custom Resource Definition (CRD), standard Kubernetes control plane certificates managed by kubeadm are stored directly as files on the host filesystem and are not exposed as native Kubernetes API resources.

Username and password

Why wrong: Username and password authentication was historically supported via the --basic-auth-file flag, but it has been deprecated and removed from Kubernetes. The API server would parse a CSV file with password, username, and optional UID/GID, sending plaintext credentials over the wire unless TLS was used. This method is insecure because passwords are stored in plaintext and never hashed, and modern Kubernetes therefore relies on token-based or certificate-based authentication.

SSH keys

Why wrong: SSH keys authenticate an entity to a remote host via the SSH protocol, establishing an encrypted shell session. The Kubernetes API server has no mechanism to validate SSH public keys or signatures as part of its authentication chain; it only accepts HTTP-based authentication methods. SSH keys are relevant for node-level access through tools like ssh or kubectl exec with SSH, but they do not authenticate a user to the Kubernetes API.

kubectl delete node <node>

Why wrong: kubectl delete node <node> is no substitute for drain or cordon; it removes the Node object from the Kubernetes API, which does not terminate or evict the pods running on it. The kubelet on that machine will usually re-register the node automatically, and existing workloads continue running, so it is not a scheduling management action. This command is only appropriate when permanently removing a node from the cluster, and it bypasses the PodDisruptionBudget protections entirely.

kubectl taint <node>

Why wrong: kubectl taint <node> is not a node-management command in the same sense as cordon or drain: it applies a scheduling constraint that makes a node repel pods unless they have a matching toleration. The full command also requires a taint specification such as key=value:NoSchedule, and it only influences future pod placement rather than evicting existing workloads. While taints are an important scheduler mechanism, they are not the right tool for generally taking a node out of service.

kubectl scale node <node>

Why wrong: kubectl scale node <node> is invalid because kubectl scale is intended for workload resources like deployments, replicasets, and statefulsets, not for node objects. Nodes do not have a concept of replica count or scaling; attempting this command will cause kubectl to reject it or fail to find a corresponding resource type. To manage a node's availability you must use drain or cordon.

kube-scheduler

Why wrong: The kube-scheduler is a control plane component responsible for selecting the optimal node for newly created or unscheduled pods based on resource requirements, policies, and constraints. It does not manage the actual lifecycle, creation, or execution of containers on the node once the assignment and binding are completed.

kube-controller-manager

Why wrong: The kube-controller-manager runs core control loops, such as the ReplicaSet and Deployment controllers, that regulate the global state of the cluster toward the desired state. While it instructs the API server to create or delete pod definitions to match desired replicas, it does not directly execute or manage container lifecycles on individual worker nodes.

kube-proxy

Why wrong: The kube-proxy is a network agent running on each node that maintains host network rules and performs connection forwarding. It implements the Kubernetes Service abstraction by managing iptables, IPVS, or NFTables rules to route traffic to backend pods, but it plays no role in managing pod or container lifecycles.

etcdctl snapshot restore /backup/snapshot.db

Why wrong: This command is used to restore an existing etcd snapshot to a data directory, rather than taking a new backup. Additionally, executing it without specifying the API version or providing the necessary TLS certificates and endpoints will fail to interact with a secure Kubernetes etcd cluster.

ETCDCTL_API=2 etcdctl backup --data-dir /var/lib/etcd

Why wrong: This command incorrectly utilizes the deprecated v2 API and the legacy backup subcommand, which is incompatible with the v3 data store used by modern Kubernetes clusters. To capture a consistent state of a running Kubernetes etcd database, you must use the v3 API's snapshot save command instead of copying raw data files.

etcdctl snapshot save /backup/snapshot.db

Why wrong: Although this command uses the correct snapshot save subcommand, it will fail in a standard, secure Kubernetes environment because it lacks the necessary TLS authentication parameters. Without specifying the endpoints, CA certificate, client certificate, and private key, the etcdctl client cannot establish a trusted connection to the encrypted etcd member.

spec: serviceAccountName: app-sa automountServiceAccountToken: false

Why wrong: Using automountServiceAccountToken: false in the Pod spec explicitly disables the automatic mounting of the service account token into the container. While this is a valid boolean setting, it contradicts the developer's stated intent to create a service account for use; without the token mounted, the application cannot authenticate to the Kubernetes API using that service account's identity. This configuration is not incorrect syntax, but it is functionally wrong for the typical purpose of assigning a service account.

spec: serviceAccountName: app-sa automountServiceAccountToken: "true"

Why wrong: The YAML value "true" is a string because it is enclosed in double quotes. However, automountServiceAccountToken is defined in the Kubernetes PodSpec as a boolean field, so it must be written as the unquoted literal true or false. When the API server attempts to parse this field, it will reject the manifest with a validation error because a string cannot be assigned to a boolean field. Therefore this specification would not be accepted by Kubernetes.

spec: serviceAccount: app-sa

Why wrong: The field name serviceAccount is a legacy alias that was deprecated in Kubernetes v1.22 and removed from the API in v1.25. Using it now would cause a validation failure because current Kubernetes API versions no longer recognize this field; the correct, supported field is serviceAccountName. Even if it did work, it would not allow separate control over token mounting, so it is not a suitable replacement for the requested configuration.

kubectl drain node1

Why wrong: Running `kubectl drain node1` goes beyond simply marking the node as unschedulable; it actively evicts all running pods from the node (except daemonsets) and reschedules them elsewhere. This is too disruptive if the goal is merely to prevent new workloads from landing on the node while allowing existing ones to continue running or being investigated.

kubectl taint nodes node1 key=value:NoSchedule

Why wrong: `kubectl taint nodes node1 key=value:NoSchedule` is incorrect because, while it prevents pods without a matching toleration from being scheduled, it does not prevent *all* new pods. Pods with a toleration for `key=value` would still be scheduled onto 'node1'. This command is useful for dedicating nodes to specific workloads by requiring pods to explicitly tolerate the taint, such as reserving a node for control plane components or specialised hardware, but it does not achieve a complete scheduling block for all new pods as required by the scenario.

kubectl delete node node1

Why wrong: Executing `kubectl delete node node1` completely removes the node object from the Kubernetes API server's registry. This does not gracefully stop scheduling; instead, it causes the control plane to lose track of the node entirely, leading to immediate rescheduling of its pods and potentially leaving the physical or virtual machine in an unmanaged, orphaned state.

Run 'kubeadm init phase certs kubelet-client'

Why wrong: While the 'kubeadm init phase' command suite is used during cluster bootstrapping to generate initial assets, there is no sub-command 'kubeadm init phase certs kubelet-client' designed for renewing an existing certificate. Attempting to run this command will result in an error, as certificate renewal tasks are properly managed under the dedicated 'kubeadm certs renew' command suite.

Renew all certificates using 'kubeadm certs renew all'

Why wrong: Although executing this command successfully renews every control plane certificate managed by kubeadm, it is inefficient and incorrect when the objective is to target only the kubelet client certificate. In a production environment or a CKA exam scenario, you should follow the principle of least disruption by renewing only the specific expired certificate identified.

Delete the old certificate and restart kubelet

Why wrong: Deleting the certificate files manually and restarting the kubelet service will not automatically regenerate the required client certificates on a kubeadm-managed control plane node. This destructive action can lead to API server communication failures and cluster instability, whereas kubeadm provides safe, built-in commands designed specifically to handle certificate lifecycles gracefully.

kube-controller-manager

Why wrong: While the kube-controller-manager is a crucial control plane component, its primary role is to run controller processes that regulate the state of the cluster. It continuously monitors the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. It does not actually store any persistent state itself.

kube-scheduler

Why wrong: The kube-scheduler is responsible for detecting newly created pods that have no node assigned and selecting the optimal node for them to run on. It makes these scheduling decisions based on resource requirements, policy constraints, and affinity specifications. However, it relies entirely on the API server to read and write this state, possessing no storage capabilities of its own.

kube-apiserver

Why wrong: The kube-apiserver acts as the front end for the Kubernetes control plane, exposing the API and validating all incoming requests. Although all other components communicate with it to query or update cluster configuration, the API server is stateless. It does not persist the cluster state directly, instead delegating all storage operations to the backing datastore.