Select Two (Multi-Select) Questions

kubelet

Why wrong: kubelet runs on worker nodes.

kube-proxy

Why wrong: kube-proxy runs on worker nodes.

container runtime

Why wrong: Container runtime runs on all nodes but is not a control plane component.

Apply a NetworkPolicy with ingress rule allowing from a specific pod only

Why wrong: This alone does not deny other traffic; you need a default deny policy.

Apply a NetworkPolicy with empty podSelector and ingress rule allowing all

Why wrong: This would allow all ingress to all pods.

Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp } and ingress rule with namespaceSelector: { matchLabels: { name: monitoring } }

Why wrong: This selects pods in monitoring namespace, not the monitoring pods themselves.

Using a ConfigMap to store the token and mounting it

Why wrong: ConfigMaps are not for secrets and should not store tokens.

Storing a token in a Secret and mounting it as a volume

Why wrong: Secrets can store tokens, but they are not automatically mounted; they must be explicitly referenced in the pod spec.

Setting the token as an environment variable using the downward API

Why wrong: The downward API does not expose the service account token; it is not available as a field.

kube-proxy

Why wrong: kube-proxy is a network proxy, not a CNI plugin.

CoreDNS

Why wrong: CoreDNS is a DNS server, not a CNI plugin.

The service account does not exist

Why wrong: Missing service account would cause the pod to fail to start (e.g., CreateContainerConfigError), but typically not Pending.

The pod's liveness probe is failing

Why wrong: Liveness probe failures occur after the pod is running, not during scheduling.

The pod's container image does not exist

Why wrong: This would cause ImagePullBackOff after scheduling, not keep the pod Pending.

It also grants access to secrets in the 'development' namespace

Why wrong: The Role's rules in the manifest specify only the resource "pods" under its rule list. RBAC grants permissions to exactly the resource kinds enumerated in a rule, so permissions never extend to other resource types like "secrets." Without an explicit rule listing secrets and the appropriate verbs, this Role cannot read or access Secret objects in the development namespace—or anywhere else.

It grants permissions across all namespaces

Why wrong: A Role in Kubernetes is inherently namespaced and cannot grant permissions across multiple namespaces. Only a ClusterRole, combined with a ClusterRoleBinding or RoleBinding, can authorize requests in all namespaces or for cluster-scoped resources. Since this manifest uses a regular Role, its effective scope is limited to the namespace in which it is created, so the claim of cluster-wide permissions is false.

It allows creating pods in the 'development' namespace

Why wrong: The manifest's verbs are exclusively read operations: "get," "watch," and "list." To create a pod, the RBAC rule must include the verb "create" for the pods resource. Because "create" is absent from the rule, any attempt to POST a new pod to the development namespace would be denied by the API server, so this option is incorrect.

Anonymous requests

Why wrong: While possible, it's not a recommended authentication method and is often disabled.

Password file with usernames and passwords

Why wrong: Kubernetes does not support password file authentication; it uses tokens or certificates.

Restart all containers on the node

Why wrong: Restarting all containers on the node is not a diagnostic procedure; it merely disrupts running workloads and can exacerbate the problem by causing unnecessary pod restarts and downtime. Node NotReady is a kubelet-level condition that is not resolved or diagnosed by cycling containers, as the kubelet itself, not individual containers, is responsible for reporting readiness. This action yields no log output or state inspection to identify the underlying cause, making it an invalid first step in troubleshooting.

Check the kube-apiserver logs on the control plane

Why wrong: The kube-apiserver handles API requests and stores cluster state, but it does not determine or directly influence node readiness. Node conditions are set by the kubelet reporting to the API server, and the kubelet itself is the one that performs readiness checks; any API server connectivity issues would manifest in kubelet logs, not apiserver logs. Checking apiserver logs may reveal control plane health but will not explain why a specific node is NotReady, making it an indirect and ineffective diagnostic for this issue.

Check kube-proxy configuration

Why wrong: kube-proxy is responsible for implementing service networking, including ClusterIP and load balancing, but it has no role in determining node readiness. Node readiness is evaluated by the kubelet using a set of checks, including whether the runtime is healthy and the CNI network plugin is functioning; kube-proxy misconfiguration could cause service connectivity problems but would not cause a node to be marked NotReady. Therefore, inspecting kube-proxy configuration is an irrelevant step for diagnosing a node-level condition like NotReady.

The node has disk pressure

Why wrong: Disk pressure is a specific node condition indicating that the node's disk space is running low, which can trigger eviction of pods to free up resources. While it affects pod scheduling and can lead to performance issues, it does not inherently cause the node to transition to a NotReady state. A node experiencing disk pressure typically remains Ready but with the DiskPressure=True condition, signaling a resource constraint rather than a complete loss of functionality or connectivity.

