mediumMultiple Choice
CCSP Practice Question: A developer is designing a microservices-based…
A developer is designing a microservices-based application in the cloud. They need to ensure communication between services is loosely coupled and resilient to failures. Which design pattern should they implement?
⚠ Common exam trap
ISC2 often tests the distinction between patterns that manage communication (like service mesh) versus patterns that decouple communication (like event-driven messaging), and the trap here is that candidates confuse a service mesh's ability to handle retries and circuit breakers with the fundamental loose coupling provided by asynchronous event-driven architectures.
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
✓
Event-driven messaging
Event-driven messaging (B) is correct because it enables asynchronous, decoupled communication between microservices, allowing them to operate independently and remain resilient to failures. When a service publishes an event, other services consume it at their own pace, preventing cascading failures and ensuring the system can handle partial outages without blocking. This pattern directly supports loose coupling and fault tolerance, which are critical for cloud-based microservices architectures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
API gateway
Why it's wrong here
An API gateway routes and mediates client-to-service requests but does not provide service-to-service resilience or decoupling; it centralises ingress rather than inter-service communication. It is tempting because it decouples clients from backends, yet asynchronous messaging or a service mesh addresses the resilience requirement.
- ✓
Event-driven messaging
Why this is correct
Event-driven messaging decouples producers from consumers via an intermediary broker, so a failing or slow service does not block callers; messages queue and retry. This satisfies the loose-coupling and failure-resilience requirements better than synchronous request-response calls between microservices.
- ✗
Service mesh
Why it's wrong here
A service mesh handles service-to-service traffic with retries, timeouts and circuit breaking, but it operates at the infrastructure layer and does not itself decouple services logically. It is tempting because it improves resilience, yet asynchronous messaging patterns deliver the loose coupling the scenario demands.
- ✗
Database per service
Why it's wrong here
Database per service isolates each microservice's persistent data, giving independent schema evolution and failure containment, but it provides no inter-service communication mechanism. It is tempting because it solves data coupling in microservices architectures; it would be correct when the requirement is decentralised data ownership rather than resilient service-to-service messaging.
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.