5 exercises — 5 exercises practising mutual TLS, SPIFFE workload identities, PeerAuthentication modes, and AuthorizationPolicy vocabulary in service meshes.
0 / 10 completed
1 / 10
A security engineer asks why Istio mTLS is described as mutual TLS rather than regular TLS. Which explanation is correct?
mTLS = both parties authenticate — the server verifies the client's certificate, and the client verifies the server's certificate. This enables zero-trust service-to-service authentication.
In a typical HTTPS connection (regular TLS), only the server presents a certificate. The browser verifies the server is legitimate, but the server doesn't verify who the browser is (authentication is done via cookies/tokens at the application layer). In Istio mTLS, the payment-service doesn't just verify that it's talking to the order-service's IP address — it verifies the order-service's SPIFFE certificate. If a rogue container with the same IP somehow intercepts traffic, it won't have the valid SPIFFE certificate and the mTLS handshake will fail.
Key vocabulary: • mutual TLS (mTLS) — both parties present and verify X.509 certificates • workload identity — the SPIFFE certificate Istio issues to each service's Envoy sidecar • SPIFFE — Secure Production Identity Framework for Everyone; standard for workload identity in cloud-native systems
2 / 10
What is the difference between Istio's STRICT and PERMISSIVE mTLS modes in a PeerAuthentication resource?
PERMISSIVE mode is the migration-friendly setting — it accepts both mTLS and plain-text, allowing teams to gradually onboard services before switching to STRICT.
A common Istio rollout pattern: (1) set PeerAuthentication to PERMISSIVE cluster-wide while enabling sidecar injection namespace by namespace — services with sidecars automatically use mTLS with each other, services without sidecars still work with plain-text; (2) once all namespaces have sidecars and mTLS is confirmed working, switch the cluster-wide PeerAuthentication to STRICT. After that, any plain-text traffic (e.g., from a service outside the mesh, or a misconfigured pod without injection) will be rejected at the Envoy sidecar.
Key vocabulary: • STRICT mTLS — rejects plain-text; all traffic must use mTLS certificates • PERMISSIVE mTLS — accepts both mTLS and plain-text; used during mesh migration • PeerAuthentication — Istio resource setting mTLS mode per namespace or workload
3 / 10
A platform engineer explains: "We use SPIFFE IDs in our AuthorizationPolicy to control which services can call the payment API." What is a SPIFFE ID and how is it used in this context?
SPIFFE IDs tie service identity to Kubernetes service accounts — the AuthorizationPolicy allows or denies based on cryptographic proof of identity, not IP addresses which can be spoofed.
Istio's built-in CA (Citadel, now part of istiod) issues X.509 certificates to each sidecar. The certificate's Subject Alternative Name (SAN) contains the SPIFFE ID: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>. When service A connects to service B with mTLS, service B's Envoy extracts the SPIFFE ID from service A's certificate. The AuthorizationPolicy can then match on principal (SPIFFE ID pattern) — for example, only allow requests from spiffe://cluster.local/ns/orders/sa/order-service to the payment endpoint.
Key vocabulary: • SPIFFE ID — spiffe://<trust-domain>/ns/<namespace>/sa/<sa-name>; workload's cryptographic identity • principal — in Istio AuthorizationPolicy, the identity of the source service (its SPIFFE ID) • AuthorizationPolicy source — restricts which principals or namespaces can initiate requests
4 / 10
A security review asks: "Does Istio mTLS encrypt data in transit between services?" Which answer is accurate?
mTLS provides both authentication AND encryption in a single mechanism — it is TLS with client certificate authentication on top.
TLS itself encrypts data using symmetric keys negotiated during the handshake. mTLS adds mutual authentication to that standard TLS process. So Istio STRICT mTLS: (1) both sidecars exchange and verify certificates (authentication), (2) they negotiate a symmetric session key, (3) all traffic between them is encrypted (encryption). This addresses both the "who are you?" and "is the data private in transit?" questions simultaneously. For compliance requirements like "all data must be encrypted in transit", Istio STRICT mTLS satisfies this for all inter-service communication — with zero application code changes.
Key vocabulary: • encryption in transit — all bytes on the wire between Envoy sidecars are encrypted via TLS session keys • authentication — mTLS certificates prove workload identity at connection establishment • STRICT mTLS — enforces both encryption and mutual authentication for all intra-mesh traffic
5 / 10
An engineer says: "We need to allow the reporting service to read from the orders API, but deny all other services." Which Istio resource implements this, and what does the policy specify?
AuthorizationPolicy is Istio's L7 access control — it can enforce fine-grained allow/deny rules based on service identity, namespace, HTTP method, and URL path.
Istio uses a default-deny posture when any AuthorizationPolicy exists on a workload: if a policy exists and a request doesn't match any ALLOW rule, it is denied. The policy for this case: spec.selector (matching orders service pods), rules[0].from.source.principals (SPIFFE ID of reporting service), rules[0].to.operation.methods (GET), rules[0].to.operation.paths (/orders/*). Note that NetworkPolicy operates at L3/L4 (IP/port) only — it can't distinguish GET from POST or restrict specific URL paths. AuthorizationPolicy operates at L7 via Envoy.
Key vocabulary: • AuthorizationPolicy — Istio L7 access control; allow/deny based on identity, method, path • default deny — when any ALLOW policy exists, traffic not matching it is implicitly denied • source.principals — SPIFFE IDs of services allowed to initiate requests
6 / 10
Sarah is a developer working on a new microservice. During code review, she notices that the service isn't using mTLS for communication with other services in her mesh. Her team lead asks: 'What's the most important reason to use mTLS?'
mTLS is crucial for establishing mutual authentication – verifying both the client (service) and server's identity. This significantly enhances security by preventing man-in-the-middle attacks. While TLS provides encryption, mTLS adds the vital component of identity verification.
7 / 10
David is troubleshooting a connectivity issue between two services in his mesh. He notices that Istio is configured with strict access control policies. Which setting would *most* likely be preventing the communication?
SPIFFE IDs are unique identifiers used in Istio's authorization policies. A mismatch would directly prevent communication between services that aren't correctly authenticated and authorized based on these IDs. While other options could cause problems, they wouldn't be the primary reason for blocked mTLS communication.
8 / 10
"We need to ensure that only our internal services can access the sensitive data API. How do we achieve this using Istio?"
Istio's VirtualServices combined with Traffic Policies are the standard way to control granular access to services. This allows you to define rules based on service names or labels – effectively creating a 'wall' around your sensitive API, ensuring only authorized services can communicate with it.
9 / 10
Mark is reviewing a PR that introduces mTLS to a new service. The commit message states: 'Enabling mTLS for secure communication between the frontend and backend services.' What key benefit does this primarily address?
The primary goal of mTLS is to safeguard data in transit. By verifying identities, it prevents attackers from impersonating services and intercepting sensitive information. While mTLS *can* indirectly improve performance through reduced attack surface, its core function is security.
10 / 10
"During a standup meeting, John says: 'We're using Istio to enforce mTLS policies on all our services.' What does he *actually* mean?"
mTLS fundamentally means that *mutual* TLS authentication is being enforced. This involves both services verifying each other's identities before establishing a secure connection – the cornerstone of Istio's security posture in this context.
What will I learn from the "mTLS and Mesh Security — Vocabulary — Service Mesh Operations | CoderLingo" exercise?
5 exercises practising mutual TLS, SPIFFE workload identities, PeerAuthentication modes, and AuthorizationPolicy vocabulary in service meshes.
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.