Practise vocabulary for service mesh traffic management: virtual services, destination rules, canary deployments, circuit breakers, retry policies, and timeout configuration.
0 / 10 completed
1 / 10
In Istio, what is a VirtualService and what does it control?
A VirtualService configures the Envoy sidecar proxies to route requests according to rules. Example: route 90% of traffic to version v1 and 10% to version v2 (canary). Route requests with header 'x-canary: true' to v2 regardless of weight. Apply a 3-second timeout and 2 retries. The VirtualService is the traffic routing policy; the DestinationRule configures what happens when traffic reaches each destination.
2 / 10
What is a DestinationRule in Istio traffic management?
DestinationRule configures traffic behaviour after the VirtualService has determined the destination. Key capabilities: defining subsets (e.g., 'v1' = pods with label version:v1, 'v2' = pods with label version:v2) for VirtualService routing. Load balancing policy: ROUND_ROBIN, LEAST_CONN, RANDOM. Connection pool: max connections, pending requests, retries. Outlier detection (circuit breaker): eject pods that return 5xx errors consecutively.
3 / 10
What is 'traffic splitting' via service mesh and how does it enable canary deployments?
Mesh-based canary deployment: VirtualService weight: [{destination: {host: myservice, subset: v1}, weight: 95}, {destination: {host: myservice, subset: v2}, weight: 5}]. This sends 5% of real production traffic to v2 regardless of replica count — unlike Kubernetes replica-based canary, which requires maintaining proportional pod counts. Mesh canary allows 1% traffic to v2 with 0 replicas waste and enables header-based routing for internal testing.
4 / 10
What is a 'circuit breaker' in service mesh vocabulary and when does it activate?
Circuit breaker in Istio is implemented as outlier detection in DestinationRule: consecutiveGatewayErrors: 5 means after 5 consecutive 5xx responses, the pod is ejected from the load balancing pool for baseEjectionTime (e.g., 30 seconds). This prevents a single failing pod from receiving traffic while it recovers. The circuit breaker 'opens' (ejects) and then 'half-opens' after the ejection time to probe if the pod has recovered.
5 / 10
What is a 'retry policy' in service mesh traffic management vocabulary?
VirtualService retry configuration: retries: {attempts: 3, perTryTimeout: 2s, retryOn: 'gateway-error,connect-failure,retriable-4xx'}. The mesh retries automatically, transparently to the application — the app makes one call, the sidecar handles up to 3 attempts internally. Key consideration: only retry idempotent operations. The retryOn field specifies conditions: gateway-error (502/503/504), connect-failure (connection refused), retriable-4xx (409 Conflict).
6 / 10
Alice (Senior Developer) just commented on a code review for the new AuthService. She's asking about implementing rate limiting. 'I need to ensure no single client can make more than 10 requests per second to prevent abuse.' Which of the following terms best describes what Alice is requesting, within the context of a service mesh like Istio?
Rate limiting precisely addresses Alice's concern about preventing abuse by controlling the rate of incoming requests. While Circuit Breakers handle failures and Virtual Endpoints manage routing, they don't directly control the number of requests. Envoy Filters operate at a lower level, modifying headers – this is a common misunderstanding; rate limits are a core traffic management function.
7 / 10
Bob (DevOps Engineer) is configuring Istio for the new OrderProcessingService. He wants to ensure that if the database becomes unavailable, requests to the service automatically retry a certain number of times before failing. Which traffic management feature should he primarily utilize?
Retry policies are specifically designed to handle transient failures by automatically retrying requests with configurable delays. Virtual Services manage routing, DestinationRules control traffic distribution based on metadata, and Envoy sidecars provide the fundamental infrastructure for Istio's operation – this is the key functionality Bob needs here.
8 / 10
Charlie (Lead Architect) is discussing a new feature release with his team. He proposes using traffic splitting to gradually roll out the update to 10% of users before fully deploying it. Which service mesh capability does this leverage?
Canary deployments are a direct application of traffic splitting, where a small percentage of users receive the new version while the majority continues with the old one. This allows for monitoring and identifying issues before widespread release; blue-green deployment is a distinct deployment strategy, whilst weighted routing and mTLS represent different traffic management techniques.
9 / 10
David (Developer) is investigating an issue with the PaymentService. Monitoring tools show a sudden increase in error rates. The service mesh's telemetry indicates that a 'Circuit Breaker' has been triggered. What does this *typically* mean?
A circuit breaker activates when a service detects repeated failures (e.g., timeouts or errors) – this is its core function. It temporarily stops sending traffic to that service to prevent further issues from propagating and allowing the underlying problem to resolve itself. Option A describes a successful deployment, B is incorrect as circuit breakers are designed for *failures*, and D is irrelevant.
10 / 10
Eve (Developer) needs to configure the UserManagementService to retry failed requests to a downstream microservice three times with a 5-second delay between each attempt. Which component of a service mesh would she primarily use to achieve this?
Envoy filters offer granular control over HTTP requests and responses, providing a flexible mechanism to implement retry policies with configurable delays. DestinationRules manage routing, VirtualServices define access points, and Traffic Mirrors are used for observation – the retry policy is best handled by modifying the request itself.
What will I learn from the "Service Mesh Traffic Management Vocabulary" exercise?
Practise vocabulary for service mesh traffic management: virtual services, destination rules, canary deployments, circuit breakers, retry policies, and timeout configuration.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 10 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Service Mesh Operations Language exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss service mesh operations language topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 10 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Service Mesh Operations Language exercises?
See the full Service Mesh Operations Language exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.