CKS Minimize Microservice Vulnerabilities Practice Question
An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?
⚠ Common exam trap
The CKS exam often tests the distinction between PeerAuthentication (server-side enforcement) and DestinationRule (client-side configuration), leading candidates to incorrectly choose DestinationRule for namespace-wide mTLS 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 in the namespace
PeerAuthentication defines the authentication policy for workloads within a namespace. Setting `mtls.mode: STRICT` in a PeerAuthentication resource for the 'mesh' namespace enforces that all services in that namespace require mutual TLS for incoming traffic, ensuring that only authenticated and encrypted connections are accepted. This is the correct Istio resource to enforce mTLS at the namespace level.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
PeerAuthentication with mtls.mode: STRICT in the namespace
Why this is correct
PeerAuthentication is the Istio custom resource that defines the server-side mTLS policy for accepted traffic. Setting `mtls.mode: STRICT` tells the sidecar proxy to reject all plaintext HTTP and require mutual TLS on every inbound connection to workloads in that namespace, making it a true namespace-wide enforcement. It is the standard, authoritative way to enforce mTLS between services because it specifically governs peer authentication, not routing or client-side TLS configuration.
- ✗
VirtualService with tls mode
Why it's wrong here
A VirtualService is an Istio traffic management resource used to define routing rules, such as weighting, HTTP match conditions, and route destinations. Its optional `tls` match stanza only matches incoming TLS or HTTPS connections based on attributes like SNI and URI, allowing the proxy to route them appropriately; it does not configure or enforce any TLS/mTLS security policy. Thus, using a VirtualService with a tls mode cannot make services require mutual TLS from peers, because it lacks the server-side enforcement mechanism.
- ✗
DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
Why it's wrong here
A DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` configures how a client sidecar establishes TLS when connecting to a particular host or subset. It only affects the client side of the connection—telling that sidecar to send mTLS to the destination—but it does not make the destination server require mTLS or reject plaintext traffic. Since it is scoped to specific destination rules and cannot enforce server-side acceptance, it is insufficient as a namespace-wide mTLS enforcement mechanism.
- ✗
ServiceEntry for external services
Why it's wrong here
A ServiceEntry is used to add external services (hosts outside the mesh) to the internal service registry so sidecars can route and enforce policies for egress traffic. While a ServiceEntry can include TLS or mTLS settings for the connection to an external endpoint, it has no bearing on traffic between internal services in a namespace. Therefore, it cannot enforce mTLS between internal services and is irrelevant to the task of securing all in-mesh service-to-service communication.
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 →
Same concept, more angles
1 more way 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. An administrator wants to enforce mutual TLS (mTLS) between all services in an Istio service mesh. Which resource should be configured?
medium- A.AuthorizationPolicy
- B.ServiceEntry
- C.VirtualService
- ✓ D.PeerAuthentication
Why D: PeerAuthentication is the correct resource because it defines the TLS mode for traffic between services within the Istio mesh. By setting the mode to STRICT, mTLS is enforced, requiring all service-to-service communication to use mutual TLS. This is the Istio-native way to enable mTLS at the mesh or namespace 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.