KCNA Cloud Native Architecture — Timed 25 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?

25 minute time limit — choose an answer to begin.

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 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 3

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 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

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 6

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 7

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 8

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 cooldown period of 3 minutes prevents scaling during the short peak duration.. The HPA cooldown period of 3 minutes prevents scaling during short peak durations. The scenario states 'intermittent slowdowns during peak traffic,' implying the high CPU usage is not sustained long enough to trigger a scale-up event. After a previous scale operation (possibly due to an earlier peak), the cooldown period must elapse before the HPA can initiate another scaling action. Since the peaks are short and intermittent, they may fall within the cooldown window, preventing the HPA from scaling despite high CPU usage.

Answer

The HPA is configured to use a different metric (e.g., memory) instead of CPU.

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 9

An application experiences intermittent failures when calling an external API. Which resilience pattern should be implemented to handle transient faults?

Accepted Answer

Retry. (Retry) is correct because intermittent failures when calling an external API are typically transient faults (e.g., network glitches, temporary service unavailability). The Retry pattern automatically reattempts the failed operation a configured number of times, often with exponential backoff, to overcome these short-lived issues without changing the application's overall architecture. This directly addresses the scenario's requirement to handle transient faults.

Answer

Bulkhead

Answer

Circuit breaker

Answer

Timeout

Question 10

Which CNCF project is commonly used for Infrastructure as Code to provision cloud resources?

Accepted Answer

Crossplane. Crossplane is a CNCF project that extends the Kubernetes API to provision and manage cloud infrastructure declaratively — Infrastructure as Code using Kubernetes-style manifests and controllers. Terraform is the better-known IaC tool but is a HashiCorp product, not a CNCF project, which is exactly the distinction this question tests. Envoy is a service proxy, Prometheus is a monitoring system, and CoreDNS is a DNS server — all CNCF projects, but none of them do infrastructure provisioning.

Answer

Envoy

Answer

Prometheus

Answer

CoreDNS

Question 11

Which GitOps tool is a CNCF graduated project that synchronizes Kubernetes clusters with a Git repository?

Accepted Answer

Argo CD. Argo CD is a CNCF graduated project for GitOps on Kubernetes.

Answer

Tekton

Answer

Jenkins X

Answer

Flux

Question 12

Which TWO of the following are CNCF graduated projects? (Choose two.)

Accepted Answer

Helm. Helm and Kubernetes are both CNCF graduated projects. Envoy is also a graduated project, but the question requires selecting only two; Helm and Kubernetes are the correct choices as per the exam objectives.

Answer

Linkerd

Answer

Knative

Answer

Envoy

Question 13

What is the primary purpose of the CNCF (Cloud Native Computing Foundation)?

Accepted Answer

To host and nurture open-source cloud-native projects. The CNCF's primary purpose is to host and nurture open-source cloud-native projects, such as Kubernetes, Prometheus, and Envoy, by providing governance, community support, and a neutral home for their development. It does not provide cloud infrastructure services itself, nor does it develop proprietary technologies; instead, it fosters an ecosystem of interoperable, vendor-neutral projects. The CNCF also manages the Cloud Native Landscape and defines standards like the Open Container Initiative (OCI) for container runtimes and images, but its scope extends far beyond just standardizing container runtimes.

Answer

To provide cloud infrastructure services

Answer

To develop proprietary cloud technologies

Answer

To standardize container runtimes only

Question 14

Which of the following is a core principle of cloud native architecture as defined by the CNCF?

Accepted Answer

Microservices. Microservices is a core principle of cloud native architecture as defined by the CNCF. The CNCF's definition emphasizes that cloud native technologies empower organizations to build and run scalable applications in dynamic environments such as public, private, and hybrid clouds. Microservices architecture, where applications are composed of loosely coupled, independently deployable services, is fundamental to achieving scalability, resilience, and agility. This aligns with the CNCF's focus on containers, service meshes, and orchestration.

Answer

Monolithic design

Answer

Single point of failure

Answer

Manual scaling

Question 15

Which of the following is a graduated CNCF project?

Accepted Answer

Prometheus. Prometheus is a graduated CNCF project (graduated August 2018, the second project ever to graduate after Kubernetes). Backstage, Flux, and ArgoCD are CNCF projects at lower maturity levels in this context — the question tests knowledge of the CNCF project maturity ladder: sandbox, incubating, graduated.

Answer

Flux

Answer

Backstage

Answer

ArgoCD

Question 16

Which service mesh provides built-in support for multi-cluster and multi-cloud deployments?

Accepted Answer

Istio. Istio is correct because it provides native support for multi-cluster and multi-cloud deployments through its mesh federation capabilities, including features like multi-primary and primary-remote cluster models, as well as east-west gateways for cross-cluster traffic. It leverages Envoy proxies and a unified control plane to enable service discovery, traffic management, and security across clusters, making it the only option among the listed that offers built-in, production-ready multi-cluster support.

Answer

Kuma

Answer

Consul Connect

Answer

Linkerd

Question 17

Which CNCF project is primarily focused on providing a unified way to define and manage cloud-native applications using declarative configuration stored in Git?

Accepted Answer

ArgoCD. ArgoCD is a CNCF project that implements GitOps: it watches Git repositories containing declarative Kubernetes manifests and continuously reconciles the cluster state to match the desired state in Git. It is the canonical answer for 'declarative configuration stored in Git' in the cloud-native ecosystem.

Answer

Helm

Answer

Prometheus

Answer

Envoy

Question 18

A development team wants to deploy a serverless function that scales to zero when not in use. Which CNCF project or platform is BEST suited for this requirement?

Accepted Answer

Knative. Knative is a CNCF project that provides serverless primitives on top of Kubernetes, including scale-to-zero for workloads with no traffic. Its Serving component automatically scales pods down to zero when idle and spins them back up on demand, satisfying the requirement while remaining vendor-neutral and Kubernetes-native. This makes it the best fit among the listed CNCF-aligned options.

Answer

Kubeless

Answer

AWS Lambda

Answer

OpenFaaS

Question 19

Which of the following is a resiliency pattern that limits the number of concurrent requests to a service to prevent overload?

Accepted Answer

Bulkhead. Bulkhead isolates resources into pools (e.g., thread pools) so that a failure in one pool does not cascade. Circuit breaker stops calls after failures, retry repeats failed calls, and timeout limits wait time.

Answer

Retry

Answer

Timeout

Answer

Circuit breaker

Question 20

A team wants to implement Infrastructure as Code (IaC) for managing Kubernetes resources. Which tool is BEST suited for this purpose?

Accepted Answer

Terraform. Terraform is an Infrastructure as Code (IaC) tool that allows you to define and manage Kubernetes resources declaratively using HCL. It is cloud-agnostic and supports Kubernetes provider for managing clusters, pods, services, etc. While Pulumi also provides IaC capabilities, Terraform is more widely adopted for managing Kubernetes infrastructure. Helm, on the other hand, is a package manager for deploying pre-packaged applications, not an IaC tool.

Answer

Pulumi

Answer

Ansible

Answer

Helm