KCNA Cloud Native Architecture Practice Test 1 — 15 Questions

Question 1

A company wants to migrate its monolithic application to a cloud-native architecture on Kubernetes. The application currently uses a shared database and communicates via internal HTTP calls. Which design pattern should be applied first to increase resilience and enable independent scaling of components?

Accepted Answer

Use the strangler fig pattern to gradually replace monolith functionality. The strangler fig pattern is the correct first step because it allows the team to incrementally replace specific functionalities of the monolithic application with microservices without disrupting the existing system. This pattern routes requests to either the old monolith or new services, enabling gradual migration, independent scaling of extracted components, and improved resilience by isolating failures. It directly addresses the need to move from a shared-database, HTTP-calling monolith to a cloud-native architecture on Kubernetes.

Answer

Adopt CQRS pattern to separate reads and writes

Answer

Implement database-per-service pattern

Answer

Deploy a sidecar container for each service

Question 2

A cloud-native application is designed with multiple microservices that need to handle a sudden spike in traffic without manual intervention. Which Kubernetes feature best enables this?

Accepted Answer

HorizontalPodAutoscaler. The HorizontalPodAutoscaler (HPA) automatically scales the number of pod replicas in a deployment based on observed CPU/memory utilization or custom metrics. This directly addresses the need to handle a sudden traffic spike without manual intervention by adding more pod instances to distribute the load.

Answer

VerticalPodAutoscaler

Answer

Cluster Autoscaler

Answer

PodDisruptionBudget

Question 3

A team is designing a cloud-native system that must maintain high availability across multiple cloud regions. The application uses Kubernetes clusters in each region. Which approach best ensures that the system can tolerate a full region failure while minimizing complexity?

Accepted Answer

Use a global load balancer with active-passive regional failover. Option B is correct because a global load balancer with active-passive regional failover provides a straightforward way to route traffic to a healthy secondary region when the primary fails, without the complexity of multi-region Kubernetes control planes or synchronous replication. This approach leverages DNS-based or anycast routing to detect region failure and redirect traffic, ensuring high availability while keeping the operational overhead low.

Answer

Deploy a single Kubernetes cluster spanning all regions

Answer

Run active-active in all regions with synchronous data replication

Answer

Implement manual failover procedures documented in runbooks

Question 4

A microservice logs errors when connecting to the database. The logs show 'connection refused'. Which troubleshooting step should be taken first?

Accepted Answer

Verify the database Service and Endpoints in Kubernetes. The 'connection refused' error indicates that the microservice is attempting to connect to a TCP port on the database endpoint, but no process is listening there. In Kubernetes, the first step is to verify that the database Service exists and that its Endpoints object contains the correct pod IPs and port. If the Endpoints are empty or missing, the Service is not routing traffic to any healthy database pod, which directly causes the refusal. This aligns with the Kubernetes troubleshooting hierarchy: always check the Service and Endpoints before assuming application-level issues.

Answer

Scale up the microservice deployment

Answer

Restart the microservice pod

Answer

Check the logs of other microservices

Question 5

Which practice is a key principle of cloud-native architecture?

Accepted Answer

Automated CI/CD pipelines. Automated CI/CD pipelines are a key principle of cloud-native architecture because they enable rapid, reliable, and repeatable delivery of microservices. By automating build, test, and deployment stages, teams can achieve continuous integration and continuous delivery, which aligns with the cloud-native goals of agility, scalability, and resilience. This automation reduces human error and accelerates the feedback loop, essential for managing distributed systems in dynamic cloud environments.

Answer

Manual configuration management

Answer

Tight coupling of services

Answer

Preferring stateful applications over stateless

Question 6

A cloud-native application uses a service mesh (Istio) for traffic management. The team notices increased latency in inter-service communication. Which likely cause should be investigated first?

Accepted Answer

Misconfigured sidecar proxy settings. In Istio, the sidecar proxy (Envoy) intercepts all inbound and outbound traffic for the application container. Misconfigured proxy settings—such as incorrect timeouts, retry policies, or circuit breaker thresholds—can introduce significant latency by causing unnecessary retries, connection delays, or queueing. This is the most common and immediate cause of increased latency in a service mesh, as the data plane is directly in the request path.

Answer

Kubernetes Network Policies blocking traffic

Answer

Application code is not optimized for the mesh

Answer

mTLS encryption overhead

Question 7

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 8

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

Accepted Answer

Service. Option C is correct because 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 9

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 10

Which TWO statements are true about cloud-native architecture?

Accepted Answer

Infrastructure is treated as immutable. Option A is correct because microservices enable independent scaling. Option B is correct because immutable infrastructure ensures consistency. Option C is wrong because stateful components are not preferred. Option D is wrong because manual scaling is not desired. Option E is wrong because monolithic is not cloud-native.

Answer

Applications are typically monolithic for simplicity

Answer

Manual scaling is the default approach

Answer

Stateful components are preferred for performance

Question 11

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

Accepted Answer

Advanced traffic management capabilities. Option B is correct because 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 12

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

Accepted Answer

Explicitly declare and isolate dependencies. Option B is correct because 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 13

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

Accepted Answer

Packaged as lightweight containers. Option C is correct because 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 14

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. Option D is correct because 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 15

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.