CKS Minimize Microservice Vulnerabilities Practice Question
You are a Kubernetes administrator for a fintech company that runs a payment processing service in a production cluster. The service consists of multiple microservices that communicate over the network. Recently, a security audit revealed that a compromised pod could potentially send malicious requests to other services because there are no network restrictions between pods. The security team has mandated that all inter-service traffic must be encrypted and authenticated, and that only necessary traffic should be allowed. You need to implement a solution that meets these requirements with minimal changes to the application code and minimal operational overhead. Which approach should you take?
⚠ Common exam trap
Many candidates think NetworkPolicies alone satisfy the encryption requirement, but NetworkPolicies only filter traffic at L3/L4 and do not provide any encryption or authentication, which is explicitly required by the security audit.
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
✓
Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.
Deploying Istio as a service mesh with mutual TLS (mTLS) provides transparent encryption and authentication of all inter-service traffic without modifying application code. Istio's AuthorizationPolicy resources allow fine-grained, label-based access control to enforce the principle of least privilege, meeting the security mandate with minimal operational overhead through sidecar proxy injection.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Encrypt traffic by configuring TLS certificates in each pod's environment variables and updating the application code to use HTTPS.
Why it's wrong here
Putting TLS certificates in environment variables and rewriting application code to use HTTPS is far from minimal overhead. Certificate material in env vars is exposed via the pod spec and any consumer of the Kubernetes API, and it does not protect against direct pod access. This approach also only secures selected endpoints, fails to provide mutual TLS, and forces a separate deploy and key rotation for every service.
- ✗
Use Kubernetes NetworkPolicies to restrict pod-to-pod communication based on labels and namespaces, and enable TLS in each service's code.
Why it's wrong here
NetworkPolicies are not an encryption mechanism: they only filter traffic by labels, namespaces, IP, and port (L3/L4) and say nothing about the authenticity or confidentiality of the traffic they allow. Not only do they leave service data plaintext, but adding TLS in each service's code reintroduces application-level changes and fragmented certificate management, so this solution still misses the transparent mutually authenticated encryption requirement.
- ✓
Deploy Istio as a service mesh with mutual TLS enabled and configure AuthorizationPolicy resources to allow only required traffic between services.
Why this is correct
Istio injects a sidecar Envoy proxy into each pod, transparently redirecting all service traffic to enforce mutual TLS using per-pod SPIFFE identities, with no changes to application code. Combined with AuthorizationPolicy resources, it allows only explicitly permitted traffic between authenticated services, providing both encryption and fine-grained, identity-aware authorization in one consistent layer.
- ✗
Move all services to a separate overlay network using Weave Net and enforce egress rules with iptables on each node.
Why it's wrong here
Moving to a Weave Net overlay network only changes how pods are networked; it does not add encryption or authentication between pods. Enforcing egress with iptables on each node is a static, IP-based approach that is tedious to maintain in a dynamic cluster, provides no service identity, and still leaves all allowed traffic unencrypted.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.