TL;DR: Kubernetes gives you service discovery and load balancing at layer 4 and stops there. A mesh adds commonly managed capabilities above the core Service abstraction: identity-based mTLS between workloads, per-request traffic control, and uniform telemetry without touching application code. It is worth it when you need those across many teams, and may be unnecessary when a small team can meet those requirements through existing libraries and certificate automation.
How to approach it
Name what Kubernetes already does before naming what the mesh adds, because the gap is the answer. Then make the adoption call yourself. An interviewer asking this at senior level is usually testing whether you buy infrastructure by fashion or by problem.
A strong answer
Kubernetes already does service discovery through DNS and Services, and it load balances across endpoints. What it does not do is care about anything above the connection. kube-proxy picks an endpoint per connection, not per request, so a long-lived HTTP/2 or gRPC connection pins to one pod and your traffic distribution quietly becomes wrong. Kubernetes provides service-account identity, but does not automatically turn it into mutual TLS for application connections. NetworkPolicy selects pods and namespaces through labels and also supports IP blocks; it does not authenticate application peers using certificates. And there is no consistent telemetry unless every team instruments their service the same way, which they will not.
A mesh addresses exactly those three. Identity comes from a per-workload certificate rather than an IP, which is what makes mTLS meaningful: the policy says "the checkout service may call the payments service", not "10.4.2.0/24 may reach 10.4.9.0/24". Traffic management moves to layer 7, so you get per-request routing, retries with budgets, timeouts, circuit breaking, and the traffic splitting that real canary analysis needs. Telemetry becomes uniform because the proxy emits the same golden signals for every service regardless of language.
Now the part that scores. The cost is a proxy in the request path of every call, which adds implementation- and workload-dependent latency and memory overhead, plus a control plane you now operate and upgrade. More importantly it adds a failure mode: when the mesh misbehaves the symptom is that everything is slightly broken, and debugging that requires understanding both your service and Envoy.
So my rule: for a small service estate with consistent client libraries, a shared client library gets you retries and timeouts for a fraction of the operational cost. Adopt a mesh when you have enough teams that you cannot make them all adopt a library, when you need mTLS for a compliance requirement you can name, or when progressive delivery on real traffic percentages has become a business need. Ambient mode changes the arithmetic by removing the per-pod sidecar for layer 4 work, and it is a reasonable answer to "the cost is too high" in 2026.
What interviewers probe next
"Why does gRPC load balance badly without one?" Because kube-proxy balances connections and gRPC multiplexes many requests over one long-lived connection. The mesh balances per request, which is the actual fix.
"Could you get mTLS without a mesh?" Yes, with SPIFFE identities and application-level TLS. Cilium mutual authentication authenticates identities but does not itself encrypt application traffic; transparent WireGuard/IPsec encryption is a separate feature and is not identical to application mTLS. Cilium mutual authentication.
"What breaks first at scale?" The control plane's config distribution. Every proxy holds config for everything it might talk to, so memory grows with cluster size unless you scope it deliberately.
Common mistakes
Listing features (retries, timeouts, mTLS, observability) with no account of what Kubernetes already provides. The interviewer knows the feature list; they want the gap.
Recommending adoption unconditionally. A candidate who has actually operated one always mentions the upgrade path, because mesh upgrades are the part that hurts.
Claiming a mesh gives you zero trust. It gives you the transport half. Authorization policy and workload identity governance are separate work.