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.