CKS Minimize Microservice Vulnerabilities Practice Question
You need to ensure that all pods in a namespace can only communicate via mTLS. In Istio, which resource should you apply?
⚠ Common exam trap
In the CKS exam, candidates often confuse PeerAuthentication (which enforces mTLS at the server side) and DestinationRule (which configures client-side TLS settings), leading to mistakenly choosing DestinationRule when the question asks for enforcing mTLS across all pods.
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 mode: STRICT
PeerAuthentication with mode: STRICT is the correct resource to enforce mTLS for all pods in a namespace. It configures the Istio sidecar proxy to require mutual TLS for all inbound and outbound traffic within the mesh, rejecting any plaintext connections. This ensures that all inter-pod communication is encrypted and authenticated using X.509 certificates, aligning with the goal of minimizing microservice vulnerabilities.
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 mode: STRICT
Why this is correct
PeerAuthentication with mode: STRICT is the correct choice because it enforces mutual TLS at the workload level, requiring every connection to be authenticated via both client and server certificates. In this mode, the sidecar proxy rejects any plaintext or unauthenticated traffic, guaranteeing that all pod-to-pod communication in the namespace uses mTLS. This is the standard Istio mechanism for mandating strict mTLS across a namespace or mesh.
- ✗
DestinationRule with tls: ISTIO_MUTUAL
Why it's wrong here
DestinationRule with tls: ISTIO_MUTUAL configures the client-side TLS settings for outbound traffic, telling the Envoy proxy to initiate mutual TLS when connecting to a service. However, this rule only affects the client side; it does not enforce any authentication policy on the server side. A server can still accept plaintext connections if no matching PeerAuthentication policy restricts it, so this option alone does not guarantee that all pods only communicate via mTLS.
- ✗
PeerAuthentication with mode: DISABLE
Why it's wrong here
PeerAuthentication with mode: DISABLE explicitly turns off mutual TLS for the affected workloads, allowing plaintext traffic and rejecting no connections based on authentication. This is the exact opposite of the requirement, as it removes any mandatory authentication and leaves communication open to unencrypted or unauthenticated requests. It would fail the objective of ensuring that all pods communicate securely.
- ✗
PeerAuthentication with mode: PERMISSIVE
Why it's wrong here
PeerAuthentication with mode: PERMISSIVE is a transitional setting that accepts both plaintext and mTLS connections, allowing workloads to gradually adopt mutual TLS without breaking existing traffic. While it enables mTLS when supported by the client, it does not enforce it, so unauthenticated plaintext traffic remains permitted. Therefore, it cannot guarantee that all pod communication is encrypted and authenticated, making it unsuitable for a strict security requirement.
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.