Courseiva

CCNA Kcna Cloud Native Arch Questions

75 of 150 questions · Page 1/2 · Kcna Cloud Native Arch topic · Answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A team wants to manage their Kubernetes infrastructure using code. Which tool is specifically designed for Infrastructure as Code (IaC) and can manage Kubernetes resources?

A.Helm
B.kubectl
C.Kustomize
D.Terraform
AnswerD

Terraform is a declarative IaC tool with a Kubernetes provider that manages cluster resources as code, tracking state and planning changes. It satisfies the requirement for a purpose-built IaC tool capable of provisioning and managing Kubernetes objects.

Why this answer

Terraform is a dedicated Infrastructure as Code (IaC) tool that uses declarative configuration files (HCL) to provision and manage cloud resources, including Kubernetes clusters and their workloads. It maintains state to track resource dependencies and can orchestrate Kubernetes resources via its Kubernetes provider, making it the correct choice for managing Kubernetes infrastructure as code.

Exam trap

The trap here is that candidates confuse Helm or Kustomize as IaC tools because they manage Kubernetes resources declaratively, but they lack the infrastructure provisioning and state management capabilities that define true Infrastructure as Code.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys pre-packaged applications (charts) but is not an IaC tool; it manages releases and templates, not infrastructure state. Option B is wrong because kubectl is a command-line client for interacting with Kubernetes API directly, used for imperative or ad-hoc operations, not for declarative infrastructure provisioning or state management. Option C is wrong because Kustomize is a configuration customization tool that overlays patches on Kubernetes manifests without managing infrastructure state or provisioning resources outside of Kubernetes.

Practice this question →
2
MCQmedium

In the 12-factor app methodology, which factor describes the practice of storing configuration in environment variables?

A.Backing services
B.Config
C.Processes
D.Build, release, run
AnswerB

The Config factor requires configuration to be stored in environment variables rather than committed to code, enabling the same deployment artefact to run across environments. This separation lets operators change settings without rebuilding, exactly as the stem describes.

Why this answer

The Config factor (Factor III) of the 12-factor app methodology mandates that configuration—such as database URLs, credentials, or feature flags—be stored in environment variables. This decouples configuration from code, allowing the same build to be deployed across different environments without code changes, and prevents accidental commits of secrets to version control.

Exam trap

CNCF often tests the distinction between 'Config' and 'Backing services'—candidates mistakenly think storing database credentials in environment variables is a 'Backing services' concern, but it is actually a 'Config' concern because the credentials are configuration, not the service itself.

How to eliminate wrong answers

Option A is wrong because 'Backing services' (Factor IV) treats attached services (databases, caches, message queues) as disposable resources accessed via URL or binding, not about storing configuration. Option C is wrong because 'Processes' (Factor VI) concerns stateless execution and sharing nothing between processes, not configuration storage. Option D is wrong because 'Build, release, run' (Factor V) describes the strict separation of build, release, and run stages to ensure immutability, not the mechanism for injecting configuration.

Practice this question →
3
MCQmedium

In a service mesh architecture, which component is responsible for intercepting and managing traffic to and from a pod?

A.Sidecar proxy
B.Ingress controller
C.API gateway
D.Control plane
AnswerA

The sidecar proxy runs alongside each pod, intercepting inbound and outbound traffic at the pod level. It enforces the mesh's routing, mTLS and telemetry policies, which is why it, rather than the control plane, handles per-pod traffic management.

Why this answer

The sidecar proxy (e.g., Envoy) runs alongside each service instance and intercepts all network traffic, enabling features like traffic management and observability.

Practice this question →
4
MCQmedium

An SRE team is reviewing a stateless web tier that runs as a Deployment. They want the platform to automatically add replicas when average CPU utilization across the Pods rises above a target, and to remove replicas when load drops, without any manual intervention. Which Kubernetes resource should they configure?

A.HorizontalPodAutoscaler
B.PodDisruptionBudget
C.Cluster Autoscaler
D.VerticalPodAutoscaler
AnswerA

The HorizontalPodAutoscaler adjusts the replica count of a scalable workload such as a Deployment based on observed metrics. With the autoscaling/v2 API you can set a CPU utilization target, and the controller periodically compares the metrics-server-reported usage against that target and scales the replica count up or down within the configured minimum and maximum. This is exactly the desired automatic behaviour.

Why this answer

The HorizontalPodAutoscaler is the controller that reads metrics such as average CPU utilization and adjusts a Deployment's replica count within a min/max range. The VerticalPodAutoscaler resizes individual Pods, Cluster Autoscaler resizes the node pool, and PodDisruptionBudget only protects availability during voluntary disruptions, so none of them provide demand-driven replica scaling.

Exam trap

The trap here is confusing scaling the number of Pods with scaling the resources inside a Pod or scaling the nodes that host them.

Practice this question →
5
MCQhard

In the context of the 12-factor app methodology, which factor is addressed by storing configuration in environment variables?

A.IV. Backing Services
B.III. Config
C.II. Dependencies
D.I. Codebase
AnswerB

Storing configuration in environment variables directly implements factor III, Config, which mandates strict separation of config from code. This satisfies the stem's constraint by keeping deployment-specific values—credentials, endpoints, feature flags—outside the codebase, so the same artefact deploys unchanged across environments.

Why this answer

Factor III (Config) of the 12-factor app methodology explicitly states that configuration should be stored in environment variables, separating config from code so the same build can be deployed across environments. This allows credentials, endpoints, and environment-specific values to be injected at runtime rather than baked into the artifact.

Exam trap

KCNA often tests whether candidates can map a described practice to the correct numbered factor — the trap is confusing Config (III) with Backing Services (IV) or Dependencies (II), which all touch on externalized resources.

How to eliminate wrong answers

Option A is wrong because Factor IV (Backing Services) concerns treating databases, queues, and caches as attached resources swappable via config, not the storage mechanism for config itself. Option C is wrong because Factor II (Dependencies) is about explicitly declaring and isolating dependencies (e.g., via a manifest), not about configuration storage. Option D is wrong because Factor I (Codebase) is about maintaining a single codebase tracked in version control with many deploys, not about where configuration lives.

Practice this question →
6
MCQmedium

Which component in a service mesh architecture is responsible for handling inter-service communication on behalf of the application container?

A.Sidecar proxy
B.Control plane
C.Ingress controller
D.API gateway
AnswerA

The sidecar proxy runs alongside each application container, intercepting inbound and outbound traffic and handling service-to-service communication, mTLS, and routing. This offloads networking concerns from the application itself, which is the defining role of the sidecar in a service mesh.

Why this answer

The sidecar proxy (e.g., Envoy) intercepts all network traffic to and from the application container, providing observability, traffic management, and security.

Practice this question →
7
MCQmedium

In a service mesh architecture, what is the role of the sidecar proxy?

A.It provides persistent storage for the pod
B.It manages the lifecycle of the pod
C.It intercepts and controls network communication to and from the main container
D.It serves as the main application container
AnswerC

The sidecar proxy runs alongside the main container, transparently intercepting inbound and outbound network traffic so mesh policies for routing, mTLS, and telemetry apply without changing application code. This interception mechanism is what delivers service mesh traffic control.

Why this answer

The sidecar proxy intercepts all network traffic to/from the main container, enabling observability, traffic management, and security without modifying application code.

Practice this question →
8
MCQeasy

Which of the following best describes the purpose of the Cloud Native Computing Foundation (CNCF)?

A.To promote cloud native technologies and host open source projects
B.To define the 12-factor app methodology
C.To provide cloud infrastructure services for enterprises
D.To develop and maintain the Kubernetes project exclusively
AnswerA

The CNCF fosters adoption of containers, service meshes and related cloud native patterns by hosting graduated, incubating and sandbox projects under neutral open governance. This matches the stem's description of promoting cloud native technologies and hosting open source projects.

Why this answer

The CNCF's primary purpose is to foster the adoption of cloud native technologies by hosting and governing open source projects like Kubernetes, Prometheus, and Envoy. It provides a neutral home for these projects, ensuring they are developed collaboratively under a vendor-neutral governance model. This aligns directly with option A, which captures both the promotional and hosting roles of the foundation.

Exam trap

CNCF often tests the misconception that the CNCF is synonymous with Kubernetes alone, but the trap here is that the CNCF's scope includes a wide ecosystem of cloud native projects, not just Kubernetes.

How to eliminate wrong answers

Option B is wrong because the 12-factor app methodology was defined by Heroku engineers in 2011, not by the CNCF, and while the CNCF promotes cloud native patterns, it did not create that specific methodology. Option C is wrong because the CNCF does not provide cloud infrastructure services (e.g., compute, storage, networking) — that is the role of cloud providers like AWS, Azure, or GCP; the CNCF is a foundation that hosts projects, not a service provider. Option D is wrong because while the CNCF hosts Kubernetes, it also hosts dozens of other projects (e.g., Prometheus, Fluentd, Linkerd) and is not exclusive to Kubernetes; its mission is broader than any single project.

Practice this question →
9
MCQmedium

In an event-driven architecture, what is the role of an event broker?

A.To intermediate between event producers and consumers
B.To run event-processing logic
C.To transform events into API calls
D.To store event schemas
AnswerA

An event broker decouples producers from consumers by receiving published events and routing them to subscribed parties, satisfying the asynchronous, many-to-many delivery constraint of event-driven architecture. It intermediates without producers knowing consumer identities, enabling independent scaling and fault tolerance across services.

Why this answer

In an event-driven architecture, the event broker acts as a middleware that decouples event producers from consumers by receiving events from producers and forwarding them to interested consumers. This intermediary role ensures asynchronous communication, scalability, and fault tolerance without requiring producers and consumers to be directly aware of each other. Technologies like Apache Kafka, RabbitMQ, or cloud-native services such as AWS EventBridge exemplify this pattern.

Exam trap

CNCF often tests the misconception that the event broker performs processing or transformation, but its core role is purely intermediary—routing events without executing business logic.

How to eliminate wrong answers

Option B is wrong because running event-processing logic is the responsibility of event processors or stream processing frameworks (e.g., Apache Flink, Kafka Streams), not the event broker, which focuses on routing and delivery. Option C is wrong because transforming events into API calls is a function of an API gateway or integration layer, not the event broker; brokers handle event transport, not protocol translation. Option D is wrong because storing event schemas is typically managed by a schema registry (e.g., Confluent Schema Registry) that works alongside the broker, but the broker itself does not store schemas—it stores and forwards event data.

Practice this question →
10
Multi-Selecthard

Which THREE of the following are benefits of using a service mesh? (Choose 3.)

Select 3 answers
A.Database management
B.Security
C.Observability
D.Code compilation
E.Traffic management
AnswersB, C, E

A service mesh enforces mutual TLS between workloads, provides identity-based authentication and authorisation, and centralises policy, delivering encryption and access control without application changes. This satisfies the stem's security benefit, complementing traffic management, observability and resilience rather than replacing them.

Why this answer

A service mesh provides security benefits (B) by enforcing mutual TLS (mTLS) between workloads, issuing and rotating service identities/certificates, and applying fine-grained authorization policies without changing application code. It delivers observability (C) through sidecar proxies that automatically collect metrics (e.g., request rate, latency, error rates), distributed traces, and access logs across service-to-service calls. It also offers traffic management (E) via features such as dynamic routing, load balancing, retries, timeouts, circuit breaking, and canary or blue/green deployments.

