Refer to the Exhibit Practice Questions

kubectl delete node master && kubeadm reset

Why it fails: This is a destructive, disproportionate response to a transient status condition. `kubectl delete node master` removes the node object from the cluster's etcd, and `kubeadm reset` tears down the local control-plane components, deletes etcd data, and resets the kubelet configuration. The NotReady state is almost never caused by a corrupted node; it is typically a health-check failure from the kubelet being unable to reach the container runtime. Reinitializing the node would require regenerating bootstrap tokens, re-joining the control plane, and restoring the cluster state — far more disruption than simply checking and restarting the runtime service.

systemctl status kubelet && systemctl restart kubelet

Why it fails: The kubelet is the agent that reports node status, but it is a client of the container runtime through the CRI (Container Runtime Interface). If containerd is stopped or hung, the kubelet cannot create pod sandboxes, so it repeatedly fails its runtime readiness probe and transitions the node to NotReady. Restarting the kubelet service alone does not start the runtime; it only re-runs the same failing CRI connection attempts, and the node will remain NotReady until containerd is operational. The proper troubleshooting sequence is to verify the runtime first, then check kubelet logs after the runtime is healthy.

systemctl status docker && systemctl restart docker

Why it fails: This option incorrectly assumes Docker is the configured CRI runtime. Modern kubeadm clusters use containerd by default, and dockershim was removed in Kubernetes 1.24, so Docker is not a drop-in replacement for containerd at the CRI level. Even if Docker is installed on the node, the kubelet will not use it unless explicitly configured through the `--container-runtime-endpoint` flag or the CRI configuration; in a kubeadm setup, that endpoint points to containerd. Restarting Docker when the actual runtime is containerd does nothing to fix the CRI connection broken by containerd being down, so the node would remain NotReady.

The container will be throttled by the kernel's memory management.

Why it fails: Memory is a non-compressible resource in Linux and Kubernetes, meaning it cannot be throttled like CPU. When a container or node runs out of memory, the kernel's Out-Of-Memory killer immediately terminates the offending process rather than slowing down its execution. Therefore, memory management issues will lead to pod termination or eviction rather than kernel throttling.

The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.

Why it fails: Kubernetes does not impose an arbitrary 1 GB limit on memory-backed emptyDir volumes. By default, a tmpfs emptyDir volume can consume up to 50% of the host node's physical memory unless a specific sizeLimit is declared in the pod specification. Since no such limit is configured here, the 3 GB write is fully permissible on a node with 4 GB of RAM.

The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.

Why it fails: There is no default memory limit applied to pods or emptyDir volumes in Kubernetes unless a LimitRange is active in the namespace. Without explicit container memory limits or an emptyDir sizeLimit specified in the manifest, the volume can scale up to the node's available memory capacity. Consequently, the pod will not trigger an Out-Of-Memory kill event simply by writing 3 GB of data.

The volume driver is not installed on node-1.

Why it fails: A missing volume driver would produce a distinctly different failure signature: the kubelet would fail to mount the volume with errors like "failed to mount volume" or "rpc error: code = DeadlineExceeded" from the CSI driver. Here the event explicitly references a missing Secret object, and the container creation is blocked because the kubelet cannot retrieve 'my-secret' from the API server. There is no indication of storage-related issues in the exhibit, so the volume driver is not the cause.

The pod has exceeded its resource limits.

Why it fails: If the pod had exceeded its resource limits, the container would be killed by the kernel OOM killer, which Kubernetes surfaces as `OOMKilled` in the container status or as a `Killing` event with an OOM reason. Neither scenario matches the observed error, which is a failure to find a secret during speculative container configuration. Resource limits do not influence secret resolution—the kubelet must first fetch the secret before it can even attempt to start the container process.

The node 'node-1' is experiencing disk pressure.

Why it fails: Node disk pressure is reported as a node condition (`DiskPressure`) and typically causes the kubelet to evict pods or mark them as `Evicted`, not fail a single pod's container creation with a missing Secret message. The event shown in the exhibit describes the inability to find 'my-secret', which is an API object lookup failure, not a filesystem or storage capacity problem. Were the node under disk pressure, you would also expect additional events for all pods on that node, not an isolated secret error.

