Cluster Architecture, Installation and Configuration practice questions

--grace-period=0

Why it fails: 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 it fails: 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 it fails: 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.

Drain the node, then run 'kubeadm upgrade node' on the worker node.

Why it fails: Draining only evicts pods; it does not upgrade the kubelet or kube-proxy binaries on the node. The node stays at v1.28. Draining is a preparatory step before maintenance, and would be correct alongside upgrading kubeadm and kubelet packages, but alone it changes nothing.

Upgrade kubelet on the worker node using the package manager and restart kubelet.

Why it fails: Upgrading kubelet alone leaves the node's kubeadm-managed configuration (kubelet config, kube-proxy) at v1.28, so the node still reports the old version. Package upgrades are the final step after 'kubeadm upgrade node' has applied the new cluster configuration on that worker.

Run 'kubeadm upgrade apply' on the worker node.

Why it fails: 'kubeadm upgrade apply' upgrades the control plane and must run only on control-plane nodes; on a worker it errors out. Workers use 'kubeadm upgrade node' instead. The apply subcommand is correct during the control-plane phase of a kubeadm cluster upgrade.

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

Why it fails: 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 it fails: 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 it fails: 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.

Username/password via HTTP Basic Auth

Why it fails: 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 it fails: 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.

kubectl delete node <node>

Why it fails: 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 it fails: 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 it fails: 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.

spec: serviceAccountName: app-sa automountServiceAccountToken: false

Why it fails: 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 it fails: 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 it fails: 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.

Run 'kubeadm init phase certs kubelet-client'

Why it fails: 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 it fails: 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 it fails: 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.

ClusterRoleBinding with get, list, watch on pods

Why it fails: A ClusterRoleBinding applies permissions globally across the entire Kubernetes cluster, violating the principle of least privilege for this scenario. Binding read-only pod permissions at the cluster level would allow the user to view pods in all namespaces, including sensitive ones like kube-system, rather than restricting access solely to the development namespace.

ClusterRole with get, list, watch on pods

Why it fails: A ClusterRole is a non-namespaced resource definition that, by itself, does not grant any permissions until it is bound to a subject. If this ClusterRole is bound using a ClusterRoleBinding, it would inadvertently grant read-only pod access across all namespaces in the cluster rather than restricting it to the development namespace.

RoleBinding referencing a ClusterRole that has get, list, watch on pods

Why it fails: Referencing a ClusterRole via a RoleBinding in the 'development' namespace would indeed grant read-only access to pods within that specific namespace. However, creating a ClusterRole for this purpose is an over-permissioning of the RBAC definition itself, as ClusterRoles are designed for cluster-scoped resources or permissions intended for multiple namespaces. For permissions strictly confined to a single namespace, a standard Role is the appropriate resource. This option is tempting because a ClusterRole can be bound by a RoleBinding to achieve namespaced access, which is useful when applying the same set of permissions across several namespaces without duplicating Role definitions.

Create a ClusterRoleBinding that binds the ServiceAccount to a ClusterRole

Why it fails: A ClusterRoleBinding associates the ServiceAccount identity with RBAC permissions, but it does not alter what identity a Pod presents. Pods choose their ServiceAccount exclusively through the pod spec field `serviceAccountName` (or `automountServiceAccountToken` for token behavior). Without that pod-level reference, the binding only affects authorization for the ServiceAccount name itself, and the Pod still falls back to the `default` ServiceAccount in its namespace.

Set automountServiceAccountToken: false and manually mount the token as a volume

Why it fails: Setting `automountServiceAccountToken: false` is a valid configuration method because it intentionally disables the automatic mounting of the ServiceAccount token, allowing a cluster administrator to mount the token manually as a projected volume. This is useful when a Pod needs to control token audience, expiration, or path, or when it must avoid credential exposure entirely. The manual mount can point to any token, including one from a custom ServiceAccount, so it is a legitimate way to configure ServiceAccount identity for specialized workloads.

Use the serviceAccount field in the pod spec

