A school district creates Gateways but must choose which implementation will reconcile them. Which resource selects the controller that implements a Gateway?
Select an answer to reveal the explanation.
Short Explanation
GatewayClass is the district’s “which brand of door controller?” label. Gateways point at a GatewayClass, and that class tells the cluster which Gateway controller should actually drive the listeners.
Full Explanation
GatewayClass is the school district’s selector for which Gateway controller implementation will reconcile Gateway objects. A Gateway references a GatewayClass; that class names (via controllerName or equivalent) the implementation responsible for programming listeners and the data plane. Without a matching installed controller and a valid class, Gateway manifests remain inert paperwork. Choosing the class is therefore the first binding decision when multiple or vendor-specific Gateway implementations exist.
NetworkPolicy selects allowed pod-to-pod or namespace traffic for the CNI dataplane—it does not choose who implements Gateways or public hostnames. PriorityClass influences Pod scheduling priority relative to other Pods; it does not rank Gateways for API admission as a controller selector. StorageClass governs volume provisioning and parameters; it does not mount TLS certificates into a Gateway controller or bind Gateways to implementations.
Exam caveat: GatewayClass is typically cluster-scoped and often managed by platform admins; application teams reference an allowed class indirectly by attaching to Gateways that already point at it. Installing CRDs without deploying the controller named by the class still yields no edge traffic.
Operational check: list GatewayClasses, confirm the intended controller Deployment or operator is running, create a Gateway that sets gatewayClassName correctly, and watch Gateway status until addresses/listeners report programmed before attaching district HTTPRoutes.