Kubernetes Gateway API Interview Questions: Routes, Listeners, and Traffic Ownership

An application team creates an HTTPRoute for shop.example.com, but requests still hit the old service. “The YAML looks right” is not a useful Gateway API interview answer. The route may not be allowed to attach to the listener, the controller may not have programmed it, the request may not match, or its backend reference may be invalid.

These Kubernetes Gateway API interview questions walk through that diagnosis and the ownership model behind it. Practice explaining how microservices run and fail on Kubernetes, then add the distinct Gateway API control plane: infrastructure teams can own the shared Gateway while application teams own their Routes.

Evidence boundary: The Gateway API project documentation defines resource fields, attachment, ReferenceGrant, and status concepts. The namespace exercise and interview response are editorial examples. Controller implementation, installed version, and supported features can differ; this is not a prediction of a particular interview.

The short answer: traffic needs several agreements

GatewayClass identifies a controller implementation and configuration class. A Gateway requests traffic-handling infrastructure and defines listeners, including protocol, port, hostname, TLS, and which Routes may attach. An HTTPRoute declares parent references, hostnames, match rules, filters, and backend references. A Service is a common forwarding target.

The key interview move is to separate who requests attachment from who permits it. A Route can name a Gateway in parentRefs, but the listener's allowedRoutes policy must admit that Route's kind and namespace. Hostname and protocol compatibility also matter. When a Route refers to a backend in another namespace, that backend namespace generally needs a ReferenceGrant. These are two different cross-namespace permissions; fixing one does not imply the other.

Think in stages: a client reaches an address and listener; the Route attaches; an HTTP request matches a hostname and rule; references resolve; the controller programs a data plane; the Service has ready endpoints; the application responds. A 404, 503, or timeout may be observed at different stages. Do not infer the failing stage from one status code alone.

Who should own GatewayClass, Gateway, and HTTPRoute?

The Gateway API is designed to express role separation. A cluster or platform owner typically selects a GatewayClass, deploys or configures the controller, and sets shared infrastructure policy. An infrastructure owner may create the Gateway and its listeners. Application owners can manage HTTPRoutes in their own namespaces, if the listener allows them. The backend Service owner may be a third team.

That is an ownership model, not a rule that Kubernetes enforces without RBAC and admission policy. Namespace boundaries and Gateway API attachment rules complement permissions; they do not replace a cluster's authorization design. A candidate should name both the API-level relationship and who can mutate each resource. If every application team can change the shared Gateway listener, the claimed separation is mostly organizational.

For example, platform owns an HTTPS listener for shop.example.com in namespace infra. The shop team owns a Route in namespace app that points to a Service in app. The platform allows Routes only from namespaces labeled expose-apps=true. The shop team can deploy its Route without changing the shared listener, but a missing label blocks attachment. The correct repair is to inspect and approve that namespace policy, not to widen allowedRoutes to every namespace by reflex.

Object	Typical decision	Evidence to inspect
GatewayClass and controller	Which implementation reconciles Gateway API objects	Installed class, controller identity, supported features
Gateway listener	Protocol, port, hostname, TLS, and allowed Route namespaces	Listener conditions and attachedRoutes count
HTTPRoute	Parent, hostname, matches, filters, and backends	Per-parent status conditions and observed generation
Service and endpoints	Which application receives traffic	Service port, ready endpoints, app logs

Why would a Route fail to attach?

Start with the Route's parentRefs: name, namespace, and optionally sectionName. A Route in app can reference a Gateway in infra, but the Gateway's listener still decides which Route kinds and namespaces are admitted. Check allowedRoutes on the intended listener, not merely the Gateway's existence. Confirm the namespace labels if a selector controls attachment.

Then check listener compatibility. A Route for a hostname that does not intersect the listener's hostname cannot receive that traffic. A Route attached to an HTTP listener does not magically terminate HTTPS on a different port. A sectionName targeting the wrong listener can leave a seemingly correct Route out of scope. Compare the actual Host header and port in the test request to the listener and Route fields.

Read Route status per parent. An HTTPRoute can refer to more than one parent, and success against one parent does not prove another is accepted. Inspect conditions such as Accepted and ResolvedRefs, their reasons, message, and observed generation. On the Gateway, inspect its conditions and each listener's status; a desired spec and an actually programmed data plane are not identical.

Do not rely on attachedRoutes count by itself as proof that a particular request will reach the backend. It is useful context about listener attachment, but route matching, references, programming, and backend health remain separate. A count of zero should redirect the investigation toward parent/listener attachment before Service endpoints.

Diagnose two separate permission failures

Use three namespaces: app owns an HTTPRoute, infra owns a Gateway with an HTTPS listener, and data owns the target Service. First, app's Route sets parentRefs to the infra Gateway. The listener allows Routes only from infra and platform namespaces. The Route asks to attach, but the listener declines it. The route's backend does not matter yet because the Route has not entered the intended traffic path.

The infrastructure owner can approve app according to policy—perhaps by applying a trusted label and matching selector. After reconciliation, inspect the Route's per-parent Accepted status and the listener status. Next test the real hostname and port. Do not assume a green YAML validation means the proxy has updated.

Now change the scenario. The Route attaches, but its backendRefs point to a Service in data. Cross-namespace backend references require permission from the namespace that owns the target. A ReferenceGrant in data can permit an HTTPRoute from app to reference a Service in data. A grant created in app does not make data consent. It is a permission from the target owner.

