Troubleshooting practice questions

The NodePort is conflicting; change the service type to ClusterIP.

Why it fails: NodePort services expose applications on a port across all cluster nodes, which is handled by kube-proxy at the node level. A container-level port binding conflict occurs within the pod's network namespace, meaning changing the Service type to ClusterIP will not resolve an internal container process failing to bind to its local port.

The container is missing an environment variable required for startup; add it via ConfigMap.

Why it fails: While missing environment variables can cause application startup failures or database connection errors, they do not result in 'address already in use' bind errors. A bind error specifically indicates that the network socket is already occupied by another process within the network namespace, which cannot be resolved by injecting configuration data.

The pod has insufficient memory; increase memory limits in the deployment.

Why it fails: If a pod exceeds its allocated memory limits, the Linux kernel's Out-Of-Memory (OOM) killer terminates the process, resulting in an OOMKilled status (Exit Code 137). This is fundamentally different from a port binding conflict, which is a network socket allocation failure and does not trigger memory-related termination events.

Run 'kubectl logs <pod-name>' to view application logs.

Why it fails: The `kubectl logs` command only reads stdout/stderr from a container that exists and is currently running — a Pending pod has no container yet. The command will fail with an error like 'container not found' or 'pod is not running' because the kubelet has not created any container. Application logs simply do not exist until the Pod is scheduled and started, making this useless for pending-pod troubleshooting.

Run 'kubectl exec -it <pod-name> -- /bin/sh' to inspect the container.

Why it fails: `kubectl exec` requires a running container with which to attach the interactive process; a Pending pod has not been scheduled to a node and thus has no running container. The kubelet will not have started anything, so exec returns an error immediately. Interactive debugging only becomes possible after the pod reaches the Running phase, so this is not a valid method for investigating scheduling failures.

Run 'kubectl top pod <pod-name>' to check resource usage.

Why it fails: `kubectl top pod` displays real-time resource consumption obtained from the metrics server for pods that are currently Running. A Pending pod is not scheduled, has no CPU/memory metrics, and the command typically reports 'no resources found' or the pod is simply not listed. Furthermore, the metrics-server itself must be deployed and fully operational; otherwise the command fails globally. Thus it cannot diagnose why a pod is pending.

kubectl logs deployment/web-app

Why it fails: kubectl logs deployment/web-app streams the logs of a single pod in the Deployment, so it tells you whether the container is crashing or logging requests. It reveals nothing about the Service's selector, targetPort, or endpoint population; a healthy application can still be unreachable if the Service labels don't match the pods. This command is premature until you have verified that the Service actually has endpoints, so it is not the best first diagnostic step.

kubectl get events --sort-by='.lastTimestamp'

Why it fails: kubectl get events --sort-by='.lastTimestamp' gives a time-ordered view of every cluster event, but a Service selector mismatch usually produces no Event at all. The kube-controller-manager might log warnings when endpoints are empty, but those are often in controller logs rather than in Event objects, so sorting events can still hide the exact Service-to-pod relationship. Event history is valuable for broader troubleshooting after you know what to look for; as a first step it casts too wide a net and dilutes the focused signal that a Service description provides.

kubectl describe ingress web-app

Why it fails: kubectl describe ingress web-app inspects Layer 7 HTTP routing rules, but an Ingress backend merely points to a Service name and port; if that Service has no endpoints, the Ingress can look perfectly configured while the application is still unreachable. Additionally, the workload may not be exposed through an Ingress at all, so running this command first could return an Ingress that does not exist and waste time at the wrong network layer. The correct first move is to verify the Service itself, not the Ingress controller's routing configuration, because the Service is the glue between an Ingress backend and the pods.

kubectl logs <pod-name>

Why it fails: This command shows logs from the current container instance, but since the pod is crashing, the crash output is in the previous instance's logs.

kubectl describe pod <pod-name>

Why it fails: This command shows pod specifications and status, but not the container logs.