A pod on the node is consuming excessive memory

Why wrong: A single pod consuming excessive memory will likely be terminated by the kernel's Out-Of-Memory (OOM) killer or by Kubernetes if it exceeds its memory limits. While this affects the specific pod, it is an isolated event within the node's resource management. The node itself, and the kubelet running on it, typically remain healthy and Ready, continuing to report their status to the API server, unless the excessive memory consumption is so severe it destabilizes the entire operating system.

kubectl delete pod pod-name

Why wrong: kubectl delete pod pod-name is not a useful diagnostic step because it merely removes the current pod object. If the pod is controlled by a Deployment, ReplicaSet, StatefulSet, or DaemonSet, a new pod is created with a fresh backoff timer, but the old pod's events, logs, and crash history are discarded. You lose the very information needed to understand why the container failed, and the new pod will likely fall into the same CrashLoopBackOff.

kubectl exec -it pod-name -- sh

Why wrong: kubectl exec -it pod-name -- sh is ineffective because CrashLoopBackOff means the container is repeatedly crashing and restarting, so there is no stable running container to attach to. Even during the brief moments the container starts, exec may fail immediately if the process dies before the shell is established, and the underlying issue is in the startup path rather than an interactive environment. The command also requires at least one running container, which usually does not exist in this state.

kubectl rollout restart deployment

Why wrong: kubectl rollout restart deployment is not the appropriate first step because CrashLoopBackOff is a pod-level runtime failure, not a rollout or deployment configuration issue. Restarting the Deployment forces a new ReplicaSet and new pods, but if the underlying container command, image, or environment is broken, the new pods will still enter CrashLoopBackOff. It also obscures the diagnostic trail and is irrelevant when the pod is not managed by a Deployment or is not yet ready for a rollout-level intervention.

A pod on the node is in ImagePullBackOff

Why wrong: ImagePullBackOff indicates the container runtime cannot pull an image for a specific pod, but the kubelet itself remains operational and continues to report node heartbeats. Node status is determined by kubelet health and resource conditions, not by individual pod failures, so the node stays Ready even if every pod on it is stuck in ImagePullBackOff.

The node has insufficient memory

Why wrong: Insufficient memory creates MemoryPressure, prompting the kubelet to evict pods and potentially set a corresponding condition, but that condition is distinct from Ready. The kubelet still runs, reports node status, and does not lose its ability to communicate with the control plane, so the node is not marked NotReady solely due to memory pressure.

The Kubernetes API server is down

Why wrong: The API server is the control-plane endpoint for cluster state; if it goes down, the kubelet's heartbeat requests fail, but the node itself is not automatically set to NotReady. Node status transitions to Unknown after the grace period if heartbeats cannot be received, and may later become NotReady only when the control plane resumes and reevaluates conditions—so API server downtime alone does not directly flip a node to NotReady.

Increase the CPU request of the pod.

Why wrong: Increasing CPU request does not address the memory insufficiency or taint, so it does not help.

Add a node selector to the pod that matches the control-plane nodes.

Why wrong: Adding a node selector that matches control-plane nodes does not help because those nodes still have the taint that the pod does not tolerate.

kubectl get events -w

Why wrong: The -w flag enables watch mode, which streams subsequent event changes in real time. While the initial snapshot may appear sorted, no sorting operation is performed by the watch itself; it is designed for continuous monitoring, not for producing a sorted view at a point in time, so it does not fulfill the timestamp-sorting requirement.

kubectl get events --sort-by=.metadata.name

Why wrong: Sorting by .metadata.name arranges events alphabetically by their generated resource name, such as a pod name suffixed with a random hash, which has no correlation with when the event occurred. This yields a lexicographic order that is neither chronological nor useful for understanding event sequence, making it incorrect for the intended timestamp-based sort.

kubectl get events --all-namespaces

Why wrong: The --all-namespaces flag expands the query to events across every namespace in the cluster, which aids cluster-wide visibility but does not alter the sort order. The output still uses the default lastTimestamp ordering and ignores creationTimestamp entirely, so this command only broadens scope without providing the required sorting mechanism.

Run 'kubectl get events --all-namespaces'

Why wrong: `kubectl get events --all-namespaces` retrieves cluster-scoped events, such as scheduling failures, image pulls, or node pressure, but it does not fetch the container's stdout/stderr stream. If `kubectl logs` yields no output, events can show why a pod was never scheduled or was evicted, yet they cannot reveal application output that was produced after startup. Events are also ephemeral and may rotate out before you inspect them, making them a supplementary diagnostic rather than a direct replacement for log retrieval.

