KCNA Cloud Native Architecture Practice Test 2 — 15 Questions

Question 1

A team is designing a cloud-native application that requires each microservice to have its own database. This pattern is known as:

Accepted Answer

Database-per-service pattern. The Database-per-service pattern is the correct answer because it ensures each microservice owns and manages its own database, enforcing loose coupling and data encapsulation. This aligns with the cloud-native principle of decentralized data management, where services communicate only via APIs and never access each other's databases directly. It prevents tight coupling at the data layer, which is critical for independent scaling, deployment, and resilience in a microservices architecture.

Answer

Saga pattern

Answer

Shared database pattern

Answer

CQRS pattern

Question 2

Which resource in Kubernetes is used to expose a set of pods as a network service?

Accepted Answer

Service. A Service in Kubernetes provides a stable network endpoint (IP address and DNS name) to expose a set of pods, which are ephemeral and can be replaced. Services use selectors to identify target pods and load-balance traffic across them, enabling reliable communication within or outside the cluster.

Answer

Pod

Answer

Deployment

Answer

Ingress

Question 3

A cloud-native application experiences periodic timeouts when calling a downstream service. The downstream service is running in the same Kubernetes cluster. Which design pattern should be implemented to handle this gracefully?

Accepted Answer

Circuit breaker pattern. The Circuit Breaker pattern is correct because it prevents cascading failures by monitoring for failures and, once a threshold is exceeded (e.g., 5 consecutive timeouts), it opens the circuit and immediately fails fast without waiting for the downstream service. This allows the application to handle periodic timeouts gracefully by avoiding wasted resources and providing a fallback response, which is critical for cloud-native resilience in Kubernetes.

Answer

Bulkhead pattern

Answer

Retry with exponential backoff

Answer

Health check endpoint

Question 4

Which TWO statements are true about cloud-native architecture?

Accepted Answer

Infrastructure is treated as immutable. Immutable infrastructure (e.g., replacing servers rather than patching) ensures consistency and reduces configuration drift, a key cloud-native principle. Option D is correct because microservices in cloud-native architectures are designed to be independently scalable, allowing efficient resource use. Option A is wrong because cloud-native applications typically use microservices, not monolithic architectures. Option C is wrong because cloud-native environments favor automated scaling (horizontal pod autoscaling, etc.) over manual scaling. Option E is wrong because stateful components introduce complexity and are generally avoided unless necessary; stateless components are preferred for scalability and resilience.

Answer

Applications are typically monolithic for simplicity

Answer

Manual scaling is the default approach

Answer

Stateful components are preferred for performance

Question 5

Which TWO are benefits of using a service mesh in cloud-native applications?

Accepted Answer

Advanced traffic management capabilities. A service mesh provides advanced traffic management capabilities such as fine-grained routing, canary deployments, and circuit breaking through sidecar proxies (e.g., Envoy). These capabilities allow operators to control traffic flow between microservices without modifying application code, enabling resilient and observable communication patterns.

Answer

Eliminates need for application monitoring

Answer

Simplified persistent storage management

Answer

Reduced network latency

Question 6

Which THREE are core principles of the Twelve-Factor App methodology?

Accepted Answer

Explicitly declare and isolate dependencies. The Twelve-Factor App methodology mandates that dependencies must be explicitly declared and isolated via a dependency declaration manifest (e.g., Gemfile, package.json, requirements.txt) and a dependency isolation tool (e.g., Bundler, npm, pip). This ensures that the application never implicitly depends on system-wide packages, eliminating 'it works on my machine' issues and guaranteeing consistent behavior across all environments.

Answer

Store config in codebase for traceability

Answer

Tight coupling to backing services

Question 7

Which THREE are typical characteristics of a cloud-native application?

Accepted Answer

Packaged as lightweight containers. Cloud-native applications are typically packaged as lightweight containers (e.g., Docker) that encapsulate the application and its dependencies, enabling fast startup, portability, and efficient resource utilization. Containers share the host OS kernel and have minimal overhead compared to virtual machines, which aligns with the cloud-native principle of agility and scalability.

Answer

Long startup times due to heavy initialization

Answer

Vulnerable to cascading failures

Question 8

Your organization runs a cloud-native e-commerce platform on Kubernetes. The platform consists of several microservices: a frontend service, an order service, a payment service, and a shipping service. All services communicate via HTTP REST APIs. Recently, during a flash sale event, the platform experienced a cascading failure. The order service became overwhelmed with requests and started responding slowly. This caused the frontend service to time out waiting for order responses, and eventually the frontend service crashed due to exhausted thread pools. The payment and shipping services were unaffected because they are called asynchronously via a message queue. You need to redesign the system to prevent such cascading failures in the future. Which approach is the most effective?

Accepted Answer

Implement circuit breakers in the frontend service for calls to the order service. Implementing circuit breakers in the frontend service for calls to the order service prevents cascading failures by monitoring failure rates and automatically tripping the circuit when the order service becomes slow or unresponsive. This stops the frontend from exhausting its thread pools waiting for timeouts, allowing it to fail fast and return a fallback response. Circuit breakers are a proven resilience pattern in cloud-native architectures, especially for synchronous HTTP REST calls where latency spikes can propagate.

