Practise vocabulary for service mesh mTLS and observability: mutual TLS, certificate rotation, zero trust, distributed tracing, trace context propagation, and mesh dashboards.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.