CKS Minimize Microservice Vulnerabilities Practice Question
A security engineer wants to enable mutual TLS (mTLS) between services in an Istio service mesh. Which Istio resource should be used to define the mTLS mode for the entire mesh?
⚠ Common exam trap
A common pitfall in the CKS exam is confusing DestinationRule (which handles traffic routing and connection pool settings) with PeerAuthentication (which handles mTLS enforcement). Candidates often choose DestinationRule because it has a tls field, but for mesh-wide mTLS, PeerAuthentication with mode: STRICT is the correct resource.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
PeerAuthentication with mTLS mode set to STRICT
PeerAuthentication is the Istio resource specifically designed to define the authentication policy for workloads, including the mTLS mode. Setting `mTLS.mode: STRICT` in a PeerAuthentication policy enforces mutual TLS for all traffic within the mesh, ensuring that every service-to-service connection requires a valid client certificate. This is the correct resource for mesh-wide mTLS enforcement, as it operates at the authentication layer rather than the traffic routing layer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
Why it's wrong here
DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL is a client-side configuration that tells the sidecar to use mutual TLS when connecting to a specific destination service. However, it does not enforce mTLS mesh-wide; it only affects outbound traffic from the client, and the destination may still accept plaintext. Mesh-wide mTLS enforcement is handled by PeerAuthentication, which sets the server-side policy for what the destination requires.
- ✓
PeerAuthentication with mTLS mode set to STRICT
Why this is correct
PeerAuthentication with mTLS mode set to STRICT is the correct approach because PeerAuthentication is the Istio policy resource that enforces TLS at the server side. When mode: STRICT is applied, the sidecar proxy requires all incoming connections to use mutual TLS and rejects plaintext traffic, thereby enforcing mTLS for the selected workloads. This can be set at the mesh, namespace, or workload level, making it the standard way to enable mesh-wide mTLS.
- ✗
VirtualService with tls configuration
Why it's wrong here
VirtualService is a traffic routing resource in Istio, used to define rules for load balancing, request routing, fault injection, and similar traffic management. It does not configure TLS enforcement; the 'tls' field in a VirtualService is for matching routing based on SNI or for other advanced routing scenarios, not for setting mTLS policies. Since mTLS enforcement is a security policy and not a routing concern, VirtualService is not the appropriate resource for enabling mesh-wide mutual TLS.
- ✗
ServiceEntry with mTLS enabled
Why it's wrong here
ServiceEntry is used to register external services into the Istio service mesh so that they can be managed with mesh features like traffic routing and telemetry. While ServiceEntry can have TLS settings for egress traffic to those external endpoints, it does not configure mutual TLS between internal workloads. Enabling mTLS mesh-wide requires PeerAuthentication to enforce the policy on the server side, not a ServiceEntry, which is meant for external service registration, not internal security enforcement.
Go deeper
Related to this question
About these practice questions
One of 114 original CKS practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
5 more ways this is tested on CKS
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?
medium- ✓ A.PeerAuthentication
- B.ServiceEntry
- C.VirtualService
- D.DestinationRule
Why A: PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.
Variation 2. Which TWO of the following are valid ways to enable mTLS between services in a service mesh (e.g., Istio)?
medium- ✓ A.Creating a DestinationRule with a trafficPolicy that sets tls mode to ISTIO_MUTUAL
- B.Creating a ServiceEntry for the destination service
- C.Creating a NetworkPolicy that allows ingress on port 443
- ✓ D.Creating a PeerAuthentication resource with mTLS mode set to STRICT
- E.Creating an AuthorizationPolicy with DENY action
Why A: A DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` explicitly configures the client-side proxy (Envoy) to use mutual TLS when sending requests to the destination service. This is the standard Istio mechanism to enforce mTLS at the service-to-service communication level, ensuring both client and server certificates are exchanged and verified.
Variation 3. You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?
medium- A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
- B.VirtualService with tls.mode: SIMPLE
- ✓ C.PeerAuthentication with mtls.mode: STRICT
- D.ServiceEntry with resolution: NONE
Why C: PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.
Variation 4. In an Istio service mesh, you want to enforce mutual TLS (mTLS) between services in a specific namespace. Which resource should you create to set the default mTLS mode to STRICT for all workloads in that namespace?
medium- ✓ A.PeerAuthentication
- B.VirtualService
- C.ServiceEntry
- D.DestinationRule
Why A: A PeerAuthentication resource in Istio defines the mutual TLS (mTLS) mode for workloads within a namespace. By setting the `mtls.mode` to `STRICT`, you enforce that all service-to-service communication in that namespace must use mTLS, rejecting any plain-text HTTP traffic. This is the correct resource for setting a namespace-wide default mTLS policy.
Variation 5. In an Istio service mesh, you want to enforce mutual TLS (mTLS) between all services in the 'default' namespace. Which resource should you create?
medium- ✓ A.PeerAuthentication with mTLS mode STRICT
- B.Sidecar resource with outboundTrafficPolicy REGISTRY_ONLY
- C.ServiceEntry with resolution NONE
- D.DestinationRule with trafficPolicy tls mode ISTIO_MUTUAL
Why A: To enforce mutual TLS (mTLS) between all services in the 'default' namespace, you create a PeerAuthentication resource with mTLS mode set to STRICT. This policy enforces that all traffic within the namespace must use mTLS, rejecting any plaintext connections. PeerAuthentication is the Istio resource specifically designed to define mTLS enforcement at the namespace or mesh level.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.