Answer

Scale up the frontend service to handle more concurrent requests

Answer

Convert all inter-service communication to synchronous calls with retries

Answer

Increase the timeout values in the frontend service configuration

Question 9

A retail company runs its e-commerce platform on Kubernetes. During a flash sale, the application experiences high latency. The team notices that the database pods are CPU-bound and the application pods are waiting on database responses. Which architectural change would best address this bottleneck?

Accepted Answer

Implement read replicas for the database and configure the application to use them for read operations.. The bottleneck is caused by the database being CPU-bound, meaning it cannot process requests fast enough. Implementing read replicas offloads read queries from the primary database, reducing its CPU load and allowing it to handle write operations more efficiently. The application can be configured to route read operations to the replicas, which directly addresses the latency caused by waiting on database responses.

Answer

Change the database service type from ClusterIP to NodePort.

Answer

Increase the number of application pod replicas.

Answer

Store database configuration in a ConfigMap to improve startup time.

Question 10

A development team is containerizing a monolithic application into microservices. Which practice aligns with cloud-native architecture principles?

Accepted Answer

Design each microservice with its own data store and communicate via APIs.. Cloud-native architecture principles advocate for decentralized data management, where each microservice owns its private data store and exposes functionality via well-defined APIs. This ensures loose coupling, independent scalability, and resilience, as services can evolve without impacting others. The pattern aligns with the Database per Service pattern, a core tenet of microservices design.

Answer

Use a shared database for all microservices to ensure data consistency.

Answer

Use JSON Web Tokens for authentication between microservices in the same cluster.

Answer

Ensure all microservices have identical resource requests and limits.

Question 11

An organization wants to adopt a cloud-native approach for its new application. Which characteristic is most important for the application to be considered cloud-native?

Accepted Answer

It is designed to be resilient, scalable, and manageable in a dynamic environment.. Cloud-native applications are fundamentally defined by their ability to operate in dynamic, distributed environments. They leverage principles like microservices, containerization, and orchestration (e.g., Kubernetes) to achieve resilience, scalability, and manageability. This characteristic is the core tenet of cloud-native architecture as defined by the CNCF, enabling the app to handle failures gracefully and scale on demand.

Answer

It stores all state in local files on the container filesystem.

Answer

It runs as a single monolithic process for simplicity.

Answer

It is deployed exclusively on on-premises infrastructure.

Question 12

A team is migrating a legacy application to Kubernetes. The application requires persistent storage and needs to maintain session affinity. Which set of Kubernetes resources should they use?

Accepted Answer

StatefulSet with a headless Service and Service with session affinity.. StatefulSet is the correct choice because it provides stable, unique network identities and persistent storage per pod, which are essential for stateful applications. A headless Service allows direct pod-to-pod communication without load balancing, while a regular Service with session affinity (using `externalTrafficPolicy: Local` or `sessionAffinity: ClientIP`) ensures client requests stick to the same pod, maintaining session state.

Answer

Deployment with a ClusterIP Service and Ingress.

Answer

Job with a LoadBalancer Service.

Answer

DaemonSet with a NodePort Service.

Question 13

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

Accepted Answer

Implement health check endpoints for each service.. Health check endpoints (e.g., /healthz or /ready) are a fundamental pattern in cloud-native microservices. They allow orchestration platforms like Kubernetes to perform liveness and readiness probes, ensuring that traffic is only routed to healthy instances and that unhealthy pods are automatically restarted. This aligns with the cloud-native principle of designing for resilience and self-healing.

Answer

Share a common database schema across all services.

Answer

Store configuration in environment variables inside the container image.

Answer

Use synchronous HTTP calls for all inter-service communication.

Question 14

Which THREE are key benefits of using a service mesh in a cloud-native architecture? (Choose 3)

Accepted Answer

Mutual TLS (mTLS) encryption between services.. A service mesh, such as Istio or Linkerd, transparently enables mutual TLS (mTLS) encryption between service sidecar proxies without requiring application code changes. This ensures all inter-service communication is encrypted and authenticated, which is a core security benefit in a zero-trust cloud-native architecture.

Answer

Persistent storage management for stateful applications.

Answer

Automatic horizontal scaling of pods.

Question 15

The exhibit shows a Deployment manifest for a frontend service. After deployment, the pods are running but the service reports that no endpoints are available. What is the most likely cause?

Accepted Answer

The readiness probe is checking /ready which is not returning a 200 OK response.. The service reports no endpoints because the readiness probe is failing. A readiness probe determines whether a pod should receive traffic; if it does not return a 200 OK on the configured path (/ready), the pod is removed from the service’s endpoint list. Since the pods are running (liveness probe passes), the most likely cause is that the /ready endpoint is not serving a successful response.

Answer

The readiness probe periodSeconds is too short, causing the probe to overload the container.

Answer

The container image nginx:1.21 does not have the /healthz endpoint.

Answer

The liveness probe is failing, causing the pod to be restarted.