kubectl logs --previous <pod-name>

Why it fails: Correct. The --previous flag is equivalent to -p and retrieves logs from the previous instance.

Image pull failure

Why it fails: Image pull failure occurs after the sandbox (pause container) is successfully created, because the kubelet first asks the container runtime to create the pod sandbox and only then pulls the application images. A failure to pull an image surfaces as an ErrImagePull or ImagePullBackOff event on the pod, not as a CRI 'CreateContainerSandbox' error. The sandbox creation phase does not depend on the application image being available locally or in the registry.

Node disk pressure

Why it fails: Node disk pressure is a node-level condition that causes the kubelet to evict pods or refuse admission of new pods, but it does not specifically trigger a sandbox creation failure. If disk pressure is present, the kubelet may mark the node as 'MemoryPressure' or 'DiskPressure' and prevent new pods from scheduling, but the underlying CRI sandbox creation call is not directly rejected because the disk is full. To diagnose sandbox creation failures you need to inspect events and logs, not rely on pressure conditions.

Incorrect security context

Why it fails: Incorrect security contexts apply to the container process, not to the creation of the sandbox itself. While the pod's security context (e.g., runAsUser, seccomp, capabilities) is eventually passed to the container runtime, a mistake in it typically causes a 'CreateContainer' error rather than a 'CreateContainerSandbox' error. The sandbox is created before the individual containers are started, and the sandbox only gets basic namespace and network configuration, so a security-context issue is a much later failure point.

kubectl get nodes

Why it fails: kubectl get nodes only shows the cluster's view of node readiness, which is based on the kubelet's last heartbeat. It does not expose any local kubelet state, so if the kubelet has crashed or lost connectivity, this command merely displays the symptom (NotReady) while offering no diagnostic details about why the kubelet stopped reporting; it is useful for confirming the problem, not for debugging it.

Check API server logs

Why it fails: API server logs, while they could show missing kubelet heartbeats, are stored on control plane nodes and are not the most direct way to diagnose a worker node's NotReady status. Searching them is indirect and slow, since the absence of a heartbeat is a downstream effect of the kubelet's local failure; the definitive evidence lives in the kubelet's own systemd state and logs on the affected node, not in the API server's request history.

kubectl get pods -o wide

Why it fails: kubectl get pods -o wide is wrong for diagnosing CrashLoopBackOff because it only expands the output to include the pod's node IP, host IP, and assigned node, none of which explain why the container is crashing. The pod's STATUS will simply show CrashLoopBackOff, but this command does not fetch logs, show termination reasons, or list events, so it gives no insight into the root cause. It is useful for verifying scheduling or network placement, not for debugging an application that continuously restarts.

kubectl edit deployment <deploy>

Why it fails: kubectl edit deployment <deploy> is wrong as a diagnostic step because it mutates the deployment's desired state without first identifying the cause of the crash. When a pod is in CrashLoopBackOff, the issue is usually inside the container image or its runtime configuration, so blindly editing the deployment risks introducing unrelated changes or restarting the rollout without learning what went wrong. After you diagnose the problem—for example, a wrong command or a bad image—this command can be used to apply a fix, but it is not a diagnostic tool for the crash itself.

A PodDisruptionBudget is set with minAvailable: 1

Why it fails: A PodDisruptionBudget (PDB) with minAvailable: 1 only restricts voluntary evictions, such as node drains or cluster autoscaler removals, by preventing the eviction of a Pod if doing so would reduce the available count below 1. It has no effect on the ReplicaSet controller's ability to create new Pods or on the Deployment's scale-up operation, which is an involuntary, non-disruptive change. Therefore, a PDB cannot be the reason a Deployment fails to scale up, making this option incorrect.

Run `kubeadm reset` on the node.

Why it fails: Running `kubeadm reset` destroys the local etcd data, CNI configuration, and kubelet state on the node, effectively tearing down the cluster node. It is a destructive administrative action intended for reinitializing a cluster, not a diagnostic or fix for image pull failures. ImagePullBackOff is an image-level issue handled by the kubelet and container runtime; resetting the node will not change the image reference or registry access, and it needlessly disrupts the entire node.

