5 exercises — 5 exercises practising service mesh observability vocabulary — golden signals, Kiali service graphs, distributed tracing, and Envoy metrics language.
0 / 10 completed
1 / 10
A team says: "One benefit of the service mesh is that we get L7 observability without application code changes." What does this mean?
Envoy operates at L7 (application layer) — it understands HTTP, gRPC, and headers — so it can generate rich metrics for every request without the application doing anything.
Compare this to L3/L4 monitoring (IP/port level — e.g., network flow logs): at L4, you can see "X bytes from service A to service B," but you can't see HTTP status codes or request paths. Envoy sees everything at L7: the HTTP method, URL path, response code, and response time for every request. It exposes these as Prometheus metrics (istio_requests_total, istio_request_duration_milliseconds) with labels for source service, destination service, and response code — enabling per-route latency and error dashboards with zero application instrumentation.
Key vocabulary: • L7 observability — metrics at the HTTP/gRPC application layer (status codes, latency, routes) • istio_requests_total — Prometheus counter: request count per source/destination/status_code • zero instrumentation — mesh-generated metrics require no application code changes
2 / 10
During a service review, a teammate refers to the four golden signals in the context of a service mesh. Which set of signals is correct?
The four golden signals — latency, traffic, errors, saturation — are the standard lens for service health, and a service mesh provides them for every service pair automatically.
Before a service mesh, each team had to instrument their service to expose these signals. With the mesh, Envoy generates them for every service-to-service call: Traffic = requests/second (istio_requests_total rate), Errors = error rate (HTTP 5xx / total), Latency = request duration histogram (istio_request_duration_milliseconds), Saturation = active connections / connection pool limit. The power: you can see the golden signals for a service your team doesn't own, or for a legacy service with no instrumentation.
Key vocabulary: • traffic (golden signal) — requests per second; demand on the service • errors (golden signal) — rate of failed requests; commonly HTTP 5xx / total • saturation (golden signal) — how close a service is to its capacity limit
3 / 10
A platform engineer says: "Look at the Kiali service graph — there's a red edge between checkout and inventory." What does a red edge in Kiali indicate?
In Kiali, edge colour represents traffic health — green (healthy), yellow (degraded), red (high error rate). A red edge is an actionable signal pointing to a service communication problem.
Kiali's service graph visualises the live traffic topology: nodes are services, edges are active connections between them. Each edge shows: request rate (RPS label), error percentage (coloured by threshold), and response time. A red edge between checkout and inventory means a significant percentage of checkout-to-inventory requests are failing (returning 5xx or connection errors). Combined with Kiali's distributed trace links, you can drill from the red edge directly to failing trace samples to identify the root cause.
Key vocabulary: • Kiali service graph — real-time service topology visualisation for Istio; nodes = services, edges = traffic flows • edge colour — green (healthy), yellow (degraded), red (high error rate); thresholds configurable • service graph — visual map of which services communicate with which; automatically generated from mesh telemetry
4 / 10
An engineer explains: "Istio can generate distributed traces, but the application still needs to propagate trace context headers." Why is this required?
Envoy creates spans automatically, but it needs the trace context to know which trace they belong to — and only the application knows which incoming request caused which outgoing request.
Envoy generates a span for every request it handles (inbound and outbound). For outbound requests, Envoy includes the trace context headers automatically. The problem: when the application receives request A and makes three downstream requests (B, C, D), Envoy at the outbound sidecar needs to know "this outbound call is part of trace X, span Y." That information comes from the inbound request's trace context headers. The application must extract those headers from the incoming request and inject them into the outgoing requests. Without this, Envoy generates three isolated spans for B, C, D that can't be connected to the original trace for A.
Key vocabulary: • trace context propagation — application forwards B3/W3C headers from incoming to outgoing requests • traceparent — W3C trace context header: version-traceId-parentSpanId-flags • span stitching — linking individual spans into a complete end-to-end trace using shared traceId
5 / 10
A manager asks: "Our service mesh gives us observability for free — do we still need application-level metrics?" Which answer best represents the nuanced reality?
The mesh and application instrumentation are complementary — mesh metrics cover the network layer; application metrics cover business logic and internal state.
A concrete example: Envoy can tell you that 2% of requests to the payments service are returning 503. But it can't tell you: how many payment transactions are in a pending state, what the database connection pool utilisation is, or how many fraud checks are being bypassed by the fallback logic. Those require application instrumentation. The ideal observability stack combines: mesh metrics (automatic, per-service network health) + application custom metrics (business logic) + structured application logs (event details) + distributed traces (request flow). The mesh reduces the baseline instrumentation burden significantly — teams should focus their instrumentation effort on business-relevant signals.
Key vocabulary: • mesh metrics — automatic HTTP/gRPC metrics generated by Envoy at the network layer • application metrics — custom instrumentation for business logic, internal state, and domain events • complementary observability — mesh + application metrics together provide full-stack visibility
6 / 10
Liam (Senior Developer) posted this comment on a code review for the new payment service: 'I'm seeing high latency spikes when processing transactions. The mesh is reporting increased request durations and an elevated error rate for the payment-gateway service. Can we investigate further?' What's the *primary* reason Liam is using the service mesh metrics to address this issue?
Liam is leveraging the service mesh's L7 observability capabilities. Unlike traditional metrics which often provide limited context about *where* a problem originates, the service mesh allows him to pinpoint latency spikes and error rates specifically for the payment-gateway service – crucial for effective debugging. Option A describes scaling, option C describes failover, and option D is a basic isolation feature, not the core purpose of using the mesh's metrics.
7 / 10
Sarah (Platform Engineer) is explaining a new monitoring dashboard to a junior developer. She says: 'We're using Istio to collect data on each service's latency and success rates. We've configured it to send these metrics to Prometheus, where we can then visualize them.' What does Sarah primarily mean by 'Istio collecting data'?
Sarah is referring to Istio's intercepting capabilities – it acts as a proxy and observes all traffic flowing through the mesh. This allows it to extract metrics like latency and success rates without requiring any changes to the application code itself. Options A and D are incorrect because Istio doesn't directly query code or use external services for this purpose; option C is unrelated.
8 / 10
David (Lead Developer) just posted this comment on a PR describing the new user authentication service: 'I've noticed some intermittent errors during login attempts. The mesh is showing increased HTTP 502 Bad Gateway rates for requests hitting the auth service. What does this suggest about the health of the service?'
A high rate of HTTP 502 Bad Gateway errors, as reported by the service mesh, strongly suggests that the authentication service itself is struggling to handle requests. While network issues *could* contribute, this message points directly to a problem within the service's processing logic or resource constraints. The mesh isn't masking the issue; it's highlighting it with detailed metrics.
9 / 10
Ben (DevOps Engineer) is troubleshooting a slow API endpoint. He examines the service mesh telemetry and notices that Envoy sidecars are consuming significant CPU resources on several instances of the backend service. What's the most likely root cause?
High Envoy CPU usage often indicates a problem with the application running inside the sidecars. The sidecars are essentially proxying requests *and* performing some level of processing for each request – if the application is resource-intensive, this will significantly increase CPU consumption and impact performance. While inefficient code or network latency can also contribute, they wouldn't explain the high CPU usage directly.
10 / 10
Alex (a junior developer) mentioned to Maria (a senior engineer) that 'the service mesh is handling all the retries automatically.' Maria responds: 'That's great! Can you confirm it's configured with a maximum retry count of, say, 3?' What is Maria primarily asking about when discussing retry behavior within the service mesh?
Maria is focusing on the *control plane* configuration of the service mesh. While HTTP protocols have retry settings, a service mesh's core function is to provide automated retry logic—this is configured at the control plane level. Options A and C represent external factors, while option D describes a different aspect of error handling (circuit breakers).
What will I learn from the "Mesh Observability Language — Service Mesh Operations | CoderLingo" exercise?
5 exercises practising service mesh observability vocabulary — golden signals, Kiali service graphs, distributed tracing, and Envoy metrics language.
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.