Interview › Istio & Service Mesh
How do you prevent a team from misconfiguring routing for a shared gateway?
Istio & Service Mesh · Advanced level
Answer
To prevent shared-gateway misconfiguration, I use ownership boundaries, Gateway API attachment rules where possible, host allowlists, admission policies, CI validation, and GitOps review. App teams should not directly edit the shared gateway listener configuration unless they own that gateway.
Technical explanation
Shared gateways are high-blast-radius resources because a bad host, TLS, or route configuration can affect many services.
The platform team should own listeners, certificates, and allowed route namespaces.
App teams can own route objects constrained to approved hostnames and namespaces.
Hands-on example
Control example:
1. Platform owns Gateway public-gw.
2. allowedRoutes permits only selected namespaces.
3. Admission policy verifies host suffix matches team domain.
4. CI runs istioctl analyze and host-conflict checks.
5. GitOps applies after approval from platform and service owner.
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?