CKS Minimize Microservice Vulnerabilities Practice Question
You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?
⚠ Common exam trap
Many exam-takers confuse DestinationRule with PeerAuthentication, thinking DestinationRule's 'tls' field controls mTLS mode, but DestinationRule only configures client-side TLS settings (e.g., SNI) for outbound traffic, not the server-side authentication policy that PeerAuthentication enforces.
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
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.
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
Why this is correct
PeerAuthentication is the Istio Custom Resource Definition (CRD) that directly defines the mTLS policy for workloads, either mesh-wide, per-namespace, or with a pod selector. Its mode field accepts STRICT, PERMISSIVE, or DISABLE, and STRICT tells the server sidecar to reject plaintext traffic and require a client certificate. This is the authoritative security policy for enforcing mutual TLS between internal services, so it is the correct resource for this task.
- ✗
ServiceEntry
Why it's wrong here
ServiceEntry has a different purpose: it registers external services (hosts outside the cluster) into the mesh so that traffic to them can be managed, observed, and routed. Although its endpoint definition may include connection-level TLS settings, that only describes how to dial the external endpoint, not whether internal workloads require mutual TLS. It cannot enforce or even specify the mTLS posture of services inside the mesh, so it is not the right resource here.
- ✗
VirtualService
Why it's wrong here
VirtualService is an L7 routing primitive that controls how requests are forwarded based on hosts, URIs, headers, or weights, and can inject faults or timeouts. It operates purely at the data-plane routing level and has no notion of authentication or encryption. Mutual TLS is a transport security property enforced by sidecar configuration before routing even takes place, so a VirtualService by itself cannot configure mTLS between services.
- ✗
DestinationRule
Why it's wrong here
DestinationRule manages post-routing behavior like load balancing, connection pool size, outlier detection, and circuit breakers, and it optionally carries a trafficPolicy.tls block to set client-side TLS mode. This client-side setting only controls what the calling sidecar sends (e.g., ISTIO_MUTUAL), not what the receiving workload must accept; the server-side mTLS requirement is governed exclusively by PeerAuthentication. Therefore, while DestinationRule is a necessary complement in many mTLS configurations, it is not the resource that configures mTLS between services on its own.
Go deeper
Related to this question
About these practice questions
One of 845 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 →
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.