Increase the pod's resource limits.

Why it fails: Increasing the pod's resource limits does not address image pulling because ImagePullBackOff occurs before the container is started; the kubelet cannot even fetch the image, so CPU and memory limits are irrelevant at that stage. Resource limits affect container scheduling and runtime operations, causing issues like OOMKilled or FailedScheduling if nodes lack capacity. Redistributing resource limits or adding more resources will not make an unavailable image tag pullable or fix registry authentication errors.

Step 1: Create the PersistentVolumeClaim, Step 2: Ensure a PersistentVolume exists, Step 3: Apply the PVC configuration, Step 4: Define the pod with a volume mount referencing the PVC, Step 5: Verify.

Why it fails: Attempting to create and apply a PersistentVolumeClaim before ensuring a compatible PersistentVolume (PV) exists will result in the PVC remaining in a Pending state. In static provisioning, the control plane's volume controller cannot bind the claim unless a matching PV with the correct storage class, capacity, and access modes is already registered in the cluster. Therefore, the PV must be established prior to initiating the PVC lifecycle.

Step 1: Ensure a PersistentVolume exists, Step 2: Define the pod with a volume mount referencing the PVC, Step 3: Create the PersistentVolumeClaim, Step 4: Apply the PVC configuration, Step 5: Verify.

Why it fails: Defining and deploying a Pod that references a non-existent PersistentVolumeClaim will cause the Pod to fail during the scheduling and startup phases, often resulting in a CreateContainerConfigError or remaining stuck in ContainerCreating. The Kubernetes API server and kubelet require the target PVC to be actively registered and bound before the Pod's volume mount can be successfully attached. Thus, the PVC configuration must be fully applied to the cluster before the Pod is defined and scheduled.

Step 1: Ensure a PersistentVolume exists, Step 2: Create the PersistentVolumeClaim, Step 3: Define the pod with a volume mount referencing the PVC, Step 4: Apply the PVC configuration, Step 5: Verify.

Why it fails: This is incorrect because the PVC must be applied (created in the cluster) before the pod definition can use it. Applying the PVC after defining the pod will cause the pod to fail to start.

NodeSelector: Pod scheduling is constrained by required and preferred rules using node labels.

Why it fails: This description is incorrect because required and preferred rules are provided by NodeAffinity, not NodeSelector. NodeAffinity's requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution clauses allow complex label matching with operators such as In, NotIn, Exists, Gt, and Lt. NodeSelector only performs simple equality matching without expressing preference weights or multiple alternative rules.

NodeAffinity: Pod scheduling is constrained by matching node labels with a simple key-value pair.

Why it fails: This statement describes NodeSelector, not NodeAffinity. NodeAffinity, in contrast, supports not only equality matching but also a rich set of operators and both required (hard) and preferred (soft) scheduling rules. While a machExpressions rule with a simple In operator could match a single key-value pair, the concept of NodeAffinity specifically involves these more advanced features. Therefore, equating NodeAffinity with a simple key-value pair match is incorrect.

Fluentd: Stores and indexes log data.

Why it fails: This option misidentifies Fluentd as the storage and indexing tier of a log stack. Fluentd is fundamentally a data collector and shipper: it reads logs from inputs, optionally buffers them on local disk or memory to smooth bursts, and then forwards them to an output backend such as Elasticsearch, S3, or Splunk. Although its buffer persists records temporarily, that spool is not searchable or queryable and is not an analytics engine, so storing and indexing log data is one of the functions Elasticsearch performs, not Fluentd.

Elasticsearch: Collects metrics from targets.

