KCNA Cloud Native Architecture Practice Question
A platform team is adopting cloud-native principles for a new microservices application. They want to ensure that each service can be independently deployed and scaled without affecting other services. Which design principle BEST supports this goal?
⚠ Common exam trap
The trap here is assuming that any form of communication or shared resource is acceptable as long as services are separate processes, when in fact coupling at the data or orchestration layer can still prevent independent deployment and scaling.
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
✓
Loose coupling between services
Loose coupling is fundamental to cloud-native architecture because it allows each microservice to evolve, deploy, and scale independently. When services communicate through stable, well-defined interfaces and avoid shared state, teams can release changes without coordinating across the entire system. This autonomy is essential for rapid iteration and resilience in distributed environments.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Shared monolithic database for all services
Why it's wrong here
A shared monolithic database creates tight coupling at the data layer because schema changes or performance issues in one service can impact all others. It prevents independent deployment since services must coordinate database migrations. This contradicts the goal of independent scaling and deployment, and is generally discouraged in cloud-native microservices design.
- ✗
Centralized orchestration of all service workflows
Why it's wrong here
Centralized orchestration introduces a single point of control that must be updated whenever service interactions change, creating tight coupling and reducing autonomy. It also becomes a bottleneck and potential single point of failure. This approach conflicts with the decentralized, independently deployable nature of cloud-native microservices.
- ✗
Synchronous request-response communication only
Why it's wrong here
Restricting communication to synchronous request-response increases temporal coupling: if a downstream service is unavailable, the caller may fail or block. This reduces resilience and independence. While synchronous calls are sometimes necessary, mandating them as the only pattern does not support independent deployment and scaling, especially under failure conditions.
- ✓
Loose coupling between services
Why this is correct
Loose coupling allows services to interact through well-defined interfaces without tight dependencies, so changes or scaling of one service do not require coordinated changes in others. This directly enables independent deployment and scaling, which is a core cloud-native principle. Tight coupling would force teams to release services together and scale them in lockstep, defeating the goal.
Visual reference
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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 CNCF exam blueprint
This KCNA 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 KCNA exam.