The remaining options are unrelated: database management (A) is handled by database systems or DBaaS platforms, not a service mesh, and code compilation (D) is a build-time developer/CI activity that a service mesh does not perform.

Exam trap

CNCF often tests the misconception that a service mesh is a general-purpose tool for all infrastructure concerns, leading candidates to incorrectly select options like database management or code compilation, when in fact the service mesh is narrowly focused on network-level traffic management, security, and observability.

Practice this question →
11
MCQmedium

Which component of the Istio service mesh is responsible for certificate signing and identity management?

A.Envoy
B.Citadel
C.Mixer
D.Pilot
AnswerB

Citadel handles certificate signing and identity management in Istio, issuing SPIFFE-based workload certificates to sidecar proxies and rotating them automatically. This satisfies the stem's requirement for the mesh component responsible for certificate signing and identity management, distinct from traffic-routing components such as Pilot or Envoy.

Why this answer

Citadel is the Istio component responsible for certificate signing, key management, and identity management, issuing SPIFFE-compliant identities to workloads. It acts as the certificate authority for the mesh, enabling mutual TLS between services.

Exam trap

KCNA often tests Istio component roles, and candidates confuse the data plane (Envoy) with control plane components (Citadel, Pilot, Mixer), picking Envoy because it 'handles security' via mTLS.

How to eliminate wrong answers

Option A is wrong because Envoy is the sidecar proxy that handles data plane traffic (routing, load balancing, mTLS termination), not certificate signing. Option C is wrong because Mixer was the policy and telemetry component (deprecated in Istio 1.5+ and replaced by Envoy extensions), not the identity manager. Option D is wrong because Pilot is the control plane component that configures Envoy proxies with routing rules and service discovery, not certificate management.

Practice this question →
12
MCQmedium

Which component in a service mesh is responsible for handling traffic management, security, and observability as a sidecar proxy?

A.Pilot
B.Mixer
C.Citadel
D.Envoy
AnswerD

Envoy is the sidecar proxy deployed alongside each workload in a service mesh, intercepting inbound and outbound traffic. It enforces traffic routing, mutual TLS, and telemetry collection, satisfying the stem's requirement for a component handling management, security and observability.

Why this answer

Envoy is the sidecar proxy used in service meshes like Istio, where it handles all data plane traffic. It intercepts inbound and outbound traffic for each service instance, enforcing traffic routing, mutual TLS, and telemetry collection. Unlike control plane components, Envoy runs as a sidecar container alongside the application, making it directly responsible for the actual traffic management, security, and observability functions at runtime.

Exam trap

KCNA often tests the distinction between control plane and data plane components in a service mesh, causing candidates to confuse control plane components like Pilot, Mixer, and Citadel with the actual data plane proxy (Envoy) that handles traffic.

How to eliminate wrong answers

Option A is wrong because Pilot is a control plane component in Istio that configures Envoy proxies with routing rules and service discovery information, but it does not handle traffic itself. Option B is wrong because Mixer is a control plane component responsible for policy checks and telemetry collection, but it was deprecated in Istio 1.5 and never acted as a sidecar proxy. Option C is wrong because Citadel is a control plane component that manages certificate issuance and rotation for mutual TLS, but it does not proxy or manage traffic.

Practice this question →
13
MCQmedium

A team is designing a cloud-native application and wants to ensure that the failure of a single availability zone does not cause a full outage. They deploy the application across multiple zones and configure the orchestrator to distribute replicas evenly. Which cloud-native architecture principle does this scenario primarily demonstrate?

A.Loose coupling
B.Declarative configuration
C.Design for failure
D.Immutable infrastructure
AnswerC

Distributing replicas across multiple availability zones ensures that if one zone fails, the application continues to run. This is a direct implementation of the design-for-failure principle, which assumes components will fail and builds redundancy to maintain availability. By spreading workloads, the system tolerates zone-level outages without manual intervention.

Why this answer

The scenario describes spreading replicas across multiple availability zones so that a single zone failure does not cause a full outage. This is the essence of designing for failure, where redundancy and fault isolation are built into the architecture. While other principles like declarative configuration or loose coupling may also be present, they do not directly address surviving a zone-level failure.

Exam trap

The trap here is confusing high availability techniques with unrelated cloud-native principles such as immutable infrastructure or declarative configuration, which do not directly explain zone-failure tolerance.

Practice this question →
14
MCQeasy

Which CNCF project is classified as a 'graduated' project?

A.Linkerd
B.K3s
C.Knative
D.Backstage
AnswerA

Linkerd reached CNCF graduated status, the highest maturity tier, reflecting production adoption, security audits and a stable governance process. Other service meshes remain at incubating or sandbox level, so graduation is the axis distinguishing it here.

Why this answer

Linkerd is a CNCF graduated project, having reached that maturity level in July 2021. It is a service mesh that provides observability, security, and reliability for Kubernetes workloads. Graduated status means the project has demonstrated production adoption, a healthy contributor base, and a stable governance model.

Exam trap

KCNA often tests the distinction between CNCF maturity levels — candidates confuse incubating projects like Knative and Backstage with graduated ones, or assume any popular project is graduated.

How to eliminate wrong answers

Option B is wrong because K3s is a lightweight Kubernetes distribution that is a CNCF sandbox project (it was accepted into sandbox in 2021 and has not graduated). Option C is wrong because Knative is a CNCF incubating project, not graduated. Option D is wrong because Backstage is also a CNCF incubating project (accepted in 2022), not graduated.

Practice this question →
15
Multi-Selecthard

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

Select 3 answers
A.Long startup times due to heavy initialization
B.Vulnerable to cascading failures
C.Packaged as lightweight containers
D.Designed for horizontal scaling
E.Built using microservices architecture
AnswersC, D, E

Lightweight containers bundle the application and its dependencies into a single immutable image, so it starts consistently across any host. This satisfies the stem's cloud-native expectation of rapid, portable deployment and horizontal scaling, unlike monolithic virtual machines that carry a full guest operating system.

Why this answer

Option C is correct because cloud-native applications are typically packaged as lightweight containers (e.g., Docker images orchestrated by Kubernetes), which enables portability, fast startup, and consistent deployment across environments. Option D is correct because cloud-native design favors horizontal scaling—adding more stateless instances behind a load balancer—rather than scaling up a single large server, allowing elasticity to match demand. Option E is correct because cloud-native applications are commonly built using a microservices architecture, where loosely coupled, independently deployable services communicate over lightweight protocols such as HTTP/REST or gRPC.

Option A is not typical, since cloud-native apps aim for fast startup and rapid initialization to support scaling and resilience. Option B is not a characteristic but a risk; cloud-native patterns like circuit breakers, retries, and bulkheads are used specifically to prevent cascading failures.

Exam trap

CNCF often tests the misconception that cloud-native apps are just 'apps in the cloud' rather than specifically requiring containerization, microservices, and horizontal scaling; candidates may mistakenly associate long startup times or fragility with cloud-native, when those are anti-patterns.

Practice this question →
16
MCQhard

You are implementing an API gateway pattern for a set of microservices. Which of the following is a typical responsibility of an API gateway?

A.Managing container lifecycle and scaling
B.Directly accessing databases to serve requests
C.Storing application state and session data
D.Enforcing authentication and rate limiting
AnswerD

API gateways centralise cross-cutting concerns for microservices, including authentication, authorisation, rate limiting, and request routing. Enforcing authentication and rate limiting is a canonical gateway responsibility, offloading these tasks from individual services rather than duplicating them in each.

Why this answer

An API gateway sits in front of microservices and centralizes cross-cutting concerns such as authentication, authorization, rate limiting, request routing, and TLS termination. Enforcing authentication and rate limiting is a canonical gateway responsibility because it offloads these concerns from individual services. This lets each microservice focus on business logic while the gateway handles policy uniformly.

Exam trap

KCNA often tests the boundary between gateway responsibilities (routing, auth, rate limiting) and orchestrator responsibilities (container lifecycle, scaling), so candidates confuse the API gateway with Kubernetes control-plane functions.

How to eliminate wrong answers

Option A is wrong because container lifecycle management and scaling are the job of an orchestrator like Kubernetes (kubelet, scheduler, HPA), not an API gateway. Option B is wrong because a gateway routes requests to services; it should not directly access databases, which would break service encapsulation and the database-per-service pattern. Option C is wrong because storing application state and session data belongs to stateful stores (databases, Redis) or the services themselves — gateways are typically stateless request proxies.

Practice this question →
17
MCQhard

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?

A.Deploy a single Kubernetes cluster spanning all regions
B.Use a global load balancer with active-passive regional failover
C.Run active-active in all regions with synchronous data replication
D.Implement manual failover procedures documented in runbooks
AnswerB

A global load balancer with active-passive regional failover keeps one region serving traffic and redirects to the standby on failure, tolerating a full region outage with far less operational complexity than active-active multi-region state replication.

Why this answer

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.

Exam trap

CNCF often tests the misconception that active-active with synchronous replication is always the best for high availability, but the trap here is that it introduces unnecessary complexity and cost for most use cases, while active-passive with a global load balancer offers a simpler, production-proven alternative for tolerating region failures.

How to eliminate wrong answers

Option A is wrong because a single Kubernetes cluster spanning multiple regions introduces significant latency, network partitioning risks, and control plane complexity, as Kubernetes is not designed for跨区域 single clusters and would violate the recommended failure domain boundaries. Option C is wrong because active-active with synchronous data replication across regions adds substantial latency, cost, and complexity, and is typically unnecessary for most applications; it also requires careful handling of conflict resolution and network reliability. Option D is wrong because manual failover procedures are slow, error-prone, and cannot meet the high availability requirements of a cloud-native system that must tolerate a full region failure automatically.

Practice this question →
18
MCQhard

In Istio, which component is responsible for enforcing traffic policies and collecting telemetry data at the pod level?

A.Mixer
B.Envoy proxy
C.Pilot
D.Citadel
AnswerB

Envoy is the sidecar proxy injected into each pod, and it is the data-plane component that applies the traffic policies pushed by istiod and emits the telemetry (metrics, logs, traces) for that workload. This satisfies the pod-level enforcement and collection requirement.

Why this answer

Envoy proxy is the correct answer because in Istio, each pod is deployed with an Envoy sidecar proxy that intercepts all inbound and outbound traffic. This proxy enforces traffic policies (e.g., routing rules, fault injection, rate limiting) and collects telemetry data (e.g., metrics, logs, traces) at the pod level, sending it to the observability backends. The sidecar model ensures policy enforcement and telemetry collection happen without modifying the application code.

Exam trap

CNCF often tests the misconception that Mixer is still the primary policy enforcement and telemetry component, but the trap here is that Mixer was deprecated and removed; candidates who haven't kept up with Istio's evolution may incorrectly select Mixer (Option A) instead of recognizing that Envoy now handles both roles via in-proxy extensions.

How to eliminate wrong answers

