Practise vocabulary for service mesh mTLS and observability: mutual TLS, certificate rotation, zero trust, distributed tracing, trace context propagation, and mesh dashboards.
0 / 10 completed
1 / 10
What is mTLS (mutual TLS) in a service mesh and how does it differ from regular TLS?
Standard TLS: client verifies server identity (certificate). mTLS: both sides verify each other. In a service mesh, mTLS is implemented transparently by the sidecar proxies — the application itself sends plaintext; the sidecar intercepts and wraps it in mTLS. This means every service-to-service call is encrypted and authenticated without developer effort. Istio's PeerAuthentication policy enforces mTLS: mode STRICT rejects non-mTLS traffic; PERMISSIVE accepts both (for migration).
2 / 10
What is 'certificate rotation' in a service mesh and why is it important?
Service mesh certificate rotation is handled by the control plane (Istio's istiod, Linkerd's trust anchor). Certificates are intentionally short-lived (24 hours in Istio by default) — if a certificate is compromised, it expires quickly. The control plane automatically issues new certificates to sidecars before expiry. This is why mesh-based mTLS is more secure than manually managed certificates: automation ensures no certificate is ever expired or forgotten.
3 / 10
How does a service mesh enable 'zero trust' networking?
Zero trust via mesh: (1) mTLS provides cryptographic identity — every service has a verifiable certificate-based identity (SPIFFE ID). (2) AuthorizationPolicy defines: 'service checkout can call service inventory, but nothing else can'. Without an explicit allow rule, traffic is denied. This replaces implicit network trust ('if you're on the internal network, you're trusted') with explicit identity-based trust ('prove who you are and show you're authorised for this call').
4 / 10
What is 'distributed tracing' in a service mesh context, and what do Jaeger and Zipkin provide?
Distributed tracing produces a trace tree: TraceID abc123 → Span: API-gateway (50ms) → Span: order-service (200ms) → Span: inventory-service (180ms) → Span: database (160ms). This shows that the database call inside inventory-service is the bottleneck. Jaeger and Zipkin are open-source distributed tracing backends. The mesh can inject trace headers (B3, W3C TraceContext) automatically — but services must propagate those headers in outgoing calls for the trace to be complete.
5 / 10
What is 'trace context propagation' and why must application code participate even with a service mesh?
The mesh sidecar can automatically add trace headers to incoming requests and record the span for the network hop. But the application code must pass those headers through: when order-service calls inventory-service, it must include the X-B3-TraceId and X-B3-SpanId headers it received. If it doesn't, the inventory-service span has no parent and appears as an unrelated standalone trace. Most tracing libraries (OpenTelemetry) handle this automatically via instrumentation — the key is to instrument the HTTP client, not just the server.
6 / 10
Code Review Comment: Sarah flagged this PR with the comment: 'Looks like you're using a self-signed certificate here. While it works for testing, we need to use certificates issued by our internal CA for production deployments. Can you explain why and how you plan to transition?' What does Sarah *really* mean when she mentions a 'self-signed certificate' in this context?
Sarah is referring to the origin of the certificate. A 'self-signed' certificate is one created and signed by the entity it secures, without relying on a Certificate Authority (CA). This contrasts with certificates issued by a CA like Let's Encrypt or your organization's internal CA, which provides a higher level of trust and verification.
7 / 10
Slack Message: Alex (DevOps) sent this message to the team: 'We're seeing increased latency in our microservices. I'm investigating potential issues with mTLS handshake times and suspect we might need to optimize certificate retrieval.' What is Alex most concerned about regarding mTLS?
Alex's message highlights a critical concern: the initial mTLS handshake. This process involves significant overhead – validating the client's certificate against the server's trust store, exchanging keys, and establishing a secure connection. This is often the biggest bottleneck when troubleshooting latency issues related to mTLS.
8 / 10
PR Description: 'Applying certificate rotation policy to all microservices using Istio. This ensures that we regularly update our certificates to mitigate the risk of compromised keys and maintain compliance with security best practices.' What is the *primary* benefit of implementing a 'certificate rotation' policy?
Certificate rotation is primarily about security. By regularly changing (rotating) certificates, you limit the time a compromised key can be exploited. A longer certificate lifespan increases the risk if a key is stolen or if a vulnerability is discovered in the underlying algorithm.
9 / 10
Standup Update: David reported to the team: 'I've been working on implementing distributed tracing with Jaeger. We're using trace context propagation to ensure that requests are tracked across our entire microservices architecture.' What is the purpose of 'trace context propagation' in this scenario?
Trace context propagation is essential for building effective distributed traces. It's the process of including tracing information – like span IDs and trace IDs – within each service call or message. This allows Jaeger (or other tracing systems) to link related spans together, creating a complete picture of a request's journey across multiple services.
10 / 10
API Response Snippet: The API returned this error message: 'Invalid Certificate Chain – Missing intermediate CA certificate.' Considering mTLS and service mesh deployments, what does this error most likely indicate?
This error message points to a problem within the certificate chain. mTLS relies on a trusted chain of certificates – the client's certificate, intermediate CA certificates, and the root CA certificate. If any link in this chain is missing or invalid, the server will reject the connection as untrusted.
What will I learn from the "mTLS and Observability Vocabulary" exercise?
Practise vocabulary for service mesh mTLS and observability: mutual TLS, certificate rotation, zero trust, distributed tracing, trace context propagation, and mesh dashboards.
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.