Why it fails: This option conflates a passive data store with an active metrics collector. Elasticsearch does not poll metrics from targets; it listens for HTTP requests from clients and ingests JSON documents (including metrics) that are pushed to it by shippers like Metricbeat, Logstash, Fluentd, or exporter operators. It can expose information about itself via its `_stats` or monitoring endpoints, but that is internal self-telemetry rather than a general-purpose collector, whereas the system that periodically obtains metrics from Kubernetes targets and stores them time-series is Prometheus.

kubectl logs pod-a | curl pod-b

Why it fails: The `kubectl logs pod-a` command retrieves the standard output and standard error streams from the specified container within `pod-a`. Piping this textual log output to `curl pod-b` is syntactically incorrect and semantically meaningless for initiating a network request. `curl` expects a URL or specific command-line arguments to define its target and operation, not arbitrary log data as its standard input for specifying a destination. This command would attempt to feed log content into `curl`, which is not how `curl` is used to test network connectivity.

kubectl port-forward pod-a 8080:8080 & curl localhost:8080

Why it fails: Port forwarding, using `kubectl port-forward`, establishes a secure tunnel from your local machine to a specific port on a pod, allowing you to access a service running inside the cluster from your local workstation. While `curl localhost:8080` would then connect to the forwarded port on your local machine, this mechanism is designed for external access to a pod, not for testing direct network communication *between* two pods residing within the Kubernetes cluster's internal network. It does not enable `pod-a` to initiate a connection to `pod-b`.

kubectl attach pod-a -- curl pod-b

Why it fails: `kubectl attach` is designed to attach to the standard input, output, and error streams of an *already running process* inside a container, typically for interactive debugging or observing an application's real-time output. It does not provide a mechanism to execute new, arbitrary commands like `curl` within the pod's context. The command `curl pod-b` would be incorrectly interpreted as an argument to the `attach` command itself, rather than as a command to be run inside the specified pod.

kubectl exec <pod-name> -- cat /var/log/container.log

Why it fails: `kubectl exec` requires a running container to execute commands; if the Pod is terminated or the container has crashed, there is no live process to attach to, and the command fails. Even during a container's lifetime, the path `/var/log/container.log` may not exist or may be outside the exec context, so this is not a reliable or valid log-retrieval method for terminated containers.

kubectl attach <pod-name>

Why it fails: `kubectl attach` connects to a running container's stdin/stdout/stderr streams and is designed for interactive debugging or live output, not for retrieving historical logs. It will block waiting for a running process and cannot access logs from a previous or terminated container instance. To view past logs, you must use `kubectl logs --previous`.

kubectl describe pod <pod-name>

Why it fails: `kubectl describe pod` provides a rich summary of the Pod's lifecycle, including container restart counts, last termination state, exit code, reason, and recent events. While it does not print the full log text, this metadata is often the only log-like information available after a container has been deleted, making it a valid way to view log-related diagnostic details.

kubectl top pod <pod-name>

Why it fails: `kubectl top pod` queries the metrics pipeline (metrics-server) to display real-time CPU and memory usage of Pods, not application log output. It has no access to the container runtime's log files or the kubelet's log store, so it is strictly a performance monitoring tool and irrelevant to viewing logs.

The pod is using a sidecar log shipper

Why it fails: A sidecar log shipper is a separate container that forwards logs from a shared volume or from the main container's stdout, but it does not control the main container's exit code. CrashLoopBackOff is entered when the main container repeatedly starts and exits with a non-zero status; the presence of a shipper cannot cause that failure. Log shipping may continue even if the primary container is unstable, so it is unrelated to the crash loop.

The kubelet log level is too low

Why it fails: The kubelet log level, set with --v or --vmodule, controls the verbosity of kubelet's own diagnostic output, not the behavior of the container runtime or the application inside the pod. A low log level merely suppresses extra kubelet messages; it does not affect how the container runs or whether it exits cleanly. CrashLoopBackOff depends on the container's restart count, which is unaffected by kubelet logging verbosity.

The log file was rotated and deleted