Option A is wrong because Mixer was a separate Istio component responsible for access control and telemetry preprocessing, but it was deprecated in Istio 1.5 and removed in later versions; telemetry and policy enforcement are now handled directly by Envoy proxies via WebAssembly extensions and the Telemetry API. Option C is wrong because Pilot is the control plane component that translates high-level traffic rules into Envoy configuration (e.g., xDS APIs) and distributes them to proxies, but it does not enforce policies or collect telemetry at the pod level. Option D is wrong because Citadel is the security component that manages certificate issuance and mTLS key rotation (using SPIFFE identities), but it does not handle traffic policy enforcement or telemetry collection.

Practice this question →
19
MCQhard

In a microservices application, you want to prevent cascading failures by limiting the number of concurrent requests to a downstream service. Which resilience pattern should you implement?

A.Circuit breaker
B.Timeout pattern
C.Bulkhead pattern
D.Retry pattern
AnswerC

The bulkhead pattern isolates resources into separate pools, so each downstream service receives a bounded number of concurrent requests. When one service saturates its pool, others continue unaffected, preventing the cascading failure the stem describes. Circuit breaking and retries address different failure modes.

Why this answer

The bulkhead pattern isolates resources by limiting the number of concurrent calls to a downstream service, so that a slow or failing dependency cannot exhaust the caller's thread pool or connection pool and cause cascading failures. In microservices, bulkheads partition thread pools, connection pools, or instances per dependency (e.g., Hystrix thread pool isolation), so one degraded service only saturates its own compartment. This directly matches the requirement of limiting concurrent requests to a downstream service.

Exam trap

KCNA often tests the confusion between bulkhead (limit concurrency/isolation) and circuit breaker (stop calls after failures); candidates pick circuit breaker because both address cascading failures, but only bulkhead limits concurrent requests.

How to eliminate wrong answers

Option A is wrong because a circuit breaker trips after a failure threshold is reached and stops calls entirely; it reacts to failures rather than limiting concurrency to prevent resource exhaustion. Option B is wrong because a timeout only bounds how long a single call waits before being abandoned; it does not cap the number of concurrent in-flight requests. Option D is wrong because retry re-attempts failed calls, which actually increases load on a struggling downstream service and can worsen cascading failures.

Practice this question →
20
Matchingmedium

Match each Kubernetes object to its typical use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Ensures a copy of a pod runs on all or selected nodes

Manages stateful applications with unique network identities

Runs a finite task to completion

Runs jobs on a time-based schedule

Automatically scales pod replicas based on CPU/memory metrics

Why these pairings

Correct matches: Deployment manages stateless apps with rolling updates; StatefulSet handles stateful apps with stable identities; DaemonSet runs a pod on every node. Common confusions: mixing Deployment with DaemonSet (one per node vs. stateless management) and StatefulSet with Jobs (stateful vs. batch).

Practice this question →
21
MCQeasy

Which service mesh component is typically deployed as a sidecar proxy alongside application containers?

A.Kiali
B.Istiod
C.Prometheus
D.Envoy proxy
AnswerD

Envoy is the data-plane proxy that service meshes such as Istio inject as a sidecar container beside each application pod. It intercepts inbound and outbound traffic to enforce routing, mTLS and telemetry policies, satisfying the sidecar proxy role described.

Why this answer

Envoy proxy is the most common sidecar proxy in service meshes like Istio and Linkerd. Istiod is the control plane component, Kiali is a visualization tool, and Prometheus is a monitoring system.

Practice this question →
22
Multi-Selecthard

A company is adopting cloud-native architecture and wants to improve the resilience of its applications. Which TWO of the following are core principles of cloud-native architecture that directly contribute to resilience? (Choose two.)

Select 2 answers
A.Store all application state in a single centralized database.
B.Design for failure and automate recovery.
C.Manually scale resources based on peak load forecasts.
D.Use monolithic deployments to simplify troubleshooting.
E.Implement observability with metrics, logs, and traces.
AnswersB, E

Designing for failure means assuming that components will fail and building systems that can detect and recover from failures automatically. This principle directly enhances resilience by minimizing downtime and manual intervention. It is a fundamental tenet of cloud-native architecture, often implemented through health checks, self-healing, and chaos engineering.

Why this answer

Designing for failure and automating recovery, along with implementing observability, are core cloud-native principles that directly enhance resilience. Designing for failure ensures that systems can withstand component outages and recover automatically, while observability provides the visibility needed to detect and respond to issues. Together, they enable applications to maintain availability and performance in dynamic environments.

Exam trap

The trap here is assuming that manual scaling or centralized databases contribute to resilience, when they actually increase fragility.

Practice this question →
23
MCQmedium

What is the primary benefit of using an API gateway in a microservices architecture?

A.It provides a single entry point for client requests and handles cross-cutting concerns
B.It replaces the need for service meshes
C.It stores application state
D.It performs service-to-service communication
AnswerA

An API gateway fronts the services, so clients call one stable endpoint instead of tracking individual service addresses. It centralises cross-cutting concerns such as authentication, rate limiting, routing and TLS termination, decoupling clients from service topology.

Why this answer

An API gateway acts as a single entry point for clients, providing request routing, composition, and cross-cutting concerns like authentication and rate limiting.

Practice this question →
24
MCQmedium

A company wants to adopt a GitOps workflow for managing their Kubernetes clusters. Which two tools are specifically designed for implementing GitOps on Kubernetes?

A.Flux
B.ArgoCD
C.Terraform
D.Jenkins
E.Helm
AnswerA, B

Flux is a CNCF GitOps operator that continuously reconciles Kubernetes cluster state against a Git repository, pulling declarative manifests. It is purpose-built for Kubernetes GitOps, satisfying the stem's requirement for a tool specifically designed for that workflow.

Why this answer

Flux (A) and ArgoCD (B) are the two tools specifically designed for GitOps on Kubernetes, as both run as controllers inside the cluster and continuously reconcile the cluster's live state with the desired state declared in a Git repository. Flux watches Git repositories and applies manifests automatically, while ArgoCD provides a declarative, Git-based continuous delivery model with drift detection and sync. Terraform (C) is an infrastructure-as-code provisioning tool that applies changes on demand rather than continuously reconciling from Git, so it is not a dedicated GitOps operator.

Jenkins (D) is a general-purpose CI automation server, and Helm (E) is a Kubernetes package manager for templating and releasing manifests, neither of which implements GitOps reconciliation on its own.

Practice this question →
25
MCQmedium

In a multi-cloud scenario, an organization wants to avoid vendor lock-in by abstracting infrastructure provisioning. Which tool is specifically designed to manage infrastructure as code across multiple cloud providers?

A.Helm
B.Istio
C.Terraform
D.ArgoCD
AnswerC

Terraform uses provider plugins to translate a single HCL configuration into each cloud's native API calls, managing state across AWS, Azure and GCP. This provider abstraction lets the organisation provision identical infrastructure on multiple clouds, directly avoiding vendor lock-in.

Why this answer

Terraform is a declarative infrastructure-as-code tool that uses provider plugins to manage resources across AWS, Azure, GCP, and many other platforms from a single configuration language (HCL). Its provider model and state file make it the canonical choice for multi-cloud, vendor-neutral infrastructure provisioning. This directly addresses the requirement to avoid vendor lock-in by abstracting provisioning.

Exam trap

KCNA often tests the boundary between Kubernetes-ecosystem tools (Helm, Istio, ArgoCD) and general infrastructure-as-code tools (Terraform) — candidates pick Helm because it 'manages infrastructure' in a loose sense, missing that it only manages Kubernetes manifests.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that templates and deploys Kubernetes manifests; it manages workloads inside a cluster, not cloud infrastructure across providers. Option B is wrong because Istio is a service mesh for traffic management, mTLS, and observability between microservices; it has nothing to do with provisioning cloud infrastructure. Option D is wrong because ArgoCD is a GitOps continuous-delivery controller for Kubernetes that syncs cluster state to Git; it deploys applications, not multi-cloud infrastructure.

Practice this question →
26
Multi-Selecthard

Which THREE of the following are components of the GitOps workflow? (Choose three.)

Select 3 answers
A.A CI/CD pipeline that validates changes before merging
B.A configuration management database (CMDB)
C.A Git repository containing declarative configuration
D.A manual approval process for every change
E.An operator (e.g., ArgoCD) that syncs the cluster state with Git
AnswersA, C, E

The CI/CD pipeline validates declarative changes before they merge, enforcing review and automated testing so only verified manifests reach the Git repository. This gate satisfies the workflow's requirement that proposed configuration is checked prior to becoming the desired state the operator later reconciles.

Why this answer

GitOps relies on a Git repository as single source of truth, a CI/CD pipeline to validate changes, and an operator to sync the cluster.

Practice this question →
27
MCQhard

A team wants to deploy a multi-cloud application that uses cloud-specific services. Which pattern is most appropriate?

A.Single-cloud vendor lock-in to reduce complexity
B.Manually managing each cloud separately without automation
C.Only using serverless functions from one provider
D.Using cloud-agnostic abstractions and infrastructure as code across providers
AnswerD

Cloud-agnostic abstractions with infrastructure as code let the team provision and manage services consistently across providers, avoiding lock-in while still integrating cloud-specific services. This satisfies the multi-cloud portability constraint better than committing to one vendor's proprietary tooling.

Why this answer

Using cloud-agnostic abstractions (e.g., Kubernetes for container orchestration, Terraform for infrastructure as code) allows the team to deploy across multiple clouds while still integrating cloud-specific services via provider-agnostic interfaces or abstraction layers. This pattern reduces vendor lock-in, enables consistent deployment workflows, and supports portability without sacrificing the ability to use unique services from each cloud provider.

Exam trap

The trap here is that candidates may think 'cloud-agnostic' means avoiding all cloud-specific services, but the correct pattern allows using them through abstraction layers, not eliminating them entirely.

How to eliminate wrong answers

Option A is wrong because single-cloud vendor lock-in contradicts the requirement for a multi-cloud application; it increases dependency on one provider and reduces flexibility. Option B is wrong because manually managing each cloud separately without automation introduces high operational overhead, configuration drift, and inconsistent deployments, which is inefficient and error-prone for multi-cloud scenarios. Option C is wrong because only using serverless functions from one provider still results in vendor lock-in and does not address the need to use cloud-specific services across multiple providers in a multi-cloud architecture.

Practice this question →
28
MCQhard

In the context of resiliency patterns, which pattern is designed to prevent a cascade of failures by isolating each component so that a failure in one component does not affect others?

A.Retry
B.Circuit breaker
C.Timeout
D.Bulkhead
AnswerD

The Bulkhead pattern partitions components into isolated pools, so resource exhaustion or failure in one partition cannot consume shared capacity and cascade to others. This isolation directly satisfies the requirement to contain failures within individual components.

Why this answer

The bulkhead pattern isolates resources (e.g., thread pools, connections) so that a failure in one part of the system doesn't bring down other parts. Circuit breaker is for handling failures of external calls, not isolation.

Practice this question →
29
MCQhard

An application is deployed across multiple cloud providers (AWS and GCP) to avoid vendor lock-in. This is an example of which pattern?

A.Public cloud
B.Federated cloud
C.Hybrid cloud
D.Multi-cloud
AnswerD

