A county wants infrastructure operators to own the shared public entrypoint while application teams only attach their own HTTP routes. How should Gateway API ownership typically be split?
Select an answer to reveal the explanation.
Short Explanation
Picture the Gateway as the county’s shared lobby door that facilities owns, while each department posts its own directory signs (Routes) on that door. Ops keeps the entrypoint safe and stable; app teams attach only their HTTPRoute pieces.
Full Explanation
Gateway API’s ownership split matches how a county facilities team runs a shared lobby while departments hang their own directory signs. Cluster or platform operators typically own GatewayClass and Gateway objects—listeners, addresses, TLS posture, and which teams may attach—because those resources define the shared public entrypoint and its blast radius. Application teams own Routes (for example HTTPRoutes) that reference an allowed Gateway listener and point at their Services. That separation keeps edge security and capacity under infrastructure control without forcing every microservice to run an exclusive edge stack.
Requiring each application team to create its own GatewayClass and exclusive Gateway per microservice collapses the shared-entrypoint model into many doors, multiplying certificates, IPs, and operational load. Restricting HTTPRoute creation to the CNI plugin owner while making app teams edit Endpoints manually mixes unrelated networking layers: CNI owns pod networking, Endpoints are selected from Pods by Services, and Routes are the application-facing attachment—not a manual endpoint craft project. Treating Routes as Service replacements so operators delete ClusterIP objects after the first Gateway appears is false: Routes commonly target Services; deleting ClusterIPs breaks stable backends and in-cluster discovery.
Exam caveat: exact RBAC may vary by platform (ReferenceGrant, allowedRoutes, namespace policies), but the conceptual split—ops owns Gateway, apps own Routes—is what CKA-style questions expect. GatewayClass still selects the controller; app teams usually do not invent classes casually.
Operational check: verify Gateway status and listener readiness under the operators’ namespace or cluster scope, apply an HTTPRoute from an app namespace that attaches only to the permitted Gateway, confirm Accepted conditions, and ensure the backend Service still has ready endpoints.