Courseiva

KCNA Cloud Native Architecture Practice Question

Which TWO practices are recommended for designing cloud-native microservices? (Choose 2)

⚠ Common exam trap

Test-takers frequently confuse 'configuration in environment variables' (which is acceptable when injected at runtime) with 'storing configuration inside the container image' (which is an anti-pattern), leading them to incorrectly select Option B.

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

✓

Implement health check endpoints for each service.

Option C is correct because cloud-native microservices must expose health check endpoints (e.g., HTTP /health or /ready probes) so orchestrators like Kubernetes can perform liveness and readiness checks and automatically restart or route traffic away from unhealthy instances. Option E is correct because designing services around business capabilities (domain-driven design bounded contexts) yields loosely coupled, independently deployable services that align with team ownership and scale autonomously. Option A is wrong because sharing a common database schema creates tight coupling and a single point of failure, contradicting the decentralized data management principle of microservices. Option B is wrong because configuration should be externalized (e.g., ConfigMaps, environment variables injected at runtime, or a config server) rather than baked into the container image, which harms portability and requires rebuilds for config changes. Option D is wrong because using synchronous HTTP calls for all inter-service communication increases latency and cascading failures; asynchronous messaging and other patterns are recommended where appropriate.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Share a common database schema across all services.

    Why it's wrong here

    Sharing a common database schema couples services through shared tables, so a schema change by one service breaks others and blocks independent deployment. It is tempting because a single shared database is the standard choice for a monolithic application, where all modules deploy together and transactional consistency across tables is required.

  • ✗

    Store configuration in environment variables inside the container image.

    Why it's wrong here

    Baking configuration into the image means every environment change demands a rebuild and redeploy, and the same artefact cannot be promoted across stages. Environment variables are the right mechanism when injected at runtime by the orchestrator, keeping one immutable image. The failure is their placement inside the image, not the use of variables themselves.

  • ✓

    Implement health check endpoints for each service.

    Why this is correct

    Health check endpoints let orchestrators such as Kubernetes detect unhealthy instances and restart or remove them from load balancing, directly satisfying the stem's resilience and self-healing requirement. Each microservice exposes liveness and readiness probes, enabling automated recovery without manual intervention, which is fundamental to cloud-native design.

  • ✗

    Use synchronous HTTP calls for all inter-service communication.

    Why it's wrong here

    Synchronous HTTP couples services tightly: a slow or failed dependency blocks the caller, defeating the resilience and independent deployability microservices require. HTTP request/response suits external APIs or simple read paths where immediate answers are needed. Cloud-native practice favours asynchronous messaging between services to decouple availability and absorb load.

  • ✓

    Design services around business capabilities.

    Why this is correct

    Designing services around business capabilities satisfies the loose-coupling constraint by aligning each microservice with a bounded context, so teams own a cohesive domain end to end. This limits cross-service dependencies and coordinated releases, letting services evolve and scale independently, which is precisely what cloud-native microservice design demands.

About these practice questions

Courseiva writes every KCNA question from scratch — 930 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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

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.