Why it fails: The bare `serviceAccount` field in a Pod spec is deprecated and was removed from the Kubernetes API; the only supported field is `serviceAccountName`. An API server on a modern version will reject or ignore `serviceAccount`, leaving the Pod assigned to the `default` ServiceAccount. Relying on that field is therefore not a valid configuration method in current Kubernetes and should never be used in manifests.

kubectl label

Why it fails: The `kubectl label` command attaches key-value pairs to nodes for grouping, selection, or annotation, but it does not alter the node's scheduling state. Node schedulability is governed by the `unschedulable` field in the node's spec, which is set to true/false by cordon/uncordon, not by labels. Applying a label like `unschedulable=true` would have no effect on the scheduler because the scheduler checks the field, not the label.

kubectl drain

Why it fails: `kubectl drain` is a maintenance command that evicts all active pods from a node and, as a side effect, it calls cordon internally to make the node unschedulable. However, its primary purpose is to safely empty a node before maintenance, not to serve as a direct toggle for schedulability. Using drain for routine scheduling changes would unnecessarily evict workloads and require flags like `--ignore-daemonsets`; cordon/uncordon are the dedicated commands for managing the schedulable state.

kubectl taint

Why it fails: `kubectl taint` sets a taint on a node to repel pods that do not have a matching toleration, which is a scheduling constraint based on pod tolerations. Taints influence pod placement by preventing certain pods from being scheduled, but they do not affect the node's overall schedulable flag. Managing node schedulability—whether the scheduler considers the node at all—is done with cordon/uncordon, not with taints.

kube-apiserver

Why it fails: While the kube-apiserver is the primary control plane entry point, it must not be upgraded first. It relies directly on the underlying etcd database for state storage. Therefore, etcd must be upgraded and verified as stable before the API server can be safely transitioned to v1.29.

kube-scheduler

Why it fails: The kube-scheduler is a client of the kube-apiserver and must be upgraded only after the API server has been successfully updated to v1.29. Upgrading the scheduler prematurely can lead to compatibility issues, as it relies on API schemas and endpoints served by the newer API server version.

kube-controller-manager

Why it fails: The kube-controller-manager regulates cluster state by interacting continuously with the kube-apiserver. According to Kubernetes version skew policies, this component must be upgraded after the API server is updated. Upgrading it beforehand risks failures due to unsupported API resources or controller logic mismatches.

kubeadm upgrade node

Why it fails: `kubeadm upgrade node` renews control-plane certificates only as a side effect of a version upgrade, so it cannot target the apiserver certificate alone and may alter cluster versions. It is tempting because it does refresh certificates on the node, but it is intended for upgrading node components, not standalone renewal.

openssl req -new -x509 -days 365 -key /etc/kubernetes/pki/apiserver.key -out /etc/kubernetes/pki/apiserver.crt

Why it fails: Manually regenerating the certificate with openssl bypasses kubeadm's CA and ignores the cluster's existing apiserver.crt configuration, producing a certificate lacking correct SANs and breaking API server trust. It is tempting because openssl genuinely issues certificates, but it is intended for creating new self-signed certificates, not renewing kubeadm-managed ones.

kubectl certificate renew apiserver

Why it fails: `kubectl certificate renew` is not a valid kubectl subcommand; certificate renewal is handled by kubeadm, not the Kubernetes API client. It is tempting because kubectl manages many cluster resources and the Kubernetes API does expose a certificates API for signing CSRs, but that API issues new certificates rather than renewing kubeadm's apiserver certificate.

kubectl get secret my-sa-token-xxxxx -o jsonpath='{.data.token}' | base64 -d

Why it fails: Explanation 3: This command only retrieves an existing token from an already-created Secret; it does not generate a new token or create any object. If the named Secret (`my-sa-token-xxxxx`) does not already exist, the command fails with a `not found` error. Even if it succeeds, it is an inspection/decoding action—the token already had to be created and stored earlier, so it cannot be the answer to a question about creating a token and storing it.

kubectl create serviceaccount my-sa --token

Why it fails: Explanation 4: The `kubectl create serviceaccount my-sa --token` instruction is invalid because the `kubectl create serviceaccount` command only supports the `--dry-run`, `--output`, and `--save-config` flags, not a `--token` flag. Running this command causes kubectl to error out with an unknown flag message before any object is created. Even if the flag were intentionally placed, creating a ServiceAccount alone does not generate a Secret; the ServiceAccount token is only stored in a Secret when a `kubernetes.io/service-account-token` Secret is created referencing that ServiceAccount.