Multi-cloud means deliberately using two or more distinct public cloud providers, here AWS and GCP, so workloads avoid dependence on one vendor. That directly satisfies the stated vendor lock-in avoidance constraint, distinguishing it from hybrid cloud, which pairs private infrastructure with a single public provider.

Why this answer

Multi-cloud refers to using services from multiple cloud providers simultaneously.

Practice this question →
30
Multi-Selecthard

Which TWO of the following are features of a service mesh like Istio or Linkerd? (Select 2)

Select 2 answers
A.Container image building
B.Traffic management (routing, load balancing)
C.Observability (metrics, tracing, logs)
D.Service discovery
E.Auto-scaling of services
AnswersB, C

A service mesh's data plane proxies intercept all pod-to-pod traffic, enabling dynamic routing rules, retries, and load balancing independent of application code. This satisfies the traffic management feature the question asks for, unlike a plain Kubernetes Service which offers only basic round-robin distribution.

Why this answer

Option B is correct because a service mesh like Istio or Linkerd deploys sidecar proxies (Envoy in Istio, linkerd2-proxy in Linkerd) alongside each workload to intercept east-west traffic and provide fine-grained traffic management such as HTTP/gRPC routing, retries, timeouts, circuit breaking, and load balancing. Option C is correct because these sidecars also emit telemetry — request metrics (e.g., Prometheus-scraped latency/error counters), distributed traces (via Zipkin/Jaeger/OpenTelemetry), and access logs — giving uniform observability without changing application code. Option A is not a service mesh feature; container image building is handled by tools like Docker BuildKit, Buildah, or Kaniko in a CI pipeline.

Option D, service discovery, is a related but distinct capability typically provided by the platform (Kubernetes Services/DNS, Consul) that the mesh consumes rather than being a defining feature of the mesh itself. Option E, auto-scaling, is performed by Kubernetes controllers such as the Horizontal Pod Autoscaler or KEDA, not by the service mesh data plane.

Exam trap

KCNA often tests the boundary between mesh features and Kubernetes-native features — service discovery and auto-scaling are Kubernetes capabilities, so candidates who pick them confuse 'things a mesh uses' with 'things a mesh provides'.

Practice this question →
31
MCQhard

Which of the following patterns is used to improve resilience by isolating failures to a subset of components?

A.Timeout
B.Retry
C.Circuit breaker
D.Bulkhead
AnswerD

Bulkhead partitions components into isolated pools so a failure in one pool cannot exhaust shared resources and cascade. This directly satisfies the stem's requirement to isolate failures to a subset, containing the blast radius rather than letting one fault degrade the whole system.

Why this answer

The Bulkhead pattern (D) is correct because it isolates failures by partitioning resources (e.g., thread pools, connections) into separate pools for different components or services. This prevents a failure in one component from exhausting shared resources and cascading to others, directly improving resilience by containing the blast radius.

Exam trap

CNCF often tests the distinction between patterns that prevent cascading failures (Bulkhead) versus patterns that handle transient failures (Retry/Timeout) or protect against repeated failures (Circuit Breaker), leading candidates to confuse the goal of isolation with failure detection or recovery.

How to eliminate wrong answers

Option A is wrong because Timeout is a pattern that limits the wait time for a response, preventing indefinite hangs, but it does not isolate failures to a subset of components—it only terminates slow operations. Option B is wrong because Retry is a pattern that automatically reattempts a failed operation, which can help with transient failures but does not isolate failures; in fact, it can exacerbate resource exhaustion if not combined with other patterns. Option C is wrong because Circuit Breaker is a pattern that monitors for failures and stops requests to a failing service to allow recovery, but it does not isolate failures to a subset of components—it protects callers from a failing dependency, not partition resources across components.

Practice this question →
32
Multi-Selecthard

Which TWO of the following are characteristics of serverless computing?

Select 2 answers
A.Manual server provisioning
B.Long-running processes
C.Event-driven execution
D.Auto-scaling to zero when not in use
E.Reserved capacity for predictable workloads
AnswersC, D

Event-driven execution is intrinsic to serverless platforms: functions are invoked only in response to triggers such as HTTP requests, queue messages or object storage events, with no persistent process awaiting work. This satisfies the stem's characteristic requirement, since the platform scales from zero and bills per invocation rather than per allocated server.

Why this answer

Serverless computing is event-driven and auto-scales to zero when idle. Long-running processes are not suitable, and you do not manage the underlying servers. Reserved capacity is a concept for traditional cloud.

Practice this question →
33
Multi-Selecthard

A team is evaluating whether their application qualifies as cloud-native. They want to identify characteristics that are central to cloud-native architecture rather than incidental implementation details. Which TWO of the following are core characteristics of cloud-native architecture? (Choose two.)

Select 2 answers
A.Declarative configuration and automated management
B.Manual, ticket-driven provisioning of production servers
C.Tight coupling between services to reduce network calls
D.Resilience through fault tolerance and graceful degradation
E.Vendor-specific, proprietary APIs for all internal communication
AnswersA, D

Declarative configuration expresses the desired state, and automation continuously reconciles actual state to match it. This is central to cloud-native architecture because it enables reproducible deployments, self-healing, and scalable operations. Kubernetes controllers and GitOps workflows are common examples. This characteristic directly reflects how cloud-native systems are managed rather than an incidental detail.

Why this answer

Declarative configuration with automated management and resilience through fault tolerance and graceful degradation are core cloud-native characteristics. They shape how systems are defined, reconciled, and kept running under failure. Manual provisioning, tight coupling, and exclusive reliance on proprietary APIs work against portability, automation, and independent operation, so they are not central characteristics of cloud-native architecture.

Exam trap

The trap here is selecting operational conveniences or performance optimizations, such as reducing network calls through tight coupling, instead of the architectural principles that define cloud-native systems.

Practice this question →
34
MCQmedium

In GitOps, what is the role of a tool like ArgoCD?

A.To automatically apply changes from a Git repository to a Kubernetes cluster
B.To monitor application performance
C.To create Docker images from source code
D.To manage container registries
AnswerA

ArgoCD continuously reconciles the desired state declared in a Git repository against the live Kubernetes cluster, applying any drift automatically. This pull-based reconciliation is the mechanism that satisfies GitOps's requirement for Git as the single source of truth.

Why this answer

ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes. It continuously monitors a Git repository that stores the desired state of applications (manifests, Helm charts, Kustomize) and compares it to the live state in the cluster. When a difference is detected, ArgoCD automatically syncs the cluster to match the Git repository, thereby applying changes.

This pull-based model ensures that Git is the single source of truth for both application and infrastructure configurations.

Exam trap

KCNA often tests the misconception that GitOps tools like ArgoCD handle the entire CI/CD pipeline, including building images or monitoring, when in fact they are strictly focused on continuous delivery by syncing Git-defined desired state to the cluster.

How to eliminate wrong answers

Option B is wrong because monitoring application performance is the domain of observability tools like Prometheus, Grafana, or Datadog, not ArgoCD. Option C is wrong because building Docker images from source code is handled by CI tools such as Jenkins, GitLab CI, or Tekton, not by ArgoCD. Option D is wrong because managing container registries (e.g., image storage, tagging, access control) is done by registry services like Harbor, Docker Hub, or cloud provider registries, not by ArgoCD.

Practice this question →
35
MCQeasy

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?

A.VerticalPodAutoscaler
B.Cluster Autoscaler
C.HorizontalPodAutoscaler
D.PodDisruptionBudget
AnswerC

HorizontalPodAutoscaler adjusts the replica count of a workload based on observed metrics such as CPU utilisation, scaling pods out during traffic spikes and in afterwards. This satisfies the stem's requirement for automatic, intervention-free handling of sudden load.

Why this answer

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.

Exam trap

CNCF often tests the distinction between scaling pods (HPA) versus scaling nodes (Cluster Autoscaler) versus scaling pod resources (VPA), and the trap here is that candidates confuse 'scaling the application' with 'scaling the cluster infrastructure'.

How to eliminate wrong answers

Option A is wrong because VerticalPodAutoscaler (VPA) adjusts resource requests and limits (CPU/memory) of existing pods, not the number of replicas, so it cannot handle a traffic spike by increasing capacity. Option B is wrong because Cluster Autoscaler adds or removes worker nodes to the cluster, not pods; it works at the infrastructure layer and does not directly scale the application itself. Option D is wrong because PodDisruptionBudget (PDB) limits the number of voluntary disruptions (e.g., node drains) to maintain availability, but it does not scale pods up or down in response to traffic changes.

Practice this question →
36
MCQmedium

An application requires external configuration that varies between environments (dev, staging, prod). Following the 12-factor app methodology, how should this configuration be provided?

A.Use environment variables
B.Store configuration in a config file that is version-controlled
C.Use a centralized database for configuration
D.Hard-code the configuration in the application code
AnswerA

Twelve-factor apps store configuration in environment variables, keeping it strictly separate from code so the same build deploys unchanged across dev, staging and prod. This satisfies the per-environment variation requirement without conditional code or committed config files.

Why this answer

The 12-factor app methodology (Factor III: Config) explicitly states that configuration should be stored in environment variables, not in code or version-controlled files. This keeps config strictly separate from code so the same build artifact can be deployed unchanged across dev, staging, and prod by simply changing environment variables.

Exam trap

KCNA often tests the misconception that version-controlled config files are 'best practice' — candidates pick B because it sounds disciplined, but 12-factor explicitly rejects config in the repo.

How to eliminate wrong answers

Option B is wrong because version-controlled config files risk leaking secrets and violate the strict separation of config from code; 12-factor explicitly warns against config files checked into the repo. Option C is wrong because a centralized config database adds a runtime dependency and is not the 12-factor recommendation — it also complicates the build-once, run-anywhere principle. Option D is wrong because hard-coding config in code makes the artifact environment-specific and requires rebuilds per environment, directly violating 12-factor.

Practice this question →
37
Multi-Selecthard

Which THREE of the following are features provided by a service mesh like Istio? (Select THREE.)

Select 3 answers
A.Container image building
B.Traffic routing and load balancing
C.Observability including metrics and distributed tracing
D.Security through mTLS and access policies
E.Database schema migrations
AnswersB, C, D

Istio's control plane configures Envoy sidecars with routing rules, retries, timeouts and load-balancing algorithms, enabling canary releases and traffic shifting. This satisfies the traffic management requirement by directing and distributing requests across service instances independently of application code.

Why this answer

Service mesh provides traffic management (routing), observability (metrics, tracing), and security (mTLS, policies).

Practice this question →
38
Multi-Selectmedium

Which TWO of the following are core principles of cloud native architecture according to the CNCF?

Select 2 answers
A.Static scaling based on predefined thresholds
B.Microservices architecture
C.Dynamic orchestration
D.Manual infrastructure management
E.Monolithic deployment
AnswersB, C

The CNCF defines microservices as a core cloud native principle: applications decompose into independently deployable, loosely coupled services communicating over well-defined APIs. This granularity enables independent scaling, deployment and failure isolation, satisfying the stem's requirement for a recognised CNCF architectural principle.

Why this answer

Options B and C are correct. Microservices architecture and dynamic orchestration are core principles of cloud native architecture according to the CNCF. Option A (static scaling) is not a core principle; cloud native emphasizes dynamic scaling.

