What is the difference between a Service and an Ingress?

WHAT THIS TESTS: Whether you understand the separation between Layer 4 cluster-internal networking and Layer 7 external HTTP routing in Kubernetes. Interviewers want to see that you know Services handle transport-level load balancing while Ingresses handle application-level routing, and that these primitives work together rather than replacing each other.

A GOOD ANSWER COVERS four things in order. First, define a Service as a Layer 4 abstraction that exposes a set of Pods via a stable virtual IP and performs TCP or UDP load balancing inside the cluster. Second, define an Ingress as a Layer 7 abstraction that exposes HTTP and HTTPS routes from outside the cluster to Services inside the cluster, and explicitly note that an Ingress requires an Ingress Controller to actually process those rules. Third, clarify the dependency chain: external traffic hits the Ingress, which routes based on host or path to a Service, which then load-balances across healthy Pods. Fourth, provide a concrete scenario where both are necessary, such as a microservices application with a React frontend and a REST API backend, each backed by its own Deployment and ClusterIP Service, with an Ingress routing example.com to the frontend Service and example.com/api to the backend Service while terminating TLS.

COMMON WRONG ANSWERS include claiming an Ingress replaces a Service, stating that an Ingress sends traffic directly to Pods, asserting that a Service understands HTTP paths or host headers, or forgetting that an Ingress is inert without an Ingress Controller installed in the cluster. Another red flag is describing a scenario that only uses a single Service when the question explicitly asks for both.

LIKELY FOLLOW-UPS are how an Ingress Controller differs from an Ingress resource, which Service type pairs best with an Ingress and why NodePort is often unnecessary when an Ingress is present, how TLS termination and certificate management work, and when the Gateway API should be preferred over Ingress.

ONE CONCRETE EXAMPLE is an e-commerce platform running in a managed Kubernetes cluster. The catalog UI and order API each have a Deployment and a ClusterIP Service. An NGINX Ingress Controller sits behind a cloud load balancer. An Ingress resource defines two rules: host shopping.example.com with path / routes to the catalog Service on port 80, and path /api/orders routes to the order Service on port 8080. The Ingress Controller handles TLS termination using a certificate from cert-manager. The Services ensure that scaling either Deployment up or down does not break the routing because the Ingress always points to the stable Service virtual IP rather than individual Pod IPs.