KCNA Cloud Native Architecture Practice Test 2 — 15 Questions

Question 1

A startup is designing a cloud-native application that processes IoT sensor data. The data arrives in bursts, and processing must be fault-tolerant with exactly-once semantics. The team considers Apache Kafka, RabbitMQ, and Amazon SQS. Which choice best meets the requirements of a cloud-native architecture?

Accepted Answer

Use Apache Kafka with idempotent producers and transactional APIs.. Apache Kafka with idempotent producers and transactional APIs is the correct choice because it provides exactly-once semantics (EOS) for bursty IoT data in a cloud-native architecture. Kafka's transactional API ensures atomic writes across partitions, while idempotent producers prevent duplicate records from retries, meeting the fault-tolerance and exactly-once requirements. Kafka also scales horizontally and handles high-throughput bursts natively, aligning with cloud-native principles.

Answer

Use Amazon SQS with FIFO queues for ordering and deduplication.

Answer

Use RabbitMQ with publisher confirms and consumer acknowledgements.

Answer

Implement an HTTP endpoint that the IoT devices call directly.

Question 2

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

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.. Option B is correct because 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 4

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 5

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

Accepted Answer

Implement health check endpoints for each service.. Option C is correct because 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 6

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

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.

Question 8

The exhibit shows pod status and logs. The web pod lmn34 has restarted 3 times. What is the root cause of the liveness probe failure?

Accepted Answer

The database service is not reachable, causing the application to fail its health check.. The liveness probe failure is caused by the database service being unreachable, which prevents the application from completing its health check. When the database is down or network connectivity is lost, the application's health endpoint returns a non-200 status code, causing Kubernetes to restart the container. The 3 restarts indicate repeated probe failures, and the logs show connection errors to the database, confirming this as the root cause.

Answer

The container is hitting a memory limit and being OOMKilled.

Answer

A network policy is blocking traffic to the database.

Answer

The readiness probe is misconfigured and not allowing traffic.

Question 9

A development team is designing a new microservices application to run on a Kubernetes cluster. They want to ensure that each microservice can be developed, deployed, and scaled independently. Which cloud native architecture principle are they primarily applying?

Accepted Answer

Loose coupling. The principle of loose coupling ensures that each microservice can be developed, deployed, and scaled independently by minimizing dependencies between services. In Kubernetes, this is achieved through well-defined APIs and service boundaries, allowing teams to update or scale one service without affecting others. This directly supports the team's goal of independent lifecycle management for each microservice.

Answer

Immutable infrastructure

Answer

Statelessness

Answer

Service discovery

Question 10

You are a platform engineer at a fast-growing startup. The company runs a Kubernetes cluster with 50 worker nodes for its production microservices. Recently, the operations team has been struggling with manual configuration drift: developers SSH into nodes to install debugging tools, and some nodes have different kernel parameters or installed packages. This has caused intermittent outages when a pod is scheduled onto a non-standard node. The CTO wants a solution that ensures each node is identical, immutable, and reproducible. The cluster uses kubeadm for bootstrapping and runs on AWS EC2. Which approach best achieves the goal of immutable nodes?

Accepted Answer

Create a golden AMI using Packer with all required configurations, then use Auto Scaling groups with a launch template that references the AMI and enable instance refresh for updates.. Option C is correct because it uses a golden AMI built with Packer to create identical, immutable nodes that are reproducible via Auto Scaling groups and launch templates. This approach ensures that every EC2 instance launched has the exact same kernel parameters, packages, and configuration, eliminating configuration drift. Instance refresh allows rolling updates to the AMI without manual intervention, aligning with the goal of immutable infrastructure.

Answer

Use a configuration management tool like Ansible to enforce desired state on each node via periodic runs.

Answer

Apply Kubernetes node labels and taints to categorize nodes and prevent workloads from running on non-standard nodes.

Answer

Deploy a DaemonSet that runs a privileged container to enforce node configuration and remove debugging tools.

Question 11

Which TWO of the following are key principles of cloud native architecture?

Accepted Answer

Infrastructure automation. Infrastructure automation (B) is a key principle of cloud native architecture because it enables consistent, repeatable, and error-free provisioning and management of infrastructure through code (e.g., Terraform, AWS CloudFormation, Ansible). This aligns with the cloud native goal of reducing manual toil and enabling rapid, reliable deployments. Microservices (C) is also a core principle, as it structures applications as a collection of loosely coupled, independently deployable services that can be scaled and updated individually, which is fundamental to cloud native agility and resilience.

Answer

Immutable infrastructure

Answer

Monolithic design

Answer

Manual scaling

Question 12

A developer creates the Pod manifest shown. When the Pod runs, the liveness probe fails and the container is restarted repeatedly. What is the most likely cause?

Accepted Answer

The liveness probe port (8080) does not match the container port (80).. The liveness probe is configured to check TCP on port 8080, but the container exposes port 80 for Nginx. Since the probe will never successfully connect to port 8080, it always fails, causing the container to be restarted repeatedly. The probe must target the same port that the application is listening on.

Answer

The initialDelaySeconds of 3 is too short for Nginx to start.

Answer

The periodSeconds of 5 causes too frequent probing.

Answer

The image nginx:latest does not have a /healthz endpoint.

Question 13

Your organization runs a multi-service application on a Kubernetes cluster. Each service is deployed as a set of Pods managed by a Deployment. The application experiences intermittent slowdowns during peak traffic. Monitoring shows that the database service Pods have high CPU usage, but the HorizontalPodAutoscaler (HPA) configured for the database Deployment does not scale. The HPA is based on average CPU utilization across Pods, with target 70%. The database Deployment has resource requests and limits set: requests.cpu: 500m, limits.cpu: 1000m. During peak, CPU usage reaches 800m per Pod. The HPA has a cooldown period of 3 minutes. The cluster has ample capacity. What is the most likely reason the HPA is not scaling?

Accepted Answer

The HPA is configured to use a different metric (e.g., memory) instead of CPU.. Option A is correct because the scenario states that CPU usage reaches 800m per Pod, which is 160% of the requested 500m, well above the HPA's 70% target. If the HPA were correctly configured for CPU, it would have triggered scaling. The fact that it does not scale despite high CPU usage indicates the HPA is likely configured to use a different metric (e.g., memory or custom metrics), not CPU. This mismatch between the metric the HPA monitors and the actual resource bottleneck prevents scaling.

Answer

The HPA cooldown period of 3 minutes prevents scaling during the short peak duration.

Answer

The CPU limit of 1000m restricts the Pods from using more than 1000m, but the HPA bases scaling on requests, not limits.

Answer

The cluster does not have enough nodes to schedule additional Pods.

Question 14

Drag and drop the steps to configure a Kubernetes Service of type LoadBalancer in a cloud environment into the correct order.

Question 15

Match each Kubernetes object to its typical use case.