5 exercises — Practice service mesh vocabulary in English: data plane, control plane, sidecar proxy, mTLS, traffic policies, Istio, Envoy, circuit breaking, and traffic shifting.
Core service mesh vocabulary clusters
Architecture: data plane (sidecar proxies), control plane (istiod/Pilot), sidecar injection, Envoy proxy
Observability: telemetry (metrics, logs, traces), Kiali, Jaeger integration, service graph
0 / 12 completed
1 / 12
A platform engineer explains service mesh architecture to a developer team adopting Istio: "A service mesh has two planes. The data plane is the sidecar proxies — Envoy containers injected into each pod. All traffic to and from your service goes through Envoy. Envoy handles retries, circuit breaking, mTLS, tracing. Your application knows nothing about any of this — it talks to localhost. The control plane — istiod in Istio — distributes configuration to all those Envoy proxies. You write a VirtualService CR in Kubernetes, istiod translates it to Envoy configuration, and pushes it to all proxies. Configuration change, no restarts needed." What is the relationship between the data plane and control plane in a service mesh?
Data plane: the Envoy sidecar proxies running alongside each application container. Every packet flows: [app] → [Envoy sidecar] → [network] → [Envoy sidecar] → [app]. Envoy performs L7 routing, load balancing, retries, timeouts, circuit breaking, mTLS termination, and telemetry — transparent to the app. Control plane (istiod): components: Pilot (service discovery, traffic config), Citadel (certificate authority for mTLS), Galley (config validation). In recent Istio versions, merged into istiod. Istiod uses xDS API (Envoy's discovery service API) to push configs to proxies. Sidecar injection: Kubernetes MutatingAdmissionWebhook automatically adds the Envoy container and an init container (to set up iptables rules intercepting traffic) to pods in labeled namespaces. Envoy proxy vocabulary: Listener: Envoy component that binds to a port and receives connections. Filter chain: the processing pipeline for each connection (HTTP connection manager, TLS inspector, etc.). Cluster: Envoy's representation of an upstream service. Endpoint: an individual backend (pod IP + port) within a cluster. Route: URL-to-cluster mapping rules. In conversation: 'The beauty of the sidecar model: you get observability, security, and traffic control for every service without changing a line of application code. The mesh handles it in the proxy.'
2 / 12
A security engineer explains zero-trust networking in a Kubernetes cluster: "By default in Kubernetes, any pod can talk to any other pod. That's a flat, implicitly trusted network. With Istio's mTLS, every connection between services is mutually authenticated and encrypted. The client proxy presents its certificate — its SPIFFE identity, derived from the Kubernetes service account. The server proxy validates it. Both sides verify each other. This happens in the data plane, transparent to the app. We also apply AuthorizationPolicy: 'only the payments service can call the orders service on path /api/orders'. Everything else is denied." What is mTLS and how does it differ from standard TLS?
TLS (one-way): client verifies server's certificate. Server proves its identity. Client identity is application-level (HTTP headers, JWT). The standard for HTTPS websites. mTLS (mutual TLS): both parties present certificates. Server verifies client identity cryptographically, not just application-level. SPIFFE (Secure Production Identity Framework For Everyone): standard for service identity. SPIFFE ID format: spiffe://trust-domain/ns/namespace/sa/service-account. Istio's Citadel acts as CA, issuing SVID (SPIFFE Verifiable Identity Document) certificates to each service account. Benefits: Cryptographic service identity: no password or token, the certificate IS the identity. Encryption in transit: all inter-service traffic encrypted. Zero-trust micro-segmentation: combined with AuthorizationPolicy, you can enforce "service A may call service B" at the proxy level. Istio PeerAuthentication: configures mTLS mode per namespace or workload. STRICT: only mTLS connections accepted. PERMISSIVE: both plaintext and mTLS accepted (migration mode). AuthorizationPolicy vocabulary: Principal: the identity of the caller (SPIFFE ID). Source: IP range, namespace, service account. Operation: HTTP method, path, host. Condition: request header values. In conversation: 'Once you enable STRICT mTLS across the cluster, you can write AuthorizationPolicies with confidence — you know exactly who is calling you, cryptographically.'
3 / 12
A senior engineer explains an Istio traffic shifting deployment strategy: "We want to roll out v2 of the product service without a full deployment switch. Using Istio VirtualService, we route 90% of traffic to v1 and 10% to v2. We monitor error rates and latency in Kiali. After an hour with no regressions, we shift to 50/50, then 100% v2. This is a canary release implemented entirely in the service mesh — no changes to Kubernetes Deployments, no additional load balancers. The DestinationRule defines v1 and v2 as subsets (label selector: version=v1 vs version=v2). The VirtualService controls the weight distribution." In Istio, what does a VirtualService do and how does it work with a DestinationRule?
VirtualService: defines how requests are routed. Attaches to a service's hostname. Rules can match: URI prefix, headers, source labels, method. Actions: weighted routing (canary), redirect, rewrite, retry policy, timeout, fault injection. DestinationRule: defines subsets (groups of pods by label) and applies policies per subset. Policies include: load balancing algorithm (round robin, least connections, consistent hash), circuit breaker (outlier detection), TLS settings. Together: VirtualService says "send 10% of traffic to subset v2"; DestinationRule says "v2 is pods with label version=v2, use consistent hash load balancing". Traffic management vocabulary: Traffic shifting: weight-based routing between versions. Header-based routing: route users with a specific header (e.g., X-Canary: true) to v2. Mirroring: copy traffic to a second version without serving the response — test v2 with real traffic, no user impact. Fault injection: deliberately inject delays or errors to test resilience. Retry policy: automatically retry on 5xx, configure attempts and retry-on conditions. Circuit breaker (outlier detection): eject unhealthy endpoints from the load balancing pool after too many 5xx errors. Istio Gateway vocabulary: Gateway: configures Envoy at the edge (ingress/egress), managing ports, protocol, TLS. Different from Kubernetes Ingress. In conversation: 'With VirtualService weights, a canary rollout is a one-line YAML change. No new Deployments, no load balancer reconfig. The mesh handles it.'
4 / 12
An SRE explains how they use Istio for resilience during an incident review: "The payment gateway was intermittently returning 503s — about 5% of requests. Without the mesh, those errors hit our checkout service directly, causing checkout failures. With Istio, we have a retry policy on the VirtualService: retry 503s up to 3 times with a 25ms delay. The circuit breaker in the DestinationRule kicks in if more than 10% of requests from a single proxy to payment fail in 1 second — it ejects that endpoint from the pool for 30 seconds. The checkout service saw near-zero errors during the payment degradation because the mesh absorbed the failures." In a service mesh, what does outlier detection (circuit breaking) do?
Outlier detection (Envoy circuit breaker): Istio's implementation of the circuit breaker pattern at the load balancing level. Configured in DestinationRule: consecutiveGatewayErrors: 5 — eject after 5 consecutive 503s. interval: 30s — evaluation window. baseEjectionTime: 30s — minimum ejection duration. maxEjectionPercent: 50 — never eject more than 50% of endpoints (prevents complete unavailability). How it differs from application circuit breaker (Resilience4j, Hystrix): Envoy outlier detection works per-endpoint within a cluster (individual pod IP), not per-service. It's fine-grained. Retry policy vs circuit breaker: Retry: retries a failed request against any available endpoint. Outlier detection: removes a specific bad endpoint from rotation. Both are needed: retry for transient failures, outlier detection for persistently failing instances. Istio observability vocabulary: Kiali: service graph UI for Istio. Shows traffic flow, health, mTLS status. Prometheus integration: Envoy emits metrics (request rate, latency, error rate) scraped by Prometheus. Distributed tracing: Envoy propagates B3/W3C trace headers — applications must forward them for end-to-end traces. Jaeger/Zipkin integration. Access log: Envoy can log every request with rich fields (upstream cluster, response code, bytes, duration). In conversation: 'The mesh circuit breaker saved us during the payment incident. Without it, the 5% error rate would have cascaded into 100% checkout failures as all threads blocked on the failing endpoint.'
5 / 12
A platform engineer discusses service mesh alternatives at an architecture review: "Istio is the full-featured option but it adds operational complexity — istiod, sidecar injector, the CRDs, the debug overhead. For teams that just need mTLS and basic observability, Linkerd is simpler: a Rust-based micro-proxy (not Envoy), lower resource overhead, easier to operate. Cilium with eBPF goes further — it implements the mesh at the kernel level without sidecars, so no added latency from proxy hops. The trade-off: Cilium requires newer kernels and is harder to debug. Choose based on your requirements: features vs simplicity vs performance." What is the main trade-off of using a sidecar-less (eBPF-based) service mesh like Cilium compared to a sidecar mesh like Istio?
Sidecar mesh costs: each pod gets an Envoy sidecar (typically 50-100MB RAM). Per-request latency: each hop adds ~0.5-1ms (ingress sidecar → network → egress sidecar). For microservices with many internal calls, this adds up. Sidecar injection complexity, debugging complexity (two containers per pod). Sidecar-less / eBPF mesh (Cilium, Calico with eBPF): network policies and observability enforced in the Linux kernel using eBPF programs. No sidecar container. Near-zero overhead. Cilium Mesh (Cilium + Hubble): provides L3/L4 network policy, L7 policy (HTTP, Kafka, DNS), flow visibility (Hubble UI), and mTLS via SPIRE. Requires Linux kernel 5.2+ ideally. Service mesh landscape: Istio: full-featured, mature, large community. Envoy data plane. Complex to operate. Linkerd: simpler, Rust micro-proxy (lighter than Envoy), better UX. Less feature-rich. Consul Connect: HashiCorp, cross-platform (VMs + K8s). AWS App Mesh: managed, Envoy-based, AWS-native integrations. Cilium: eBPF-based CNI + mesh. Istio ambient mode (Istio 2023+): moves Istio to a sidecar-less "ambient" model using a per-node proxy (ztunnel) for L4 and optional Waypoint proxies for L7 — aims to reduce sidecar overhead while keeping Istio's features. In conversation: 'We chose Linkerd over Istio because our team can actually understand it. The simpler model means fewer 3am incidents trying to debug why a VirtualService isn't matching.'
6 / 12
John (DevOps Engineer): 'Hey team, we're seeing some latency spikes on the OrderService. I've been using Istio's tracing features to investigate. The Envoy sidecars are collecting detailed metrics about request timings. What does 'request duration' in this context *primarily* represent?
Request duration refers specifically to the time spent within the Envoy sidecar proxy. It's not the overall network latency or the processing time of the service itself. Envoy's role is to intercept and potentially modify requests, adding that delay as a measured component – this is key to understanding how the mesh impacts performance.
7 / 12
Sarah (Lead Developer): 'I'm seeing a lot of 'retry' events in our Grafana dashboard for the UserProfile service. The Service Mesh monitoring shows Envoy is automatically retrying failed requests due to transient network errors. What does 'circuit breaker' relate to within this context, considering Istio's configuration?'
Circuit breakers in a service mesh like Istio are designed to prevent cascading failures. They intelligently monitor service availability and temporarily halt traffic when an upstream service becomes unavailable, allowing it time to recover without overwhelming the downstream service. This is different from simply retrying indefinitely (option A) or limiting concurrency (option C).
8 / 12
Code Review Comment: 'The Envoy sidecars are injecting excessive overhead into the OrderService. I've flagged this for further investigation.' What does 'injecting excessive overhead' likely refer to in the context of a service mesh?
'Injecting excessive overhead' refers to a measurable increase in resource usage (CPU and memory) caused by the sidecar proxies. Envoy's functions – such as mTLS encryption and detailed monitoring – consume resources. Option B is the most accurate description of this effect; options A and C are related but not the core meaning, and option D describes deployment changes, not resource consumption.
9 / 12
Slack Message: '@team – we're seeing a high number of 'HTTP 503 Service Unavailable' errors coming from the InventoryService. Istio's telemetry shows Envoy is frequently retrying these requests, but the failures persist.' What is the primary purpose of Envoy's retry mechanism in this scenario?
The retry mechanism is designed to address transient network problems – such as brief outages or congestion – that would otherwise cause HTTP 503 errors. Envoy automatically re-attempts the failed request, attempting to recover from these intermittent issues. Options A, C and D describe different behaviors rather than the core function of retries.
10 / 12
PR Description: 'Updating the VirtualService for the ProductCatalog service to utilize a canary deployment strategy. We'll route 20% of incoming traffic to the new version (v3) while monitoring its performance closely.' What does 'canary deployment' typically involve in this context?
A canary deployment is a risk mitigation technique where a small percentage of traffic is directed to a new service version before it's rolled out fully. This allows developers to identify and address any issues in a controlled environment – minimizing the impact on users. Option A describes a full rollout, which is generally undesirable for high-risk deployments.
11 / 12
Standup Update: 'I've been using Istio's traffic mirroring feature to investigate performance problems with the ReportingService. I'm observing all requests going through the mesh and capturing detailed latency data.' What is the primary benefit of using traffic mirroring in this scenario?
Traffic mirroring allows you to duplicate network traffic passing through the mesh without affecting the original service's performance. This is crucial for detailed analysis and debugging because it provides a live copy of the requests being processed by the ReportingService. Options A, C, and D describe different functionalities or security measures.
12 / 12
API Response (example):{ "mesh_metrics": {"envoy_cpu_usage": "150MB", "mTLS_overhead": "20ms"}, "service_latency": {"order_service": "50ms"}}. Based on this response, what does the 'mTLS_overhead' metric likely represent?
'mTLS_overhead' in this context refers to the additional processing time – and therefore CPU usage – incurred during the mTLS (mutual Transport Layer Security) handshake. This is a common metric monitored when using service meshes for enhanced security. Options B, C, and D describe different metrics or aspects of mesh operation.
What does the "Service Mesh Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to service mesh vocabulary through 12 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 12 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.