A pod is stuck in Pending state after deployment. Which component would you check first?

Correct answer: kube-scheduler logs

Option D is correct because the kube-scheduler is responsible for assigning pods to nodes; if a pod remains Pending, it almost always means the scheduler could not find a suitable node, and checking its logs reveals reasons such as insufficient resources, taint/toleration mismatches, or affinity failures. Option A (container registry credentials) would cause an ImagePullBackOff or ErrImagePull error, not a Pending state, because the pod would already have been scheduled. Option B (kubelet) is relevant only after the pod has been scheduled to a node; a Pending pod has not yet been assigned to any node, so the kubelet has not yet acted on it. Option C (etcd) stores cluster state and is rarely the first place to look for scheduling issues; etcd problems would manifest as API server or cluster-wide failures rather than a single pod being Pending.