Option D (manual infrastructure management) contradicts the principle of automation. Option E (monolithic deployment) is antithetical to the microservices principle. Thus, the correct answers are B and C.

Practice this question →
39
MCQmedium

A team is deploying a microservices application on Kubernetes. They want to ensure that each microservice can be updated independently without affecting others, and that the application can tolerate the failure of a single microservice. Which cloud-native architecture principle are they applying?

A.Monolithic architecture
B.Microservices architecture
C.Serverless architecture
D.Service mesh
AnswerB

Microservices architecture decomposes an application into small, independent services that can be developed, deployed, and scaled independently. This enables independent updates and fault isolation, as a failure in one service does not necessarily bring down the entire application. The scenario explicitly describes these characteristics, making microservices the correct principle.

Why this answer

Microservices architecture is the correct principle because it structures an application as a collection of loosely coupled services, each independently deployable and scalable. This allows teams to update one service without redeploying others, and a failure in one service can be isolated, preventing cascading failures. The scenario highlights these exact benefits, aligning with microservices principles.

Exam trap

The trap here is attributing independent updates and fault tolerance to service mesh rather than the underlying architectural style.

Practice this question →
40
MCQmedium

A development team wants to implement a GitOps workflow for their Kubernetes deployments. Which tool is specifically designed for GitOps on Kubernetes?

A.ArgoCD
B.Helm
C.Jenkins
D.Terraform
AnswerA

ArgoCD is purpose-built for GitOps on Kubernetes, continuously reconciling cluster state against a Git repository as the single source of truth. It satisfies the stated GitOps workflow requirement natively, unlike generic CI/CD tools that push changes without declarative drift detection.

Why this answer

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes that continuously monitors Git repositories and synchronizes the desired state with the cluster. It is purpose-built for GitOps workflows, automatically detecting drift and applying changes. Helm, Jenkins, and Terraform are not specifically designed for GitOps on Kubernetes.

Exam trap

KCNA often tests the misconception that Helm or Jenkins are GitOps tools, when in fact GitOps requires a dedicated continuous reconciliation controller like ArgoCD or Flux.

How to eliminate wrong answers

Option B is wrong because Helm is a package manager for Kubernetes that templates and deploys applications, but it does not provide continuous synchronization from Git. Option C is wrong because Jenkins is a general-purpose CI/CD automation server that can be scripted for GitOps but lacks native GitOps reconciliation. Option D is wrong because Terraform is an infrastructure-as-code tool for provisioning cloud resources, not for continuous Kubernetes application delivery.

Practice this question →
41
MCQeasy

What is the role of an API gateway in a microservices architecture?

A.To schedule pods on nodes
B.To store application configuration
C.To monitor container resource usage
D.To provide a single entry point for external clients to access multiple backend services
AnswerD

An API gateway routes external client requests to the appropriate backend microservices, handling cross-cutting concerns such as authentication, rate limiting and protocol translation. This provides the single entry point the stem requires, hiding internal service topology and decoupling clients from individual service addresses.

Why this answer

An API gateway acts as a single entry point for client requests, handling routing, authentication, rate limiting, and other cross-cutting concerns.

Practice this question →
42
MCQeasy

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

A.Use a shared database for all microservices to ensure data consistency.
B.Use JSON Web Tokens for authentication between microservices in the same cluster.
C.Design each microservice with its own data store and communicate via APIs.
D.Ensure all microservices have identical resource requests and limits.
AnswerC

Decentralised data ownership lets each microservice evolve its schema independently, avoiding the shared-database coupling that would reintroduce monolith-style coordination. API-based communication enforces loose coupling and independent deployability, directly satisfying the cloud-native constraint of per-service autonomy and fault isolation.

Why this answer

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.

Exam trap

CNCF often tests the misconception that 'shared data ensures consistency' (Option A) or that 'identical resource limits simplify management' (Option D), while the correct answer emphasizes data autonomy and API-based communication as the hallmark of cloud-native design.

How to eliminate wrong answers

Option A is wrong because a shared database creates tight coupling between microservices, violating the principle of bounded contexts and making independent deployments and scaling impossible; it also introduces a single point of failure and contention. Option B is wrong because JSON Web Tokens (JWTs) are used for stateless authentication between services, but within the same cluster, internal service-to-service communication should leverage mutual TLS (mTLS) or a service mesh (e.g., Istio) for stronger security, not rely on JWT alone which can be intercepted without transport encryption. Option D is wrong because requiring identical resource requests and limits for all microservices ignores the fact that different services have distinct resource profiles (e.g., CPU-intensive vs. memory-intensive), leading to inefficient cluster utilization and potential throttling or waste.

Practice this question →
43
MCQmedium

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

A.Saga pattern
B.Database-per-service pattern
C.Shared database pattern
D.CQRS pattern
AnswerB

Database-per-service gives each microservice a private datastore, accessed only through its own API. This enforces loose coupling and independent schema evolution, avoiding the shared-database integration that would couple services and undermine the autonomy the stem's design requires.

Why this answer

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.

Exam trap

CNCF often tests the misconception that the Saga pattern defines database ownership, when in fact it is a transaction coordination pattern, not a data isolation strategy.

How to eliminate wrong answers

Option A is wrong because the Saga pattern is a distributed transaction management pattern used to maintain data consistency across multiple services, not a database ownership model. Option C is wrong because the Shared database pattern contradicts the requirement for each microservice to have its own database, as it forces all services to access a single database, creating tight coupling and single points of failure. Option D is wrong because CQRS (Command Query Responsibility Segregation) is a pattern that separates read and write operations into different models or databases, but it does not define per-service database ownership.

Practice this question →
44
MCQhard

A team is designing a cloud-native system that must remain available even if an entire availability zone fails. They want to distribute workloads across multiple zones and automatically recover from failures. Which cloud-native architectural approach BEST addresses this requirement?

A.Rely on vertical scaling of a single large node
B.Store all state in a single-zone database
C.Deploy all replicas in a single zone with a load balancer
D.Use a multi-zone cluster with anti-affinity rules and health checks
AnswerD

A multi-zone cluster spreads nodes and pods across zones. Anti-affinity rules ensure replicas are not co-located, and health checks trigger rescheduling if a zone fails. This provides fault tolerance and automatic recovery, directly satisfying the requirement for availability during a zone outage.

Why this answer

Spreading workloads across multiple availability zones with anti-affinity and health checks enables the system to tolerate a zone failure. Kubernetes can reschedule pods from a failed zone onto nodes in healthy zones, maintaining service. This design is a standard cloud-native pattern for high availability.

Exam trap

The trap here is thinking that a load balancer or vertical scaling alone provides zone-level fault tolerance; without distributing replicas across zones, a single zone outage still takes down the application.

Practice this question →
45
MCQeasy

Which of the following best describes the purpose of the CNCF (Cloud Native Computing Foundation)?

A.To develop proprietary cloud native software
B.To define the 12-factor app methodology
C.To host and promote open source cloud native projects
D.To provide certification exams for Kubernetes administrators
AnswerC

The CNCF's core function is acting as a vendor-neutral home for cloud native projects such as Kubernetes, Prometheus and Envoy, providing governance, trademark and marketing support. Hosting and promoting open source cloud native projects is precisely its charter, satisfying the stem's request for its purpose.

Why this answer

The CNCF is a vendor-neutral organization under the Linux Foundation that hosts and promotes open source cloud native projects such as Kubernetes, Prometheus, and Envoy. Its core mission is to foster collaboration and standardization in the cloud native ecosystem by providing a neutral home for projects, not to develop proprietary software or create certification exams. Option C accurately captures this purpose.

Exam trap

KCNA often tests the misconception that the CNCF's primary role is certification or proprietary development, when its main function is hosting and promoting open source projects.

How to eliminate wrong answers

Option A is wrong because the CNCF does not develop proprietary software; it supports open source projects. Option B is wrong because the 12-factor app methodology was created by Heroku engineers and is not a CNCF initiative. Option D is wrong because while the CNCF offers certifications like CKA and CKAD, that is not its primary purpose; its main role is hosting and promoting open source projects.

Practice this question →
46
MCQhard

A cloud-native application experiences intermittent failures when calling an external API. The team implements a pattern that allows the application to temporarily stop calling the failing API and serve stale data or a fallback response. Which resiliency pattern does this describe?

A.Circuit Breaker pattern
B.Retry pattern
C.Bulkhead pattern
D.Timeout pattern
AnswerA

The circuit breaker monitors calls to the external API and, once failures cross a threshold, trips open to stop further calls, immediately returning a fallback or stale response. After a cool-down it half-opens to test recovery, matching the requirement to temporarily halt calls and serve fallback data.

Why this answer

The Circuit Breaker pattern wraps calls to a remote dependency and trips 'open' after a threshold of failures, immediately returning a fallback (stale data, cached response, or default) instead of continuing to hammer the failing API. This prevents cascading failures and gives the downstream service time to recover, while periodically probing in a 'half-open' state to test restoration. Serving stale data while the breaker is open is the classic implementation of this pattern in cloud-native apps.

Exam trap

KCNA often tests the distinction between resiliency patterns that stop traffic (Circuit Breaker) versus those that merely retry, isolate, or bound calls (Retry, Bulkhead, Timeout) — candidates confuse 'handling failure' with 'stopping calls and serving fallback'.

How to eliminate wrong answers

Option B is wrong because the Retry pattern re-attempts the same call (often with backoff) and does not stop calling the failing API or serve fallback data — it actually increases load on a struggling dependency. Option C is wrong because the Bulkhead pattern isolates resources (thread pools, connection pools) per dependency so one failure cannot exhaust shared resources; it does not provide fallback responses. Option D is wrong because the Timeout pattern only bounds how long a caller waits for a response before giving up — it does not stop calls or return stale/fallback data.

Practice this question →
47
MCQeasy

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

A.Monolithic application design
B.Manual scaling of applications
C.Static infrastructure provisioning
D.Microservices packaged in containers
AnswerD

Microservices packaged in containers is a CNCF cloud native principle: loosely coupled services, each in its own container, deployed and scaled independently. This enables resilience, portability and automated orchestration, distinguishing cloud native design from monolithic deployment.

Why this answer

The CNCF defines cloud native as an approach that uses containers, service meshes, microservices, immutable infrastructure, and declarative APIs to build loosely coupled systems that are resilient, manageable, and observable. Microservices packaged in containers is the foundational pattern: each service is independently deployable, scalable, and isolated, which enables the automation and orchestration (e.g., Kubernetes) that cloud native relies on.

Exam trap

KCNA often tests the misconception that cloud native is just 'running in the cloud' — candidates may pick static infrastructure or manual scaling because they associate cloud with VMs, missing that cloud native specifically means containers, microservices, and automation.

How to eliminate wrong answers

Option A is wrong because monolithic application design is the opposite of cloud native — monoliths are tightly coupled, hard to scale independently, and slow to deploy, which contradicts CNCF's loosely coupled microservices principle. Option B is wrong because manual scaling is antithetical to cloud native, which emphasizes automated, declarative scaling (e.g., Horizontal Pod Autoscaler) driven by metrics. Option C is wrong because static infrastructure provisioning (manual, long-lived servers) conflicts with cloud native's immutable, declarative, and often ephemeral infrastructure model managed via IaC.

