Service Mesh Interview Questions India 2026: Istio, Envoy, mTLS, and Traffic Management

Service mesh fundamentals:

1. What is a service mesh? A service mesh is an infrastructure layer for managing service-to-service (east-west) communication in a microservices architecture. It handles: service discovery and load balancing, encrypted communication between services (mTLS), traffic management (canary deployments, retries, timeouts, circuit breakers), and observability (metrics, logs, and traces for every service call) — without changes to the application code. The service mesh is implemented as a set of sidecar proxies that run alongside each service and intercept all network traffic.

2. Why is a service mesh needed? In a microservices architecture with 50+ services, each service needs to: discover the other services it calls (service discovery), handle failures gracefully (retries, timeouts, circuit breaking), encrypt traffic between services (mTLS for zero-trust security), and emit observability data (traces and metrics for each outbound call). Implementing all of this in every service is duplicated work and it couples every service to the operational infrastructure. A service mesh moves these concerns out of the application code and into the infrastructure layer.

3. Service mesh vs API gateway: API gateway (north-south): handles traffic from external clients into the cluster; authentication, rate limiting, routing. Service mesh (east-west): handles traffic between services within the cluster; mTLS, observability, traffic management for internal calls. They are complementary: the API gateway is the external front door; the service mesh governs all internal communication. At large Indian companies, both exist: Kong or AWS API Gateway at the edge; Istio inside the cluster.

4. Popular service meshes: Istio: the most widely adopted service mesh; uses Envoy as the data plane proxy; managed by CNCF. Linkerd: lightweight, simpler than Istio; uses its own purpose-built proxy (not Envoy). Consul Connect (HashiCorp): integrates with Consul service discovery; good for hybrid environments (VMs + Kubernetes). AWS App Mesh: AWS-managed service mesh; integrates with ECS and EKS natively.

Istio architecture:

1. Data plane: The data plane consists of Envoy sidecar proxies, one per pod (container in Kubernetes). Every inbound and outbound request to and from a service passes through its Envoy sidecar. The Envoy proxy: enforces mTLS (encrypts and authenticates traffic), applies traffic policies (retries, circuit breaking, load balancing), collects telemetry (metrics, traces for every request). The application code sees Envoy as localhost: it sends requests to localhost:port; Envoy intercepts the traffic (via iptables rules set up by an init container), applies policies, and forwards to the destination's Envoy sidecar.

2. Control plane (Istiod): Istiod is the control plane; it is a single binary that combines the previously separate Pilot, Citadel, and Galley components. Istiod responsibilities: service discovery (watches the Kubernetes API server for pods, services, and endpoints; converts them to Envoy xDS configuration), configuration management (converts Istio custom resources like VirtualService, DestinationRule into Envoy configuration and pushes to all proxies via xDS APIs), certificate management (acts as a Certificate Authority; issues and rotates mTLS certificates for all service identities; enables zero-trust networking).

3. Key Istio custom resources: VirtualService: defines traffic routing rules for a service (route 90% to v1 and 10% to v2 of a service — canary deployment; match on HTTP headers to route beta users to a new version). DestinationRule: defines policies for traffic after routing (load balancing strategy, circuit breaker thresholds, outlier detection, mTLS mode). Gateway: configures an Envoy proxy at the edge of the mesh to handle ingress or egress traffic. ServiceEntry: adds external services (outside the mesh) to the service registry so that Istio can manage traffic to them.

4. Traffic management patterns: Canary deployment: route a small percentage of traffic to a new version; gradually increase; roll back if error rate rises. Blue-green deployment: route all traffic to a new version at once; roll back by switching back. A/B testing: route traffic based on HTTP headers or cookies to different versions. Fault injection: inject artificial delays or errors into requests to test resilience (useful in chaos engineering).

Service mesh security:

1. What is mutual TLS (mTLS)? TLS (Transport Layer Security): the server presents a certificate to prove its identity; the client verifies it; communication is encrypted. mTLS (Mutual TLS): both the client and the server present certificates and verify each other. In a service mesh, mTLS ensures: authentication (only services with a valid certificate issued by the mesh's CA can communicate; no spoofed services), encryption (all service-to-service traffic is encrypted in transit, even within the cluster), and authorization (RBAC policies can restrict which services can call which other services).

2. Istio and zero-trust networking: The traditional network security model: trust everything inside the network perimeter. Zero-trust: never trust; always verify. With Istio mTLS: every service has a cryptographic identity (SPIFFE ID); no service can call another without a certificate issued by Istiod; authorization policies define which services can call which endpoints; even if a bad actor gains access to the internal network, they cannot communicate with services without a valid certificate. Istiod automatically issues and rotates certificates for all service identities (no manual certificate management).

3. Istio PeerAuthentication and AuthorizationPolicy: PeerAuthentication: defines how a service accepts mTLS connections. Mode STRICT: only mTLS connections accepted (plaintext rejected). Mode PERMISSIVE: accept both mTLS and plaintext (useful during migration when not all services have sidecars). AuthorizationPolicy: fine-grained access control (service A can only call the /payments endpoint of service B; deny all other calls to service B). Applied at the namespace or workload level.

4. Ingress and egress control: Istio Ingress Gateway: the entry point for traffic from outside the cluster to the mesh. Manages TLS termination, authentication, and routing to internal services. Istio Egress Gateway: controls traffic leaving the cluster (to external services). Centrally log, restrict, and inspect all egress traffic; prevent services from making unauthorized external calls.

Service mesh observability and operations:

1. Observability in Istio: Without code changes, Istio's Envoy sidecars automatically generate: metrics (request rate, error rate, p50/p95/p99 latency for every service pair — exported to Prometheus), distributed traces (every request gets a trace ID injected in headers; Envoy adds spans; traces exported to Jaeger or Tempo), and access logs (every request logged with full context: source service, destination service, status, latency, trace ID). This means that a new service added to the mesh immediately has full observability without instrumentation. The Kiali dashboard visualises the service mesh (service graph, traffic rates, error rates, circuit breaker status).

2. Service mesh performance overhead: The Envoy sidecar adds latency to every request (additional network hop to localhost). Typical overhead: 0.5-2ms per request (very low; acceptable for most applications). Memory overhead: each Envoy proxy uses 50-100MB of memory (significant at scale: 1000 pods = 50-100GB of extra memory just for proxies). CPU: 5-10% additional CPU per pod under load. For latency-sensitive, very high-throughput workloads, profile the overhead before adopting a service mesh.

3. Service mesh troubleshooting: Common issues: mTLS failures (certificate not yet propagated to a new pod; service in STRICT mode but the caller has no sidecar), configuration not taking effect (verify with istioctl proxy-config; check the Envoy xDS state directly), connection refused between services (check if the destination service's sidecar is running; check AuthorizationPolicy), high latency (Envoy sidecar under load; check resource limits; check if circuit breaker is firing).

Useful commands: `istioctl proxy-config routes <pod> --name=80` (view routing rules applied to a pod), `istioctl analyze` (check for common configuration errors), `istioctl proxy-status` (check if all proxies are in sync with Istiod).

4. When NOT to use a service mesh: Small microservices architectures (fewer than 10 services): the operational complexity of Istio outweighs the benefits. Teams without Kubernetes expertise: the service mesh significantly increases the operational surface area. Simple monolith or majestic monolith: no east-west service communication to manage. Alternative: use a service mesh library (Netflix's Ribbon, Spring Cloud circuit breaker) in the application code; simpler but requires per-service implementation.