CKS Minimize Microservice Vulnerabilities Practice Question
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?
⚠ Common exam trap
Watch out — candidates often confuse DestinationRule's `trafficPolicy.tls.mode: ISTIO_MUTUAL` with PeerAuthentication's `mtls.mode: STRICT`; candidates often mistakenly think DestinationRule enforces mTLS, but it only configures TLS for outbound traffic, not inbound authentication enforcement.
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: STRICT
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.
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
This setting applies to the client side of the connection: a DestinationRule tells the Envoy proxy what TLS context to use when sending requests to a given service. ISTIO_MUTUAL configures the client to speak Istio mTLS, but it does not instruct the server to reject plaintext traffic. Namespace-wide enforcement of mutual TLS is the job of a PeerAuthentication policy with mtls.mode: STRICT, so this alone cannot enforce mTLS.
- ✗
VirtualService with tls.mode: SIMPLE
Why it's wrong here
VirtualService is an Istio resource for routing, mirroring, or fault injection, and it has no tls.mode field for mTLS; TLS configuration on the server side belongs in a Gateway or DestinationRule. Even if you attempted to set 'tls.mode: SIMPLE' on a VirtualService, Istio would ignore or reject it, and SIMPLE denotes TLS without client certificates, not mutual TLS. Routing objects are orthogonal to mTLS enforcement.
- ✓
PeerAuthentication with mtls.mode: STRICT
Why this is correct
PeerAuthentication is the Istio policy object that controls inbound TLS enforcement on the server side, and mtls.mode: STRICT demands that all traffic arriving at the workload be wrapped in Istio mutual TLS. Any plaintext or non-Istio TLS connection is rejected with a 403 response, so this is the correct way to enable mTLS between services in a namespace. It works alongside DestinationRules, which configure the client side, but enforcement of the policy happens here.
- ✗
ServiceEntry with resolution: NONE
Why it's wrong here
A ServiceEntry is designed to register external services (outside the service mesh) with the service registry, and 'resolution: NONE' simply tells Istio to skip DNS or service discovery for that endpoint. It has no impact on the mutual TLS policy of internal namespace workloads, because it does not apply to traffic between in-mesh services. Using it would not cause proxies to require client certificates and would not affect the mesh's mTLS posture.
Go deeper
Related to this question
About these practice questions
This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.