The kube-scheduler selects a node in two main phases: filtering and scoring, so C is correct. First, filtering identifies which nodes are feasible for the Pod by applying hard constraints. These include resource availability (CPU/memory requests), node taints/tolerations, node selectors and required affinities, topology constraints, and other scheduling requirements. Nodes that cannot satisfy the Pod's requirements are removed from consideration.
Second, scoring ranks the remaining feasible nodes using priority functions to choose the "best" placement.
Scoring can consider factors like spreading Pods across nodes/zones, packing efficiency, affinity preferences, and other policies configured in the scheduler. The node with the highest score is selected (with tie-breaking), and the scheduler binds the Pod by setting spec.nodeName.
Option B ("filtering and selecting") is close but misses the explicit scoring step that is central to scheduler design. The scheduler does "select" a node, but the canonical two-step wording in Kubernetes scheduling is filtering then scoring. Options A and D are not how scheduler internals are described.
Operationally, understanding filtering vs scoring helps troubleshoot scheduling failures. If a Pod can't be scheduled, it failed in filtering-kubectl describe pod often shows "0/... nodes are available" reasons (insufficient CPU, taints, affinity mismatch). If it schedules but lands in unexpected places, it's often about scoring preferences (affinity weights, topology spread preferences, default scheduler profiles).
So the verified correct answer is C: kube-scheduler uses Filtering and Scoring.
=========