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: ingress-nginx, Traefik, HAProxy, or a cloud-native one like the AWS Load Balancer Controller. The controller watches the API server for Ingress objects, and reconfigures the proxy it manages to match. So the flow is: your traffic arrives at the controller's own Service, which is usually the one LoadBalancer in the cluster, the controller's proxy reads the request, matches it against the rules from every Ingress object, and forwards to the right backend Service.
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.
What interviewers probe next
"Where does TLS terminate?" At the controller, normally, using a certificate from a Secret named in the Ingress. Traffic from there to the pods is plaintext inside the cluster unless a mesh is doing mTLS, and that is an assumption worth stating rather than leaving implied.
"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.