Kubernetes Interview Questions & Answers

The scheduler filters out any node that can't satisfy a pod's requested resources. This event means every node's already-allocated CPU requests leave too little room for what this pod is asking for - the fix is usually more/bigger nodes or a smaller request.

No single command tells the whole story of a crash: --previous shows you what the container printed right before it died, describe pod shows recent events and how many times it's restarted, and get events shows broader scheduling/health signals from the cluster. Using all three together gives you the fullest picture of what actually went wrong.

Normally, debugging a running Pod means adding tools to its image and restarting it, which changes exactly the thing you're trying to investigate. Ephemeral containers let you attach a temporary debugging container to an ALREADY-running Pod on the fly (usually via kubectl debug), without restarting or recreating anything.

A liveness probe periodically checks whether a container is actually healthy, and if the checks keep failing, the kubelet restarts that container. A readiness probe only controls whether the pod receives traffic, it wouldn't cause the hung container to restart.

NetworkPolicy is just an API object - Kubernetes itself doesn't enforce it. Enforcement is entirely the CNI plugin's job, so on a plugin that doesn't support it, the policies exist in etcd but do nothing, with no warning or error.

Environment variables are injected once when the container starts and stay frozen for that container's life, so a Secret change has no effect until the pod restarts, while the kubelet periodically syncs mounted Secret volumes so file contents on disk update without needing a restart. Neither DNS caching nor etcd permanence has anything to do with this behavior.

OOMKilled specifically means the Linux out-of-memory killer terminated the process because it exceeded the memory limit set for the container. Running out of CPU causes throttling rather than a kill, and disk space or probe failures would show up as a different status entirely.

kubectl rollout undo reverts a Deployment to its previous revision using the rollout history Kubernetes automatically keeps, making it the fast, safe way to recover from a bad release. Deleting the Deployment or scaling it to zero would take the app down entirely instead of restoring the working version.

Normally, if your app wants to know its own Pod name or namespace, it would have to ask the Kubernetes API directly. The Downward API skips that entirely by exposing a Pod's own metadata (name, namespace, labels) straight into its environment variables or files, no API call needed.

A PersistentVolume represents the actual underlying storage, and a PersistentVolumeClaim is how a pod requests and binds to that storage, so the data outlives any single pod that happens to use it. ConfigMaps and Secrets only hold configuration data, not durable application storage.