CCSP Cloud Application Security Practice Question
A cloud-native application uses a microservices architecture deployed on Kubernetes. The security team wants to ensure that only authorized services can communicate with each other, and that communication is encrypted. Which Kubernetes feature should be used to meet these requirements?
⚠ Common exam trap
The trap here is assuming that Network Policies alone provide encryption, or that RBAC or Secrets can secure service communication, when they address different layers.
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
✓
Network Policies with a service mesh like Istio for mutual TLS.
Network Policies provide segmentation by allowing or denying traffic between pods based on labels and namespaces. However, they do not encrypt traffic. A service mesh like Istio adds mutual TLS (mTLS) to encrypt all service-to-service communication and can enforce fine-grained authorization policies. Using both together ensures that only authorized services communicate and that the traffic is encrypted.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Role-Based Access Control (RBAC) to restrict which services can access the Kubernetes API.
Why it's wrong here
RBAC controls access to the Kubernetes API server, not service-to-service communication. It authorizes actions like creating pods or reading secrets, but does not govern network traffic between microservices. Therefore, it does not enforce encryption or authorization for inter-service communication.
- ✗
Kubernetes Secrets to store service credentials and TLS certificates.
Why it's wrong here
Kubernetes Secrets can store sensitive data like certificates, but they do not automatically enforce encryption or authorization for service communication. Secrets are a storage mechanism; they must be integrated with other controls to achieve mTLS and access control. They alone do not meet the requirement for encrypted, authorized communication.
- ✗
Pod Security Policies to enforce security contexts and prevent privileged containers.
Why it's wrong here
Pod Security Policies (now deprecated in favor of Pod Security Standards) control pod-level security settings such as running as non-root or restricting volume types. They do not address network communication between services or encryption. Thus, they are irrelevant to the requirement of securing service-to-service traffic.
- ✓
Network Policies with a service mesh like Istio for mutual TLS.
Why this is correct
Network Policies control pod-to-pod communication at Layer 3/4, but they do not encrypt traffic. A service mesh like Istio provides mutual TLS (mTLS) for service-to-service encryption and can enforce authorization policies. Together, they ensure only authorized services communicate and that traffic is encrypted, meeting both requirements.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CCSP question from scratch — 934 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official ISC2 exam blueprint
This CCSP practice question is part of Courseiva's free ISC2 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 CCSP exam.