Run 'kubectl top pod pod-name' to check resource usage

Why wrong: `kubectl top pod pod-name` reports live CPU and memory utilization from the metrics-server, which is useful for identifying resource saturation or throttling, but it never exposes the container log stream. A pod with zero log output might be OOMKilled or stuck in a pending state, and while resource pressure might be a contributing cause, `top` will not show the actual stdout/stderr lines or whether the process wrote anything before failing. Additionally, `top` requires metrics-server to be deployed; in a minimal environment it may fail entirely, so it is not a reliable log-diagnosis step.

Run 'kubectl exec pod-name -- cat /var/log/container.log'

Why wrong: `kubectl exec pod-name -- cat /var/log/container.log` executes a command inside the container, but it does not access the container runtime's managed log stream. Unless the application explicitly writes its own log file to `/var/log/container.log`, that path usually does not exist, and `cat` will return an error such as `No such file or directory` instead of log content. Moreover, `exec` requires a currently running container with a shell or suitable binary, which is often impossible for a container that has crashed or is in a pending state. This approach conflates application-level file logs with the runtime's captured stdout/stderr, and it is not the standard way to retrieve container logs.

kubectl get nodes

Why wrong: kubectl get nodes fetches the Node object from the API server, which reflects the control plane's view of node readiness based on heartbeats and status reported by the kubelet. It will confirm that the node is indeed NotReady, but it provides no diagnostic details about why the kubelet failed to report ready status; the underlying fault could be in kubelet's communication with the container runtime, network issues, or resource pressure, all of which require inspecting logs on the node itself.

journalctl -u docker

Why wrong: journalctl -u docker examines the systemd journal for the Docker daemon, which is the container runtime, not the kubelet. While a node being NotReady can be caused by the container runtime being unhealthy, Docker logs do not reveal the kubelet's own status reporting, registration, or heartbeat failures. Furthermore, many modern Kubernetes nodes use containerd or CRI-O, so Docker-specific logs may be entirely irrelevant if the cluster does not use Docker as the runtime.

kubectl describe pod

Why wrong: kubectl describe pod is meant for inspecting individual pod objects, including their events, scheduled node, containers, and recent state, which is useful for pod-level failures but useless for a node-level NotReady issue. Node readiness is a status recorded by the kubelet about the node's overall health (e.g., disk pressure, PID pressure, memory pressure, kubelet readiness probes), and no amount of pod introspection will reveal why the kubelet is failing to report a Ready status. The troubleshooting target should be the kubelet service on the affected node, not any particular pod.

kubectl top pod --nodes

Why wrong: The correct command is 'kubectl top pods' (plural).

kubectl resource usage

Why wrong: Not a valid kubectl command.

kubectl top node --containers

Why wrong: The correct command is 'kubectl top nodes' (plural).

Node not registered with the cluster

Why wrong: Would cause Node NotReady, not pod Pending.

Container image name is incorrect

Why wrong: Typically causes ImagePullBackOff, not Pending.

The pod's readiness probe is failing.

Why wrong: A failing readiness probe would remove the pod from the Service's endpoint list, so the premise that endpoints exist would be false. Thus, this cannot be the cause when endpoints are present.

The Service name is too long.

Why wrong: Service name length does not affect connectivity.

journalctl -u kubelet

Why wrong: Contains container logs from the kubelet.

kubectl describe pod pod-name

Why wrong: Shows events and state, not logs.

systemctl status kubelet

Why wrong: Shows service status, not container logs.

Run 'kubectl get nodes' to check node status

Why wrong: Node status reflects the overall health of the Kubernetes node (Kubelet, CRI, and kube-proxy) but does not expose the state of pod-to-pod communication paths. A pod can be unable to reach another pod's Service even when all nodes show Ready, because the fault may lie in the Service's endpoint selector, a NetworkPolicy, or iptables/IPVS forwarding rules. Checking node status is a coarse, low-yield diagnostic that won't identify the specific break in the Service-to-pod chain.

Run 'kubectl logs' on the target pod to check application logs

Why wrong: Pod logs contain what the application writes to stdout/stderr, which reflects application-level behavior and not the underlying network forwarding or Service routing. A connectivity failure often occurs before a packet reaches the target container—for example, a NetworkPolicy drop, a Service with no endpoints, or a wrong port—so the target application may never even receive a request and thus log nothing. Logs are useful only after you have confirmed that packets can reach the pod; they cannot reveal why the Service is not routing traffic or why DNS resolution failed.