Practice this question →
48
MCQeasy

Which GitOps tool is specifically designed for Kubernetes and follows the declarative GitOps pattern, continuously reconciling the desired state from a Git repository?

A.ArgoCD
B.Helm
C.Terraform
D.Jenkins
AnswerA

ArgoCD runs in-cluster as a Kubernetes controller, continuously comparing live manifests against the Git repository and reconciling drift automatically. This satisfies the stem's requirement for a Kubernetes-native tool following the declarative GitOps pattern, unlike push-based CI pipelines or general-purpose configuration management tools.

Why this answer

ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes that syncs application state with a Git repository.

Practice this question →
49
Multi-Selectmedium

Which TWO of the following are key characteristics of cloud-native applications? (Select two.)

Select 2 answers
A.Monolithic architecture
B.Microservices architecture
C.Containerized deployment
D.Manual scaling
E.Long-lived virtual machines
AnswersB, C

Microservices architecture decomposes an application into independently deployable services, each owning its own data and lifecycle. This satisfies the stem's characteristic criterion by enabling independent scaling, fault isolation, and rapid iteration, which monolithic designs cannot match.

Why this answer

Option B is correct because cloud-native applications are built as microservices architecture, decomposing functionality into small, independently deployable services that communicate over lightweight APIs (e.g., REST/gRPC), enabling independent scaling and resilience. Option C is correct because cloud-native apps are typically packaged and deployed in containers (e.g., Docker images orchestrated by Kubernetes), which provide portability, immutable artifacts, and fast, consistent deployment across environments. Option A is incorrect because monolithic architecture is the opposite of the loosely coupled, independently deployable services that characterize cloud-native design.

Option D is incorrect because cloud-native applications rely on automated/elastic scaling (e.g., Horizontal Pod Autoscaler, auto-scaling groups) rather than manual scaling. Option E is incorrect because long-lived virtual machines reflect traditional, pet-style infrastructure, whereas cloud-native workloads favor ephemeral, disposable instances and containers managed declaratively.

Exam trap

KCNA often tests the misconception that 'cloud-native' simply means 'running in the cloud', tricking candidates into selecting options like long-lived VMs or manual scaling that describe traditional cloud-hosted rather than cloud-native architectures.

Practice this question →
50
Multi-Selectmedium

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

Select 3 answers
A.Store config in codebase for traceability
B.Explicitly declare and isolate dependencies
C.Tight coupling to backing services
D.Treat logs as event streams
E.One codebase tracked in revision control, many deploys
AnswersB, D, E

Twelve-Factor's dependency principle requires applications to declare all dependencies explicitly in a manifest and isolate them from the host, never relying on implicit system-wide packages. This guarantees reproducible builds and prevents version drift between development and production environments.

Why this answer

Option B is correct because Factor II (Dependencies) requires an app to explicitly declare all dependencies via a manifest such as requirements.txt, package.json, or Gemfile, and isolate them using tooling like virtualenv or Bundler so no implicit system-wide packages are assumed. Option D is correct because Factor XI (Logs) states an app should never manage log files itself; instead it writes unbuffered event streams to stdout/stderr, letting the execution environment aggregate and route them. Option E is correct because Factor I (Codebase) mandates exactly one codebase tracked in a version control system such as Git, with many deploys from that same codebase across environments.

Option A is wrong because Factor III (Config) requires config to be stored in the environment, not in the codebase, precisely to keep credentials and environment-specific values out of revision control. Option C is wrong because the methodology calls for loosely coupled, interchangeable backing services (Factor IV), attached and detached via config, not tight coupling.

Exam trap

CNCF often tests the misconception that storing configuration in the codebase provides traceability, but the Twelve-Factor App explicitly forbids this to maintain strict separation of config from code and avoid accidental exposure of secrets.

Practice this question →
51
MCQmedium

What is the primary function of a service mesh like Istio?

A.To build container images
B.To handle inter-service communication with features like traffic control and security
C.To manage container orchestration
D.To provide persistent storage for stateful applications
AnswerB

Istio provides a dedicated infrastructure layer that intercepts all service-to-service traffic via sidecar proxies, delivering traffic routing, mutual TLS, and policy enforcement. This directly satisfies the stem's requirement for managing inter-service communication rather than merely deploying or monitoring individual services.

Why this answer

A service mesh provides observability, traffic management, and security for microservices communication.

Practice this question →
52
MCQeasy

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?

A.It stores all state in local files on the container filesystem.
B.It is designed to be resilient, scalable, and manageable in a dynamic environment.
C.It runs as a single monolithic process for simplicity.
D.It is deployed exclusively on on-premises infrastructure.
AnswerB

Resilience, scalability and manageability in a dynamic environment define cloud-native design, satisfying the stem's demand for a cloud-native approach rather than mere cloud hosting. Unlike lift-and-shift workloads, such applications tolerate node failure, scale horizontally, and are orchestrated declaratively, aligning with CNCF principles and Kubernetes-based platforms.

Why this answer

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.

Exam trap

CNCF often tests the misconception that cloud-native simply means 'running in containers' or 'using Kubernetes,' but the defining characteristic is the architectural property of being resilient, scalable, and manageable in a dynamic environment, not the deployment technology itself.

How to eliminate wrong answers

Option A is wrong because storing state in local container filesystems violates the cloud-native principle of statelessness; containers are ephemeral, and local state is lost on restart, making the application non-resilient and unscalable. Option C is wrong because a monolithic process contradicts the cloud-native preference for microservices, which allow independent scaling, deployment, and fault isolation; monoliths become bottlenecks in dynamic environments. Option D is wrong because cloud-native applications are designed to be infrastructure-agnostic and typically run in multi-cloud or hybrid environments, not exclusively on-premises; being tied to on-premises infrastructure limits portability and cloud benefits.

Practice this question →
53
Multi-Selecthard

Which THREE of the following are benefits of using an event-driven architecture? (Choose three.)

Select 3 answers
A.Simpler debugging and tracing
B.Better resilience through decoupled components
C.Improved scalability through asynchronous processing
D.Reduced need for monitoring
E.Loose coupling between services
AnswersB, C, E

Because producers publish to a broker rather than calling consumers directly, a failed consumer does not cascade failure upstream; events queue until recovery. This decoupling delivers the resilience benefit the stem asks for, unlike tightly coupled synchronous invocation.

Why this answer

Option B is correct because event-driven architecture decouples producers from consumers, so if one component fails or is slow, others can continue operating and events can be buffered or retried, improving overall resilience. Option C is correct because asynchronous processing lets events be queued and consumed independently, allowing components to scale out horizontally based on event volume rather than being blocked by synchronous calls. Option E is correct because services communicate through events via a broker or event bus rather than direct point-to-point calls, which reduces dependencies and enforces loose coupling between services.

Option A is not correct because event-driven systems typically make debugging and tracing harder, since flows span multiple asynchronous hops and require correlation IDs and distributed tracing. Option D is not correct because event-driven architectures still require robust monitoring, observability, and alerting to track event flows, broker health, and consumer lag.

Exam trap

KCNA often tests the misconception that event-driven architectures simplify operations; in reality they trade synchronous simplicity for asynchronous complexity, so 'simpler debugging' and 'reduced monitoring' are always wrong.

Practice this question →
54
MCQmedium

Which of the following is a key principle of the 12-factor app methodology?

A.Treat logs as event streams
B.Bind services at build time
C.Use local disk storage for persistence
D.Store configuration in the codebase
AnswerA

Treating logs as event streams satisfies the 12-factor requirement that an app never concern itself with routing or storage of its output. Each running process writes its event stream unbuffered to stdout, letting the execution environment capture, aggregate and route those streams to files or monitoring systems.

Why this answer

The 12-factor app includes the principle of treating logs as event streams, not as files.

Practice this question →
55
MCQhard

Which of the following is a benefit of using an API gateway pattern?

A.It reduces the number of microservices needed
B.It replaces the need for a service mesh
C.It provides a single entry point for clients and handles cross-cutting concerns
D.It stores application state
AnswerC

An API gateway consolidates disparate backend services behind one client-facing endpoint, so callers avoid coupling to individual service addresses. It also centralises cross-cutting concerns such as authentication, rate limiting, TLS termination and request routing, satisfying the stem's requirement for a single entry point that offloads duplicated logic from every service.

Why this answer

An API gateway sits in front of microservices and provides a single, unified entry point for all external clients, while centralizing cross-cutting concerns such as authentication, rate limiting, TLS termination, request routing, and logging. This decouples clients from the internal service topology, so services can be refactored or scaled without changing client code. It is a traffic-management and policy-enforcement layer, not a compute or storage layer.

Exam trap

KCNA often tests the misconception that an API gateway and a service mesh are interchangeable — candidates must distinguish north-south (gateway) from east-west (mesh) traffic.

How to eliminate wrong answers

Option A is wrong because an API gateway does not reduce the number of microservices — it aggregates and routes to them; the number of services is determined by domain decomposition, not by the gateway. Option B is wrong because a service mesh handles east-west (service-to-service) traffic inside the cluster, whereas an API gateway handles north-south (client-to-service) traffic; they are complementary, not replacements. Option D is wrong because API gateways are stateless proxies — they do not store application state, which belongs in databases or stateful services.

Practice this question →
56
MCQhard

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?

A.Kubernetes Network Policies blocking traffic
B.Misconfigured sidecar proxy settings
C.Application code is not optimized for the mesh
D.mTLS encryption overhead
AnswerB

Each Istio sidecar proxies every inbound and outbound request, so an incorrect proxy setting—such as a misconfigured concurrency limit, buffer size or timeout—directly adds per-hop latency to inter-service calls. Inspecting sidecar configuration and Envoy stats isolates this overhead before blaming the application or network.

Why this answer

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.

Exam trap

CNCF often tests the misconception that mTLS encryption is a major source of latency, but in practice its overhead is negligible compared to misconfigured proxy settings that directly impact request handling.

How to eliminate wrong answers

Option A is wrong because Kubernetes Network Policies operate at the IP/port level and would block traffic entirely rather than cause increased latency; they do not introduce gradual performance degradation. Option C is wrong because application code optimization is a separate concern—the service mesh handles traffic management at the infrastructure layer, and unoptimized code would cause latency regardless of the mesh. Option D is wrong because mTLS encryption overhead in Istio is minimal (typically under 5% latency increase) and is a known, accepted cost of zero-trust security; it would not be the first suspect for a noticeable latency spike.

Practice this question →
57
MCQmedium

A platform engineer is explaining cloud-native architecture to a new team. The team asks which statement BEST describes the relationship between microservices and cloud-native architecture. Which answer is correct?

A.Microservices are the only valid way to build cloud-native applications
B.Cloud-native architecture requires every service to share a single database
C.Microservices are one common architectural style used within cloud-native systems
D.Microservices eliminate the need for observability and monitoring
AnswerC

Microservices are a widely adopted architectural style in cloud-native systems because they support independent deployment, scaling, and fault isolation. However, cloud-native architecture also includes other styles and practices. This statement correctly describes microservices as one common approach rather than the only one, matching the broader definition of cloud-native architecture.

Why this answer