kubectl create token my-sa

Why it fails: Explanation 1: The command `kubectl create token my-sa` requests a new, time-bound token via the TokenRequest API and prints it as a string to stdout. It does not create or persist any Secret object, so the token cannot be used later by a pod through a volume mount or other Secret-based mechanism. The token also has a default TTL, after which it expires, and no associated secret is stored in etcd.

Restarting etcd pod

Why it fails: Restarting the etcd pod merely restarts the etcd process with the same data directory already present on disk. If the etcd store was corrupted, deleted, or lost, a restart will not rehydrate that data from a snapshot; it will just attempt to load whatever is already there. A restart only helps if the process crashed due to a transient issue and the underlying data files are still intact. It is not a restore mechanism and cannot recover data that was permanently lost.

kubeadm reset

Why it fails: kubeadm reset is designed to decommission and clean up a Kubernetes cluster by removing local etcd data, static pods, and all cluster-related files. It does not understand etcd snapshots nor does it have any mechanism to restore data from a backup; instead, it actively deletes the existing etcd data directory (usually /var/lib/etcd) as part of the reset process. Therefore, running kubeadm reset would destroy the current etcd state and certainly cannot be used to recover lost data. It is a teardown utility, not a recovery utility.

kubectl apply -f etcd-backup.yaml

Why it fails: kubectl apply -f etcd-backup.yaml is meant for applying Kubernetes manifest files (like Deployments, Services, or Custom Resources) to the cluster API. An etcd snapshot is not a Kubernetes resource—it is a binary file (or set of files) that must be processed by etcd-specific tools like etcdctl or an etcd operator. Even if the YAML file defines an etcd-related resource, kubectl apply merely submits that manifest to the API server; it does not perform any data restoration on the etcd backend itself. Thus, this command has no direct role in restoring etcd data from a backup.

Upgrade the container runtime on worker nodes before the control plane

Why it fails: Upgrading the container runtime on worker nodes before the control plane violates the upgrade ordering that kubeadm prescribes. In a standard kubeadm cluster upgrade, the control plane components are upgraded first, and only after that succeeds are worker node kubelets and container runtimes upgraded. While the runtime itself can technically be upgraded independently, doing so before the control plane can produce version-skew mismatches (e.g., kubelet vs. container runtime API validation) that are hard to troubleshoot. Thus, this is not a valid step in the typical sequence.

Delete all pods before upgrading

Why it fails: Deleting all pods before upgrading a node is both unnecessary and harmful. The correct approach is to drain the node, which cordons it and evicts pods gracefully, respecting PodDisruptionBudgets and ensuring replacements are scheduled on other nodes. Deleting pods manually does not move them to other nodes; they are simply removed, and the ReplicaSet/Deployment controller will recreate them elsewhere, but this bypasses graceful eviction and can cause downtime. Furthermore, many cluster-critical system pods (like DaemonSet pods) are not deleted by a cluster-wide delete and will be recreated immediately, making the operation futile.

Create a ClusterRole in the 'production' namespace and a RoleBinding in the 'ci' namespace.

Why it fails: ClusterRoles are cluster-scoped; they cannot be created inside a namespace, so this manifest is invalid. A Role in production plus a RoleBinding in production would suffice. ClusterRoles suit granting permissions across all namespaces, paired with ClusterRoleBindings for cluster-wide access.

Create a Role in the 'production' namespace and a RoleBinding in the 'ci' namespace referencing the Role.

Why it fails: A RoleBinding only grants permissions within its own namespace, so placing it in 'ci' cannot confer access to pods in 'production'. The binding must reside in 'production' alongside the Role. This pattern is correct when the ServiceAccount and target resources share one namespace.

Create a Role in the 'ci' namespace and a RoleBinding binding the ServiceAccount to the Role.

Why it fails: A Role in 'ci' scopes permissions to that namespace only, so it cannot authorise listing pods in 'production'. The Role must live where the pods reside. This arrangement is correct when the ServiceAccount needs permissions over resources within its own namespace.