Why it fails: Log file rotation and deletion affect files written directly to disk by the application, but container logs are typically captured by the container runtime from stdout/stderr; if the container crashes immediately, there may be no rotated file involved. Even if an application log is rotated, that does not cause the process to terminate or restart. CrashLoopBackOff is triggered solely by the container process exiting abnormally, not by any external log management action.

The pod's resource requests

Why it fails: Resource requests can make a pod unschedulable if no node has enough allocatable CPU/memory, but that condition appears as 'Insufficient cpu' or 'Insufficient memory' warning events in kubectl describe output. The question's described output specifically shows taint-related event messages, so resource requests are not the root cause here.

The pod's image pull policy

Why it fails: Image pull policy controls when kubelet pulls an image, which happens only after the pod has been scheduled and bound to a node. A pod stuck in Pending is still waiting for a node assignment; the scheduler never reaches the container creation phase, so pull policy cannot affect pending state.

The pod's liveness probe configuration

Why it fails: Liveness probes are executed by the kubelet against an already running container to decide if it must be restarted. Since a Pending pod has not yet been scheduled and no containers have started, probe configuration is irrelevant at this stage.

kubectl get events --watch

Why it fails: The --watch flag streams new event objects in real time, but it does not produce a static, time-sorted list of existing cluster events. It continuously monitors for changes, showing a live feed of events as they occur, which is not the same as querying all events and ordering them by their creation timestamp. To see a sorted historical view, you must omit --watch and instead use --sort-by with a JSONPath expression.

kubectl logs --events

Why it fails: kubectl logs --events is not a valid command because kubectl logs does not support an --events flag. The logs command is designed to fetch container logs (stdout/stderr) from a pod, not to display cluster events. Attempting to run this command will result in a syntax error or an unknown flag error, so it cannot show any events, sorted or otherwise.

kubectl describe events

Why it fails: kubectl describe events provides a human-readable summary of events, but its default output is not guaranteed to be strictly sorted by creationTimestamp. The describe command formats a compact representation that often groups or aggregates information and may display events in an unordered or ID-based manner. While timestamps appear in the output, this command does not provide the explicit, structured chronological ordering that the --sort-by flag ensures.

systemctl status kube-scheduler

Why it fails: systemctl status kube-scheduler is incorrect because in modern Kubernetes (especially kubeadm-deployed clusters) the kube-scheduler is typically a static pod managed by the kubelet, not a systemd service. Even if a systemd unit exists, checking it bypasses the Kubernetes API and may show a running unit while the scheduler's actual control loop is unhealthy. Additionally, on managed Kubernetes platforms (EKS, GKE) you have no access to systemctl, making this approach invalid.

kubectl get pods -n kube-system | grep scheduler

Why it fails: kubectl get pods -n kube-system | grep scheduler is incorrect because it merely verifies that a scheduler pod exists and reports its pod phase (Running, Pending, etc.). The pod could be Running while the scheduler's internal controller loop is crashing or stuck, and componentstatuses is the command intended to report the component's health from the API server's perspective. It also requires the scheduler to run as a pod, which is not universally true across all control-plane setups.

kubectl describe node

Why it fails: kubectl describe node is incorrect because it focuses on node-level information: taints, labels, capacity, allocatable resources, conditions, and events about the node. While it can show if scheduling is disabled on that node, it provides no direct insight into whether the kube-scheduler process or its control loop is functioning. The scheduler is a control-plane component, not a node agent, so describing nodes cannot reveal its health or liveness.

kubectl logs pod --all-containers

Why it fails: The `--all-containers` flag is designed to aggregate logs from all active containers running concurrently within a multi-container pod. It does not target the historical logs of a previously crashed or restarted container instance, which is required to diagnose past failures.

kubectl describe pod

Why it fails: While `kubectl describe pod` is highly useful for troubleshooting, it only displays high-level metadata, controller details, current status, and recent lifecycle events of the pod. It does not stream or retrieve stdout/stderr container logs, making it insufficient for inspecting application-level output from a terminated container.