Microservices are a common architectural style within cloud-native systems, valued for independent deployability, scalability, and fault isolation. They are not the only way to be cloud-native, and they do not remove the need for observability or decentralized data. The other statements are either too absolute or contradict established cloud-native practices, so the accurate description is that microservices are one common style.

Exam trap

The trap here is treating microservices as synonymous with cloud-native architecture, when cloud-native is a broader set of principles and practices.

Practice this question →
58
MCQmedium

What is the primary purpose of an API gateway in a microservices architecture?

A.To manage service-to-service communication within a cluster
B.To replace DNS for service discovery
C.To act as a single entry point for external clients
D.To directly connect databases to clients
AnswerC

An API gateway fronts all backend microservices, routing external requests to the appropriate service while handling cross-cutting concerns such as authentication and rate limiting. This satisfies the stem's requirement for a single entry point, hiding internal service topology from external clients.

Why this answer

The primary purpose of an API gateway in a microservices architecture is to act as a single entry point for external clients, hiding the internal service topology and centralizing concerns like routing, authentication, and rate limiting. Clients talk only to the gateway, which forwards requests to the appropriate backend microservice. This simplifies client code and allows services to evolve independently.

Exam trap

KCNA often tests the confusion between API gateway (north-south, external entry) and service mesh (east-west, internal service-to-service), causing candidates to pick the service-mesh-related option.

How to eliminate wrong answers

Option A is wrong because service-to-service communication within a cluster is the domain of a service mesh (e.g., Istio, Linkerd) or direct service discovery, not the API gateway, which handles external ingress. Option B is wrong because DNS-based service discovery (e.g., CoreDNS in Kubernetes) resolves service names to ClusterIPs; an API gateway does not replace DNS — it consumes service discovery to route traffic. Option D is wrong because directly connecting databases to clients bypasses the service layer entirely and violates microservice encapsulation; gateways route to services, not databases.

Practice this question →
59
Multi-Selectmedium

Which TWO statements are true about cloud-native architecture?

Select 2 answers
A.Applications are typically monolithic for simplicity
B.Infrastructure is treated as immutable
C.Manual scaling is the default approach
D.Services can be scaled independently
E.Stateful components are preferred for performance
AnswersB, D

Immutable infrastructure means servers are never patched or reconfigured in place; changes produce new instances that replace old ones. This eliminates configuration drift, makes deployments reproducible, and enables reliable rollback, which are core cloud-native principles.

Why this answer

Option B is correct because cloud-native architecture treats infrastructure as immutable — servers and containers are provisioned from versioned images and replaced rather than patched in place, which enables consistent, reproducible deployments and supports practices like blue/green and rolling updates. Option D is correct because cloud-native design decomposes applications into loosely coupled microservices that can each be scaled independently (e.g., via Kubernetes Horizontal Pod Autoscaler or similar orchestration), so a hot service can scale out without scaling the entire application. Option A is incorrect because cloud-native favors small, independently deployable microservices over monolithic applications.

Option C is incorrect because autoscaling driven by metrics is the default approach, not manual scaling. Option E is incorrect because cloud-native prefers stateless components with state externalized to managed data services, since statelessness improves scalability, resilience, and portability.

Exam trap

KCNA often tests the misconception that cloud-native simply means 'running in the cloud,' causing candidates to pick monolithic or manual-scaling options that describe traditional on-premises patterns.

Practice this question →
60
Multi-Selecthard

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

Select 2 answers
A.Share a common database schema across all services.
B.Store configuration in environment variables inside the container image.
C.Implement health check endpoints for each service.
D.Use synchronous HTTP calls for all inter-service communication.
E.Design services around business capabilities.
AnswersC, E

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.

Why this answer

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.

Exam trap

The trap here is that candidates often 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.

Practice this question →
61
MCQeasy

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

A.Pod
B.Deployment
C.Service
D.Ingress
AnswerC

A Service provides a stable virtual IP and DNS name, load-balancing traffic across the pods selected by its label selector. That abstraction decouples clients from ephemeral pod IPs, directly satisfying the requirement to expose a set of pods as a network service.

Why this answer

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.

Exam trap

CNCF often tests the misconception that a Deployment can expose pods as a network service, but a Deployment only manages pod lifecycle and replicas, not network exposure.

How to eliminate wrong answers

Option A is wrong because a Pod is the smallest deployable unit in Kubernetes and has its own IP address, but it is ephemeral and cannot provide a stable network endpoint for a set of pods. Option B is wrong because a Deployment manages the desired state of replica sets and pods, but it does not expose them as a network service; it is a controller, not a networking abstraction. Option D is wrong because an Ingress is a higher-level resource that provides HTTP/HTTPS routing rules to Services, but it does not directly expose pods as a network service; it relies on a Service to do so.

Practice this question →
62
MCQhard

In a serverless architecture using Knative, what happens when a function finishes processing an event and there are no pending events?

A.The function instance is automatically scaled down to zero replicas
B.The function instance is terminated and the container image is deleted
C.The function continues to run but stops listening for events
D.The function instance remains running for a configurable idle timeout
AnswerA

Knative's autoscaler, via the Pod Autoscaler and Activator, reduces the deployment to zero replicas when no events are pending, eliminating idle compute cost. The revision remains registered so the Activator can cold-start a replica when the next event arrives, matching the stem's zero-pending-events condition.

Why this answer

Knative scales the function to zero replicas when idle, which is a key feature of serverless platforms.

Practice this question →
63
MCQmedium

Which GitOps tools use a pull-based approach to synchronize the desired state in a Git repository with the actual state in a Kubernetes cluster? (Select all that apply.)

A.Flux
B.Terraform
C.Helm
D.ArgoCD
AnswerA, D

Flux runs an in-cluster controller that continuously pulls the Git repository, reconciles the desired manifests against live cluster state and applies drift corrections. This pull-based reconciliation satisfies the requirement for synchronising Git-declared state with the Kubernetes cluster.

Why this answer

Both Flux and ArgoCD are pull-based GitOps tools. Flux pioneered the pull-based pattern, while ArgoCD is also a popular implementation. Therefore, both A and D are correct.

Practice this question →
64
MCQmedium

What is the purpose of the circuit breaker pattern in a microservices architecture?

A.To balance load across multiple instances
B.To handle authentication between services
C.To encrypt data in transit
D.To prevent a service from being overwhelmed by requests when it is failing
AnswerD

When a downstream dependency fails, the circuit breaker trips and returns errors or fallbacks immediately, halting calls to the unhealthy service. This stops retry storms and queued requests from overwhelming an already failing service, satisfying the stem's requirement to prevent overload during failure.

Why this answer

The circuit breaker pattern is a stability pattern that monitors for failures and prevents a service from making requests to a failing downstream service, allowing it to recover. When the failure rate exceeds a threshold (e.g., 50% of requests fail within a 10-second sliding window), the circuit 'opens' and subsequent calls fail immediately without consuming resources. This prevents cascading failures and resource exhaustion in distributed systems like Kubernetes or Spring Cloud.

Exam trap

CNCF often tests the distinction between 'preventing overload from a failing service' (circuit breaker) and 'distributing load across healthy instances' (load balancer), so candidates mistakenly pick load balancing when they see 'overwhelmed by requests' in the question.

How to eliminate wrong answers

Option A is wrong because load balancing distributes incoming traffic across healthy instances (e.g., via Round Robin or Least Connections), not preventing overload from a failing service. Option B is wrong because authentication between services is handled by mechanisms like OAuth2, JWT, or mTLS, not by the circuit breaker pattern. Option C is wrong because encrypting data in transit is achieved via TLS/SSL (e.g., HTTPS, gRPC with TLS), not by circuit breakers which operate at the application or network layer to manage fault tolerance.

Practice this question →
65
MCQmedium

A platform team is adopting cloud-native principles for a new microservices application. They want to ensure that each service can be independently deployed and scaled without affecting other services. Which design principle BEST supports this goal?

A.Shared monolithic database for all services
B.Centralized orchestration of all service workflows
C.Synchronous request-response communication only
D.Loose coupling between services
AnswerD

Loose coupling allows services to interact through well-defined interfaces without tight dependencies, so changes or scaling of one service do not require coordinated changes in others. This directly enables independent deployment and scaling, which is a core cloud-native principle. Tight coupling would force teams to release services together and scale them in lockstep, defeating the goal.

Why this answer

Loose coupling is fundamental to cloud-native architecture because it allows each microservice to evolve, deploy, and scale independently. When services communicate through stable, well-defined interfaces and avoid shared state, teams can release changes without coordinating across the entire system. This autonomy is essential for rapid iteration and resilience in distributed environments.

Exam trap

The trap here is assuming that any form of communication or shared resource is acceptable as long as services are separate processes, when in fact coupling at the data or orchestration layer can still prevent independent deployment and scaling.

Practice this question →
66
MCQmedium

In serverless computing, what is the primary characteristic of Function-as-a-Service (FaaS)?

A.Stateful execution
B.Always running instances
C.Auto-scaling to zero
D.Manual scaling
AnswerC

Auto-scaling to zero means no function instances run while there is no traffic, so the platform provisions capacity only on invocation and releases it afterwards. That scale-to-zero behaviour, with no idle server cost, is the defining characteristic of FaaS.

Why this answer

The defining characteristic of FaaS is that functions are event-driven and the platform automatically scales the number of running instances from zero up to meet demand, then back down to zero when idle. This means you pay only for actual execution time, not for idle capacity. Auto-scaling to zero is what fundamentally separates FaaS from container-as-a-service or VM-based models.

Exam trap

KCNA often tests whether candidates confuse FaaS with containers or PaaS, so the trap is picking 'always running instances' because it sounds like a managed service rather than recognizing that scale-to-zero is the defining FaaS trait.

How to eliminate wrong answers

Option A is wrong because FaaS functions are stateless by design — state must be externalized to a database, cache, or object store, which is what enables the platform to spin instances up and down freely. Option B is wrong because always-running instances describe long-running containers or VMs, not FaaS; FaaS instances exist only during invocation (plus a brief warm period). Option D is wrong because manual scaling is the opposite of the FaaS model — FaaS platforms handle scaling automatically based on incoming events, with no operator intervention required.

Practice this question →
67
MCQmedium

An organization wants to implement a serverless function that scales to zero when not in use. Which technology is specifically designed to achieve this on Kubernetes?

A.Knative
B.Prometheus
C.Istio
D.Kubernetes Horizontal Pod Autoscaler (HPA)
AnswerA

Knative's Serving component manages request-driven workloads through its autoscaler, which scales pods down to zero when no traffic arrives and spins up on demand via the Activator. This directly satisfies the stem's scale-to-zero constraint, unlike standard Kubernetes Deployments, which maintain a minimum replica count.

Why this answer

Knative is a Kubernetes-based platform specifically designed to run serverless workloads, and its Serving component includes scale-to-zero as a core feature — pods are removed when there is no traffic and recreated on demand. It builds on Kubernetes primitives but adds the autoscaling and request-driven activation needed for true serverless behavior. This makes it the purpose-built answer for scale-to-zero functions on Kubernetes.

Exam trap

The trap is picking Kubernetes HPA because it sounds like the native scaling solution — candidates forget that HPA cannot scale to zero and lacks request-driven activation, which is the defining serverless requirement.