kube-scheduler

Why it fails: The kube-scheduler is a control plane component responsible for selecting the most appropriate node for newly created or unscheduled pods based on resource requirements, constraints, and policies. It does not run containers directly, nor does it execute on worker nodes to manage container lifecycles. Once it binds a pod to a node, its job is complete, handing off execution duties to the kubelet.

kubelet

Why it fails: The kubelet is the primary node agent that ensures containers described in PodSpecs are running and healthy on a specific node. However, it does not run containers itself; instead, it acts as an orchestrator on the node, communicating with the container runtime via the Container Runtime Interface (CRI) to request container creation, start, and stop operations.

kube-proxy

Why it fails: The kube-proxy is a network daemon running on each node that maintains network rules to allow network communication to your Pods from network sessions inside or outside of your cluster. It manipulates IP tables, IPVS, or NFTables on the host to route traffic destined for Services to the correct backend pods, playing no role in container execution or lifecycle management.

ConfigMap

Why it fails: A ConfigMap is a Kubernetes object used to store non-confidential configuration data in key-value pairs, such as environment variables, command-line arguments, or config files for containers. It has no networking layer role and cannot accept network traffic, resolve DNS names, or route requests to pods. Consequently, ConfigMap does not expose pods or a set of containers in any way, making it invalid for this purpose.

Deployment

Why it fails: A Deployment is a workload API object that manages replicas of pods through a ReplicaSet, ensuring the desired number of pod replicas are running and enabling rolling updates. However, a Deployment does not allocate a stable network identity or a virtual IP; the Pods it creates are ephemeral and get new IP addresses. Exposing a set of pods requires a Service to provide a stable endpoint, so a Deployment alone is not a valid exposure mechanism.

NetworkPolicy

Why it fails: A NetworkPolicy is a specification of how groups of pods are allowed to communicate with each other and with other network endpoints. It acts as a firewall by selecting pods with labels and applying rules that allow or deny traffic based on ports, IP blocks, and namespaces, but it does not create endpoints or open inbound access to a set of pods from outside the cluster. Instead, it constrains traffic to already-exposed Services, and thus it is not a means of exposing pods.

After restoring a snapshot, you must restart all etcd members manually

Why it fails: The statement overstates the restore procedure. When you run etcdctl snapshot restore, it writes a new data directory for a single member, and only that node's etcd process needs to be started (typically via systemctl start etcd). The other cluster members do not all require manual restarts; they either rejoin through the cluster's reconfiguration process or are re-added individually with etcdctl member add, so the claim that 'all members must be restarted manually' is inaccurate.

Etcd snapshots exclude cluster member information

Why it fails: Etcd snapshots are not missing member information—they deliberately include the raft cluster's membership configuration. When a snapshot is captured, it contains the ConfState (the raft cluster state, including member identities and their peer addresses) so that a restored member can reestablish the correct cluster topology. Without this member information, a restored etcd node could not rejoin the quorum or safely reconstruct the network membership, so this option is false.

kubeadm alpha certs check-expiration

Why it fails: kubeadm alpha certs check-expiration is a stale command from the era when kubeadm's certificate management features were still in an alpha staging area. In current kubeadm versions the alpha subcommand has been removed, and the stable command is simply kubeadm certs check-expiration. Running the alpha variant will fail with an unknown command error, so it cannot be the correct answer.

kubectl get secret -n kube-system

Why it fails: The kubectl get secret command against the kube-system namespace lists Kubernetes secrets, including the cluster CA and front-proxy CA, but it does not decode or parse the x509 certificate contents to show expiry dates. To see expiration one would need to extract the cert data and run openssl, which is not what the question asks for. It is a valid troubleshooting step but not a direct expiration-check command.

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

Why it fails: openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates will print the notBefore and notAfter fields of only that specific apiserver certificate file. While that provides expiration for that single cert, kubeadm manages many certificates (etcd, apiserver, kubelet, front-proxy), and checking them individually is inefficient and incomplete. The question explicitly asks for the kubeadm-native way to check all certificate expirations, making this a per-file manual approach rather than the correct answer.