CCSP Cloud Application Security Practice Question
A company deploys microservices in Kubernetes. Each service communicates via gRPC with mutual TLS. A security assessment reveals that some services use self-signed certificates. What is the primary risk?
⚠ Common exam trap
ISC2 often tests the misconception that self-signed certificates are only a problem for revocation or key exposure, when the core issue is the lack of trusted identity verification enabling MITM attacks.
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
✓
Man-in-the-middle (MITM) attacks between services
The primary risk of using self-signed certificates in a gRPC mutual TLS environment is that there is no trusted Certificate Authority (CA) to verify the identity of the communicating services. Without proper CA-signed certificates, an attacker can easily perform a man-in-the-middle (MITM) attack by presenting a forged self-signed certificate, intercepting and modifying gRPC traffic between microservices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Inability to revoke certificates
Why it's wrong here
Self-signed certificates can still be revoked, so revocation is not the primary risk; the real issue is that no trusted CA validates identity, permitting impersonation. Revocation matters when a compromised certificate must be invalidated within a managed PKI hierarchy.
- ✗
Exposure of private keys in the container image
Why it's wrong here
Self-signed certificates do not inherently expose private keys; keys reside in the container regardless of signer. The genuine risk is absent CA trust, so any service can present a self-signed certificate and be accepted, defeating mutual TLS authentication.
- ✗
Increased latency due to certificate validation
Why it's wrong here
Certificate validation overhead is negligible and unrelated to whether certificates are self-signed; the actual risk is unverified service identity enabling impersonation. Latency concerns arise from handshake frequency or cipher choice, not from the signing authority.
- ✓
Man-in-the-middle (MITM) attacks between services
Why this is correct
Self-signed certificates lack a trusted certificate authority, so services cannot reliably verify each other's identity during the mutual TLS handshake. An attacker positioned between pods could present their own self-signed certificate and impersonate a legitimate service, intercepting gRPC traffic. This directly enables man-in-the-middle attacks, satisfying the scenario's mutual authentication requirement.
Go deeper
Related to this question
About these practice questions
This CCSP question is part of Courseiva's 934-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 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.