How to eliminate wrong answers

Option B is wrong because Prometheus is a metrics monitoring and alerting system, not a serverless runtime — it has no function execution or scaling capability. Option C is wrong because Istio is a service mesh providing traffic management, mTLS, and observability, not a serverless platform; it does not scale workloads to zero. Option D is wrong because Kubernetes HPA scales replicas based on metrics but has a minimum replica count of 1 by default and cannot scale to zero — it also does not provide the request-driven activation that serverless requires.

Practice this question →
68
MCQmedium

Which of the following best describes 'Infrastructure as Code' (IaC)?

A.Manually configuring servers via SSH
B.Using a scripting language to automate tasks
C.Running containers on a Kubernetes cluster
D.Defining infrastructure resources in a declarative configuration file
AnswerD

Declarative configuration files let you specify the desired end state of infrastructure, and the tool reconciles actual resources to match it. This satisfies IaC's core constraint: infrastructure defined reproducibly in version-controlled code rather than manual provisioning, enabling consistent, repeatable deployments across environments without imperative step-by-step commands.

Why this answer

IaC is fundamentally about declaring the desired end state of infrastructure in machine-readable configuration files (Terraform HCL, CloudFormation YAML, Kubernetes manifests) and letting a tool reconcile reality to match that declaration. Option D captures this declarative model, which is the defining characteristic of modern IaC. The key distinction is that the file describes *what* the infrastructure should look like, not the step-by-step *how*.

Exam trap

KCNA often tests the distinction between declarative (desired-state) and imperative (step-by-step) approaches, so candidates who equate 'automation' or 'scripting' with IaC pick Option B.

How to eliminate wrong answers

Option A is wrong because manually configuring servers via SSH is the antithesis of IaC — it is imperative, undocumented, non-reproducible, and prone to configuration drift. Option B is wrong because scripting (e.g., Bash, Python) is imperative automation: it describes *how* to reach a state, not the desired state itself, and re-running scripts is not idempotent in the way declarative IaC tools are. Option C is wrong because running containers on Kubernetes is a workload orchestration concern, not an infrastructure provisioning methodology — Kubernetes can itself be provisioned *via* IaC, but it is not IaC.

Practice this question →
69
MCQmedium

A development team wants to adopt a cloud-native architecture for a new application. Which set of principles BEST describes the cloud-native approach?

A.Microservices, containers, dynamic orchestration, and DevOps
B.Service-oriented architecture, bare-metal servers, static scaling, and Agile
C.Monolithic applications, virtual machines, manual scaling, and waterfall development
D.Serverless functions, virtual machines, manual provisioning, and ITIL
AnswerA

Microservices decompose the application into independently deployable services, containers package each with its dependencies, dynamic orchestration schedules and scales them across nodes, and DevOps automates delivery. Together these four principles satisfy the stem's cloud-native requirement, distinguishing it from monolithic or lift-and-shift approaches.

Why this answer

Cloud-native is defined by the CNCF as combining containers, microservices, service meshes, immutable infrastructure, and declarative APIs — with dynamic orchestration (Kubernetes) and DevOps culture as the operational backbone. Option A bundles all four pillars correctly: microservices for decomposition, containers for packaging, dynamic orchestration for scheduling/scaling, and DevOps for the cultural/process model. These four elements reinforce each other: containers enable microservices, orchestration makes containers manageable at scale, and DevOps provides the feedback loops.

Exam trap

KCNA often tests whether candidates conflate 'cloud-hosted' with 'cloud-native', so options mixing serverless with VMs or ITIL look plausible to anyone who only skims for buzzwords.

How to eliminate wrong answers

Option B is wrong because bare-metal servers and static scaling are explicitly anti-cloud-native — cloud-native relies on elastic, API-driven infrastructure, not fixed physical hosts. Option C is wrong on every count: monoliths, VMs, manual scaling, and waterfall are the traditional model that cloud-native was designed to replace. Option D is wrong because although serverless functions are cloud-native, pairing them with VMs, manual provisioning, and ITIL (a heavyweight IT service management framework) contradicts the automated, self-service, DevOps-oriented cloud-native philosophy.

Practice this question →
70
MCQmedium

Which command would you use to apply a manifest file 'deployment.yaml' to a Kubernetes cluster?

A.kubectl run deployment.yaml
B.kubectl set image deployment.yaml
C.kubectl apply -f deployment.yaml
D.kubectl create -f deployment.yaml
AnswerC

kubectl apply -f deployment.yaml submits the manifest declaratively, creating or updating the resources it defines to match the desired state. Alternatives such as create fail on existing resources, and get or describe only read cluster state.

Why this answer

kubectl apply -f deployment.yaml is the declarative command that creates or updates resources from a manifest file, reconciling the desired state in the file with the cluster's current state. The -f flag specifies the file, and apply is idempotent — running it repeatedly produces the same result. This is the standard way to deploy manifests in Kubernetes.

Exam trap

KCNA often tests the difference between imperative and declarative kubectl commands, so the trap is picking kubectl create -f because it also accepts a file, ignoring that create is not idempotent and fails on re-application.

How to eliminate wrong answers

Option A is wrong because kubectl run is used to create a single pod or deployment imperatively from command-line flags, not to apply a YAML manifest file; passing a filename to it is invalid usage. Option B is wrong because kubectl set image is used to update the container image of an existing workload, not to apply a manifest file. Option D is wrong because kubectl create -f works only for initial creation — it fails with an 'AlreadyExists' error if the resource is already present, so it is not the idiomatic command for ongoing manifest application.

Practice this question →
71
MCQmedium

What is the primary purpose of the sidecar container in a service mesh?

A.To run application business logic
B.To handle logging and monitoring of the main container
C.To provide persistent storage for the main container
D.To intercept and manage network traffic for the main container
AnswerD

The sidecar proxy runs alongside the main container and transparently intercepts inbound and outbound network traffic, enforcing mTLS, routing, retries and telemetry policies. This offloads service-mesh networking concerns from application code without modifying the main container.

Why this answer

In a service mesh, the sidecar container (typically an Envoy or Linkerd proxy) is injected alongside the main application container to intercept and manage all inbound and outbound network traffic. This allows the service mesh to enforce traffic policies, handle service discovery, implement retries and circuit breaking, and collect telemetry without modifying the application code. The sidecar operates at the network layer (L4/L7), decoupling communication concerns from business logic.

Exam trap

CNCF often tests the misconception that the sidecar's primary role is logging and monitoring, but the correct answer is always traffic interception and management, as that is the core architectural purpose of a service mesh sidecar.

How to eliminate wrong answers

Option A is wrong because the sidecar container does not run application business logic; that is the responsibility of the main container. Option B is wrong because while the sidecar can collect telemetry data as a byproduct of traffic interception, its primary purpose is not logging and monitoring—those are separate concerns often handled by dedicated agents or the control plane. Option C is wrong because persistent storage is provided by volumes or CSI drivers, not by sidecar containers, which are ephemeral and focused on network functions.

Practice this question →
72
MCQmedium

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

A.Verify the database Service and Endpoints in Kubernetes
B.Scale up the microservice deployment
C.Restart the microservice pod
D.Check the logs of other microservices
AnswerA

'Connection refused' means the client reached a host but nothing accepted the connection, so the Service may have no matching Endpoints. Verifying the Service selector and its Endpoints confirms whether pods are actually registered before investigating DNS, network policy or the database itself.

Why this answer

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.

Exam trap

The trap here is that candidates often jump to restarting the pod or scaling the deployment, assuming the microservice itself is faulty, rather than recognizing that 'connection refused' is a network-level symptom pointing to the target (the database Service/Endpoints) not being available.

How to eliminate wrong answers

Option B is wrong because scaling up the microservice deployment will create more pods that all try to connect to the same unreachable database, multiplying the failure without addressing the root cause. Option C is wrong because restarting the microservice pod will only reattempt the same connection to the same database endpoint, which will still be refused if the database Service or its backing pods are misconfigured. Option D is wrong because checking logs of other microservices is a distraction; the 'connection refused' error is specific to the database connectivity and does not require cross-service log analysis to diagnose.

Practice this question →
73
MCQmedium

An organization uses GitOps with ArgoCD to manage Kubernetes deployments. What is the PRIMARY advantage of this approach over traditional imperative deployment methods?

A.It eliminates the need for any manual approval processes
B.It provides a single source of truth for cluster state through Git
C.It allows developers to directly access the Kubernetes cluster
D.It reduces the number of containers needed in a deployment
AnswerB

Git holds the declarative desired state, and ArgoCD continuously reconciles the cluster to match it. This differs from imperative scripting, which issues one-off commands, because Git becomes the authoritative, auditable source of truth for the cluster.

Why this answer

GitOps uses a Git repository as the single source of truth, enabling declarative configuration, version control, and automated reconciliation. This is the primary advantage over traditional imperative methods. Option A is incorrect because manual approval processes can still be part of a GitOps workflow.

Option C is incorrect because GitOps does not eliminate the need for access controls. Option D is incorrect because GitOps does not directly reduce container count.

Practice this question →
74
MCQeasy

Which of the following is a core principle of the 12-factor app methodology?

A.Treat logs as event streams
B.Store configuration in the application code
C.Store logs in the local filesystem of each container
D.Use shared filesystems for persistent storage
AnswerA

Treating logs as event streams means the app writes them to stdout as an unbuffered sequence of events, leaving routing, storage and aggregation to the execution environment. This decouples the app from log destinations, matching the 12-factor principle of separation from backing services.

Why this answer

The 12-factor app methodology, a set of best practices for building modern, scalable applications, includes the principle 'Treat logs as event streams.' This means an app should not concern itself with routing or storage of its output stream; instead, it writes logs to stdout/stderr, and the execution environment captures and routes them. This decouples log management from the application, enabling flexibility and scalability.

Exam trap

The trap is confusing log storage with log handling: candidates might think storing logs in the filesystem is acceptable, but 12-factor explicitly advocates treating logs as event streams, not files.

How to eliminate wrong answers

Option B is wrong because storing configuration in application code violates the 12-factor principle of separating config from code; config should be stored in environment variables. Option C is wrong because storing logs in the local filesystem of each container is an anti-pattern; containers are ephemeral, and logs should be streamed to a centralized system. Option D is wrong because using shared filesystems for persistent storage is not a core 12-factor principle; while stateful apps exist, 12-factor apps are designed to be stateless and store state in backing services.

Practice this question →
75
MCQeasy

Which CNCF project maturity level indicates that a project has adopted the CNCF Code of Conduct and is considered early-stage?

A.Sandbox
B.Incubating
C.Graduated
D.Experimental
AnswerA

Sandbox is the earliest CNCF maturity level. Projects at this stage must adopt the CNCF Code of Conduct and are described as early-stage experiments, before progressing to Incubating and then Graduated. It directly matches the stem's requirement for the level indicating Code of Conduct adoption and early-stage status.

Why this answer

The CNCF has three maturity levels: sandbox (early-stage), incubating (growing), and graduated (mature). Sandbox projects are early-stage and have accepted the CNCF Code of Conduct.

Practice this question →
Page 1 of 2 · 150 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Kcna Cloud Native Arch questions.

Start 20-question session