kubectl describe node node-1

Why it fails: kubectl describe node node-1 surfaces node-level data such as capacity, allocatable resources, taints, conditions, and kubelet events; it never inspects the containers inside individual pods. A CrashLoopBackOff is a pod-level condition driven by the container runtime reporting a failed exit, and this command cannot reveal the container's exit code, stderr, or restart reason. At best, node pressure could explain why kubelet evicted or restarted a pod, but it does not show why the api container itself is crashing.

kubectl top pod api-6f4d7b9d4c-abcde -n production

Why it fails: kubectl top pod api-6f4d7b9d4c-abcde -n production displays live CPU and memory consumption gathered from the metrics-server; it is a resource telemetry tool, not a diagnostic tool for container failures. Even if resource limits are being hit, CrashLoopBackOff is fundamentally caused by the application process terminating unexpectedly or failing its startup, health checks, or initialization — none of which appear in a metrics snapshot. High usage might be a consequence of a crash loop, but the command provides no access to the previous container's logs, exit code, or error message.

kubectl get deployment api -n production -o yaml

Why it fails: kubectl get deployment api -n production -o yaml emits the desired state of the Deployment: the pod template, container image, environment variables, resource limits, and probe configurations. Because it reflects the declarative spec, it contains no live per-pod restart counters, termination messages, or container logs, so the actual CrashLoopBackOff reason stays hidden. While Deployment status may show available replicas or conditions, it does not tell you whether the current pod's container exited with code 1 or 137, nor what stderr output the previous instance produced before dying.

Increase the apiserver-advertise-address to match the node's external IP.

Why it fails: Increasing the apiserver-advertise-address to match the node's external IP is irrelevant to the NotReady state. This flag only controls the address the API server advertises to clients for reaching it, not the kubelet's readiness or pod networking. The node will remain NotReady because the kubelet cannot report Ready until a CNI plugin configures the pod network, and changing this address does not install or activate any network plugin. Moreover, the control plane is already initialized; altering the advertise address would require re-running kubeadm init or editing the kube-apiserver manifest, which would not fix the missing pod network.

Run kubeadm join on the control plane node.

Why it fails: Running `kubeadm join` on the control plane node is wrong because the control plane node is already part of the cluster and does not need to join itself. The `kubeadm join` command is intended for worker nodes to attach to an existing cluster by providing a discovery token and the API server endpoint; executing it on the control plane node would attempt to register a duplicate node or cause a configuration conflict. Even if it did run, it would not address the underlying issue: the node's `NotReady` status stems from the absence of a pod network, not from a missing node registration.

Restart the kubelet service on all nodes.

Why it fails: Restarting the kubelet service on all nodes may temporarily resolve transient errors (e.g., stale state, file descriptor exhaustion), but it does not fix the root cause of the `NotReady` status. The kubelet is already running and reporting to the API server; otherwise, the node would show as `NotReady` with `NodeNotReady` reason, but the core issue is that the pod network is not configured. The kubelet requires a CNI plugin to set up the pod's network namespace; without it, the kubelet will repeatedly fail the network readiness check and keep the node `NotReady`. Therefore, restarting kubelet is at best a superficial troubleshooting step, not a resolution, and it would not change the missing CNI configuration.

The token will expire after the default TTL.

Why it fails: The default TTL is only relevant when no TTL flag is provided to the token creation command. Since the administrator explicitly passed `--ttl=0`, that value overrides the cluster default, and the default duration is never applied. Consequently, the token does not inherit the standard expiration period and therefore will not expire after the default interval.

The token expires immediately.

Why it fails: A TTL of 0 is a sentinel meaning 'no expiration', not a duration of zero seconds. Immediate expiration would require a very small positive TTL (e.g., 1 nanosecond) or immediate revocation, and the API server would still reject tokens with an `exp` in the past. Because 0 is interpreted as 'never expire', the token remains valid and does not become instantly unusable.

The token is invalid and cannot be used.

Why it fails: TTL=0 does not affect the validity of the token at creation time; the token is signed and registered normally. The zero TTL only influences the token’s expiry behavior, so the token is fully usable for authentication and authorization. Invalid tokens would result from bad signatures, missing audiences, or nonexistent service accounts, not from a zero TTL.