The image is deliberately two gates. In the first failure, change listener allowedRoutes or namespace eligibility. In the second, retain the accepted attachment and repair the backend reference with an appropriately scoped ReferenceGrant. Then validate Service port, endpoints, and policy. If you collapse both into “cross-namespace routing is broken,” you can give the wrong team the wrong action.

Avoid a blanket grant to every Route namespace just to make one deployment pass. Record which source namespace and kind may reference which target kind, and use admission or organizational policy if the grant scope still exceeds what a team should authorize. The API's available fields do not eliminate the need for ownership review.

How do hostname and path rules choose a backend?

HTTPRoute hostnames constrain Host matching; rules can further match paths, methods, headers, or query parameters according to supported features. Filters can modify or redirect a request, and backendRefs determine forwarding destinations. A candidate should begin with one concrete request—scheme, host, port, path, and relevant headers—and predict the match before discussing traffic weights.

Suppose the listener serves shop.example.com and two Routes are attached: one matches /api and another matches /. A request to shop.example.com/api/orders should follow the most appropriate matching rule under the Gateway API conflict-resolution specification, not whichever manifest was applied last. If several Route rules or multiple Routes overlap, inspect the documented precedence and the implementation's supported features; do not invent an arbitrary “first YAML wins” rule.

Test negative cases as carefully as the happy path. A request using the Gateway's IP as the Host may not match a hostname-constrained Route. A path with an unexpected case or prefix boundary may select a different rule. A redirect filter may return a response without contacting the backend at all. Looking only at application logs cannot reveal a request that never reached the application.

For a weighted rollout, first establish that both backends resolve and have healthy endpoints. State the traffic objective and the observation window. A 90/10 configuration does not guarantee every ten consecutive requests contain exactly one canary request. Measure over an appropriate sample and monitor per-backend errors and latency, then roll back the Route change or weight if the canary fails.

A reliable debugging order for a failed rollout

Reproduce one request with a known Host header and path, and record the response, destination address, time, and correlation ID. Confirm DNS and the Gateway's published address. Then inspect Gateway and listener conditions to see whether the controller accepted and programmed the intended listener. Only then inspect the Route's parent status and attachment gate.

If attachment passes, inspect rule matching and filters. Follow any redirect or rewrite deliberately. If the Route resolves references, check backend Service name, namespace, port, endpoint readiness, and the application's actual response. If references do not resolve, determine whether the failure is a typo, missing object, unsupported feature, or absent ReferenceGrant. Treat NetworkPolicy and application-level authentication as separate later layers; Gateway API acceptance does not automatically allow pod-to-pod traffic.

For a fast rollback, know which object changed. Reverting the HTTPRoute is different from deleting a shared Gateway or weakening a cluster-wide policy. Capture the previous Route spec and status, watch observed generation catch up, and repeat the same request. If the controller has a feature mismatch or listener outage, Route rollback alone may not restore service. Explain the scope of the rollback rather than promising it will always work.

This order prevents the common interview failure of prescribing a Service restart before establishing that the request can match any Route. It also gives distinct owners actionable evidence: platform can inspect listener programming, application can inspect Route matching, and backend owners can inspect Service health.

How is this different from classic Ingress?

Ingress remains a familiar Kubernetes way to expose HTTP services, but Gateway API makes the roles and attachment relationships more explicit through GatewayClass, Gateway, and Route objects. That gives teams a vocabulary for shared infrastructure ownership and delegated application routing. It does not mean every controller exposes identical features or that an Ingress can be translated mechanically without testing.

When asked to compare them, do not recite a feature checklist from memory. Identify the requirement: multi-team ownership, cross-namespace references, listener-level policy, advanced matching, or migration risk. Check installed CRDs, controller conformance and feature support, TLS handling, and status behavior. A working Ingress serving one application may be simpler than introducing a new control plane just for terminology.

During migration, run representative requests against old and new paths. Compare host/path precedence, redirects, header behavior, backend health, and TLS certificate selection. Preserve a rollback path and avoid publishing two conflicting routes to the same traffic without a deliberate cutover. State what would demonstrate equivalence and what mismatch would stop rollout.

A concise interview answer

“I would start with the concrete request and separate five stages: listener availability, Route attachment, rule match, reference resolution, and backend health. The application Route can name an infrastructure Gateway, but the listener's allowedRoutes controls attachment. A cross-namespace backend reference is a different permission and generally needs a ReferenceGrant from the target namespace. I would read status per Route parent and per Gateway listener, check observed generation, then validate the actual Host/path and Service endpoints. I would roll back the smallest changed object and verify the same request.”

The most useful answer is not “Gateway API replaces Ingress.” It is a trace of who is authorized to connect which objects and how to prove the request took that path. Use Explain How Microservices Run and Fail on Kubernetes to practice the downstream half after you can explain the two Gateway API permission gates.

Sources and Further Reading

• Gateway API: API Overview
• Gateway API: Gateway reference
• Gateway API: HTTPRoute reference
• Gateway API: ReferenceGrant reference
• Gateway API: HTTP routing guide

Research checked September 21, 2026. Verify your controller version, conformance, and installed Gateway API resources before adopting a feature or diagnostic command.