TL;DR: A Service balances connections to pods and knows nothing about HTTP. An Ingress is a set of HTTP routing rules (host, path, TLS certificate) that a separate ingress controller reads and turns into real proxy configuration. The object is just data; without a controller running, nothing happens.
How to approach it
The two-part structure is the answer: the Ingress resource is declarative configuration, and the controller is the thing that implements it. Most candidates describe the rules and never mention that a controller has to exist, which is exactly what goes wrong the first time someone applies an Ingress to a fresh cluster and nothing responds.
A strong answer
A Service works at layer 4. It takes a connection to a virtual IP and sends it to a pod. It cannot see that the request was GET /api/orders with Host: shop.example.com, so it cannot route on any of that, and it cannot terminate TLS.
An Ingress is where those HTTP decisions live. One object typically says: requests for shop.example.com with a path starting /api go to the orders Service on port 80, everything else goes to frontend, and here is the TLS secret to serve the certificate from. That is the whole resource. It is a routing table expressed as Kubernetes data.
Then the part people leave out. An Ingress object on its own does nothing at all. An ingress controller has to be running in the cluster: a maintained implementation such as Traefik, HAProxy or a cloud-native controller. Community ingress-nginx retired in March 2026 and should not be selected for a new installation. Retirement notice. The controller watches the API server for Ingress objects, and reconfigures the proxy it manages to match. An in-cluster proxy may receive traffic through its own LoadBalancer Service. A cloud-native controller may instead configure a managed external proxy. In either case, distinguish the controller that reconciles configuration from the data plane that serves requests.
That structure is why a single load balancer can serve a hundred applications. The cloud load balancer points at the controller; the controller does the fan-out using rules that live in Kubernetes.
What the controller gives you beyond routing is worth naming: TLS termination with certificates from Secrets (usually issued automatically by cert-manager), path rewriting, request and connection limits, and sometimes authentication. The details are controller-specific, which is the recurring annoyance: most of the useful behaviour is configured through annotations that differ between controllers, so an Ingress is portable in principle and rarely in practice.
That portability gap is what the Gateway API exists to close. It splits the single Ingress object into several with clearer ownership: the platform team owns the Gateway (the listener, the addresses, the certificates) and application teams own HTTPRoutes attached to it, with routing behaviour specified properly instead of through annotations. For a new cluster it is worth starting there.
Diagnose a wrong backend using the hostname
A request sent to the load balancer's IP without the intended hostname can reach a default backend even when the application route is correct. For a hypothetical HTTPS route, this read-only probe preserves both TLS server name and HTTP host while selecting a specific address:
curl --resolve shop.example.com:443:192.0.2.10 https://shop.example.com/api/orders
The address is a documentation example; use the authorized test endpoint. Verify the certificate without disabling validation. Compare the request with the route's host and path rules, then correlate proxy logs with backend logs. If the wrong application answers, investigate route selection. If the intended backend is selected but unavailable, inspect its Service endpoints and target port.
TLS termination and backend encryption are separate choices. A proxy can establish a second TLS connection to the backend without a service mesh. Document whether it validates the backend certificate and which identity it expects; an encrypted connection without the intended peer validation is incomplete evidence.
What interviewers probe next
"Where does TLS terminate?" At the controller, normally, using a certificate from a Secret named in the Ingress. Backend traffic may be plaintext or a separate TLS connection, depending on controller configuration. A mesh is one possible way to provide mutual TLS, not a requirement for all backend encryption.
"Can you use an Ingress for a database?" No. It is HTTP and HTTPS only. Non-HTTP traffic needs a LoadBalancer Service, or a controller-specific TCP passthrough configuration, which is outside the Ingress spec.
"What happens when two Ingress objects claim the same host and path?" Controller-dependent and usually resolved by oldest-wins or by rejecting the newer one. It is a real source of confusion on shared clusters and an argument for the Gateway API's explicit ownership model.
Common mistakes
Applying an Ingress to a cluster with no controller installed and concluding that Ingress is broken.
Describing an Ingress as "a load balancer", which loses the distinction that matters: it routes on HTTP, and something else is providing the address.
Forgetting that the backend is a Service, not a pod, so a broken selector or a failing readiness probe looks like an Ingress problem and is not.
Assuming annotations carry over between controllers when swapping one out.