Courseiva
Cloud Application Security →mediumMultiple Choice

CCSP Cloud Application Security Practice Question

A company is migrating a legacy monolithic application to a cloud-native microservices architecture. The security architect is concerned about securing inter-service communication. Which of the following should be implemented to ensure mutual authentication and encryption between services?

⚠ Common exam trap

ISC2 often tests the misconception that network segmentation (VPC/security groups) alone is sufficient for securing inter-service communication, but the CCSP emphasizes that encryption and mutual authentication are required for data-in-transit security in a zero-trust model.

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 a service mesh with mutual TLS (mTLS) for all inter-service communication.

A service mesh with mutual TLS (mTLS) provides both encryption and mutual authentication for inter-service communication, ensuring that each service verifies the identity of the other before exchanging data. This is the recommended approach for cloud-native microservices because it offloads security concerns from application code and uses X.509 certificates to establish trust, aligning with zero-trust principles.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Deploy a service mesh with mutual TLS (mTLS) for all inter-service communication.

    Why this is correct

    A service mesh sidecar proxy intercepts all inter-service traffic and enforces mutual TLS, giving each service a verifiable identity certificate plus encryption in transit. This satisfies the mutual authentication and encryption requirement across the microservices architecture without altering application code.

  • ✗

    Use shared API keys embedded in each service's configuration.

    Why it's wrong here

    Shared API keys are static secrets that authenticate the caller to the service, not both parties, and they encrypt nothing in transit. They are tempting because API keys are a legitimate mechanism for authenticating clients to a public API, and would be correct where one-way client identification suffices.

  • ✗

    Implement TLS termination at the load balancer with internal certificates.

    Why it's wrong here

    Terminating TLS at the load balancer encrypts only the client-to-proxy hop; traffic behind it is plaintext and services never authenticate each other. It is tempting because edge TLS termination is standard for exposing web applications, and would be correct where only external client connections require encryption.

  • ✗

    Place all services in the same Virtual Private Cloud (VPC) and restrict ingress with security groups.

    Why it's wrong here

    Network isolation and security groups filter traffic by IP and port but provide no cryptographic identity or encryption, so mutual authentication between services is absent. It is tempting because VPC segmentation is a valid defence-in-depth control for reducing lateral movement, and would suit scenarios where network zoning alone is the requirement.

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 →

How Courseiva writes practice questions · Editorial policy

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.