Practice the vocabulary of splitting and routing traffic declaratively between service versions.
0 / 5 completed
1 / 5
At standup, a dev mentions splitting incoming traffic between two versions of a service by percentage, sending most requests to the stable version and a small fraction to a new one, without changing any application code. What Istio capability supports this?
Traffic splitting via a VirtualService's weighted routing rule sends most requests to the stable version of a service and a small percentage to a new one, without requiring any change to the application's own code. Sending one hundred percent of traffic to whichever version was deployed most recently offers no gradual, percentage-based rollout at all. This weighted routing is the core mechanism Istio uses to support a canary rollout between two service versions.
2 / 5
During a design review, the team wants Istio to automatically retry a failed request against a different upstream instance a bounded number of times, with a defined per-try timeout, rather than surfacing the first failure directly to the caller. Which capability supports this?
A retry policy configured with a bounded attempt count and a per-try timeout automatically retries a failed request against a different upstream instance, rather than surfacing the first failure directly to the caller. Surfacing every failure immediately with no retry configured pushes a transient, recoverable error straight through to the end user unnecessarily. This retry policy is one of Istio's core traffic management features layered on top of the underlying Envoy proxies it configures.
3 / 5
In a code review, a dev notices a VirtualService routes a request to a specific service version based on a header value, letting an internal tester reach a new version while ordinary traffic continues to the stable one. What does this represent?
Header-based traffic routing routes a request to a specific service version based on a header value, letting an internal tester reach a new version through a distinguishing header while ordinary traffic continues to the stable version untouched. Routing every request identically, with no conditional logic, gives no way to selectively expose a new version to just a targeted subset of traffic. This header-based routing is a common pattern for testing a new version safely before rolling it out more broadly.
4 / 5
An incident report shows a canary rollout accidentally sent fifty percent of production traffic to a broken new version because the VirtualService's weighted routing rule had been misconfigured with the wrong percentage split. What practice would prevent this?
Reviewing and validating a VirtualService's weighted routing percentages carefully before applying a canary rollout, and starting with a conservatively small percentage, limits the blast radius if the new version turns out to be broken. Applying the configuration with no review at all is exactly what let fifty percent of production traffic hit a broken version in this incident. This careful review and gradual percentage increase is a standard practice for any canary rollout driven by Istio's traffic splitting.
5 / 5
During a PR review, a teammate asks why the team uses Istio's VirtualService routing rules for a canary rollout instead of deploying the new version behind its own separate load balancer and manually redirecting some traffic to it. What is the reasoning?
A separate load balancer requires its own manually managed redirection logic, adding an extra piece of infrastructure outside the mesh to configure and maintain. Istio's weighted routing rule adjusts the traffic split declaratively, entirely within the mesh's own configuration, without touching application code or standing up separate infrastructure. The tradeoff is the added complexity of operating Istio itself and correctly authoring its routing rules for every canary rollout.
What does the "Istio Traffic Management Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to istio traffic management vocabulary through 5 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 5 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.