Interview › Istio & Service Mesh
How do you decide whether a service should be in the mesh or not?
Istio & Service Mesh · Advanced level
Answer
I decide based on value versus risk and cost. A service belongs in the mesh when it benefits from mTLS identity, authorization, traffic control, observability, or progressive delivery. I avoid onboarding services where proxying creates unsupported behavior, unnecessary overhead, or no meaningful platform benefit.
Technical explanation
Good candidates are internal HTTP/gRPC services with multiple callers and clear security or release-control needs.
Riskier candidates include latency-critical ultra-low-latency paths, unusual protocols, hostNetwork workloads, and some stateful systems without testing.
The decision should be explicit, documented, and revisited as mesh modes and service needs evolve.
Hands-on example
Scoring model:
Security need: 0-5
Traffic-control need: 0-5
Observability gap: 0-5
Protocol compatibility risk: 0-5
Operational owner readiness: 0-5
Onboard high-value, low-risk services first; keep exceptions with compensating controls.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- How does automatic sidecar injection work (namespace label, webhook)?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?