Skip to content

Quiz: Envoy Proxy

← Back to quiz index

6 questions

L1 (3 questions)

1. What is Envoy proxy and why is it used as the data plane in most service meshes?

Show answer Envoy is a high-performance L7 proxy designed for microservices. It is the data plane in Istio, Consul Connect, and AWS App Mesh because:
1. It supports HTTP/2 and gRPC natively.
2. Dynamic configuration via xDS APIs (no restarts needed).
3. Built-in observability (detailed stats, distributed tracing, access logs).
4. Advanced load balancing (zone-aware, circuit breaking, outlier detection).
5. Extensible via WASM filters. It runs as a sidecar alongside each service, handling all network traffic transparently.

2. How does Envoy handle circuit breaking and outlier detection?

Show answer Circuit breaking: limits concurrent connections, pending requests, and retries to a cluster. When limits are hit, Envoy returns 503 immediately instead of overloading the backend. Configured per cluster (max_connections, max_pending_requests, max_retries). Outlier detection: Envoy tracks error rates per endpoint and ejects unhealthy ones from the load balancing pool (e.g., 5 consecutive 5xx errors triggers ejection for 30 seconds). They work together: outlier detection removes bad endpoints, circuit breaking prevents overload on remaining ones.

3. What is the difference between Envoy listeners, routes, clusters, and endpoints?

Show answer Listener: the address:port Envoy binds to receive traffic (e.g., 0.0.0.0:8080). Each listener has filter chains. Route: matches incoming requests (by host, path, headers) and sends them to a cluster. Cluster: a named group of upstream endpoints with load balancing and health check config. Endpoint: an individual backend instance (IP:port). Flow: client -> listener -> route match -> cluster selection -> load balance to endpoint. Think of it as: listeners receive, routes decide, clusters organize, endpoints serve.

L2 (3 questions)

1. What are the xDS APIs and how does Envoy receive its configuration dynamically?

Show answer xDS is a family of discovery service APIs: CDS (Cluster Discovery), EDS (Endpoint Discovery), LDS (Listener Discovery), RDS (Route Discovery), SDS (Secret Discovery). The control plane (Istio Pilot, Consul, custom) pushes configuration to Envoy via gRPC streams. Envoy subscribes at startup and receives updates in real-time — no restart or reload needed. This enables dynamic service discovery, traffic shifting, and policy changes. ADS (Aggregated Discovery Service) multiplexes all xDS types over a single stream for consistency.

2. How do you debug Envoy when requests are failing with 503 or NR (no route) errors?

Show answer 1. Check Envoy admin interface (/config_dump for current config, /clusters for endpoint health, /stats for metrics).
2. For 503 with UF flag: upstream connection failure — check if backend is reachable.
3. For 503 with UO flag: upstream overflow — circuit breaker triggered, increase limits or fix the backend.
4. For NR: no route matched — check /config_dump routes section, verify domain and path match.
5. Enable access logging with %RESPONSE_FLAGS% to identify the cause.
6. Use /logging?level=debug temporarily for detailed connection logs.

3. How does Envoy implement traffic shifting for canary deployments?

Show answer Configure a route with weighted clusters: route traffic to v1 cluster at 95% and v2 cluster at 5%. Gradually shift weight toward v2 as confidence builds. In Istio, this maps to VirtualService with weight-based routing. Envoy evaluates weights per-request, so it is statistically accurate over many requests. Combine with: header-based routing (route internal users to v2 regardless of weight), retry budget (limit retries to v2 to contain blast radius), and outlier detection (auto-eject v2 if error rate spikes). Monitor v2's error rate and latency before shifting more traffic.