CCNA Kcna Cloud Native Arch Questions — Page 2 of 2

MCQhard

Which of the following is a key principle of the 12-factor app methodology related to managing configuration?

A.Store configuration in the application code

B.Use environment variables for configuration

C.Embed configuration in the build process

D.Use a configuration file in the application directory

AnswerB

Twelve-factor apps separate configuration from code, storing it in environment variables so the same build deploys unchanged across environments. This satisfies the stem's constraint of managing configuration without hardcoding values or committing environment-specific settings into the codebase.

Why this answer

The 12-factor app methodology's third factor, 'Config,' states that configuration should be stored in the environment (environment variables), not in the code. This separates config from code, allowing the same build to be deployed across environments (dev, staging, prod) without modification. Environment variables are language-agnostic and easily changed per deployment.

Exam trap

KCNA often tests the 12-factor 'Config' factor, catching candidates who confuse environment variables with config files or build-time embedding, missing the core principle of separating config from code for portability.

How to eliminate wrong answers

Option A is wrong because storing configuration in application code violates the 12-factor principle of separating config from code; it makes the build environment-specific and requires code changes to alter config. Option C is wrong because embedding configuration in the build process ties config to a specific build artifact, preventing the same artifact from being promoted across environments — the opposite of the 12-factor goal. Option D is wrong because a configuration file in the application directory is still part of the codebase and is not environment-agnostic; it can be accidentally committed and does not support per-environment overrides as cleanly as environment variables.

Practice this question →

MCQeasy

A platform engineer is explaining the role of the Kubernetes API server in a cloud-native architecture. Which statement BEST describes its primary function?

A.It schedules pods to nodes based on resource availability.

B.It serves as the central management endpoint that validates and processes REST requests for cluster resources.

C.It provides a distributed key-value store for cluster state.

D.It monitors the health of nodes and restarts failed containers.

AnswerB

The Kubernetes API server is the front end of the control plane. It exposes the Kubernetes API, validates and processes REST requests, and updates the cluster state in etcd. All other components interact with it to read or modify resources, making it the central management endpoint.

Why this answer

The Kubernetes API server acts as the central management endpoint for the cluster. It exposes the Kubernetes API, authenticates and authorizes requests, validates resource configurations, and persists state to etcd. Other control plane components and user tools like kubectl communicate exclusively through it, so it is the single point of interaction for cluster operations.

Exam trap

The trap here is attributing scheduling, node health monitoring, or etcd's storage role to the API server, when those are handled by separate control plane components.

Practice this question →

MCQmedium

Which service mesh component is responsible for handling inter-service communication as a sidecar proxy?

A.Mixer

B.Pilot

C.Envoy

D.Citadel

AnswerC

Envoy is the high-performance proxy that Istio and similar service meshes deploy as a sidecar container alongside each workload. It intercepts inbound and outbound traffic, applying routing, mTLS and telemetry policies for all inter-service communication.

Why this answer

Envoy is the correct answer because it is the sidecar proxy component in Istio that handles all inter-service communication. It intercepts traffic between microservices and applies routing, load balancing, and security policies defined by the control plane. Envoy runs as a sidecar container alongside each service instance, managing inbound and outbound traffic at the L4/L7 layer.

Exam trap

CNCF often tests the distinction between data-plane and control-plane components, so the trap here is that candidates may confuse Pilot (control plane) with the sidecar proxy that actually handles traffic, or incorrectly associate Mixer with traffic management due to its former role in policy enforcement.

How to eliminate wrong answers

Option A (Mixer) is wrong because Mixer was a deprecated Istio component used for telemetry collection and policy enforcement, not for proxying inter-service traffic; it was removed in Istio 1.5. Option B (Pilot) is wrong because Pilot is the control plane component that translates high-level routing rules into Envoy configuration and distributes them to sidecars, but it does not handle data-plane traffic itself. Option D (Citadel) is wrong because Citadel is the Istio security component responsible for certificate issuance and key management for mTLS, not for proxying service-to-service communication.

Practice this question →

MCQhard

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

A.Scale up the frontend service to handle more concurrent requests

B.Convert all inter-service communication to synchronous calls with retries

C.Increase the timeout values in the frontend service configuration

D.Implement circuit breakers in the frontend service for calls to the order service

AnswerD

Circuit breakers in the frontend trip when order-service calls exceed a failure threshold, failing fast instead of holding threads until timeout. This stops thread-pool exhaustion and the cascading failure, directly addressing the synchronous HTTP dependency that caused the frontend to crash.

Why this answer

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

Exam trap

CNCF often tests the misconception that scaling or increasing timeouts is a sufficient fix for cascading failures, but the trap here is that these options treat symptoms rather than applying the circuit breaker pattern, which is the standard resilience mechanism for synchronous calls in cloud-native systems.

How to eliminate wrong answers

Option A is wrong because scaling up the frontend service only increases the number of concurrent requests it can handle, but does not address the root cause—the order service being overwhelmed—and may actually worsen the cascading failure by allowing more requests to pile up and exhaust thread pools faster. Option B is wrong because converting all inter-service communication to synchronous calls with retries would increase coupling and amplify failures; retries during overload can cause retry storms, further degrading the order service and increasing latency. Option C is wrong because increasing timeout values only delays the inevitable thread pool exhaustion, as the frontend will hold connections longer without reducing the load on the order service, and may lead to resource starvation under sustained high traffic.

Practice this question →

MCQmedium

In a service mesh architecture, which component is responsible for intercepting and managing traffic between microservices?

A.Control plane

B.API gateway

C.Service registry

D.Sidecar proxy

AnswerD

A sidecar proxy runs alongside each microservice instance, transparently intercepting all inbound and outbound network traffic. This satisfies the service mesh requirement for per-service traffic management, since the sidecar enforces routing, retries, mutual TLS and telemetry policies without modifying application code.

Why this answer

In a service mesh, the sidecar proxy is deployed alongside each microservice instance and transparently intercepts all inbound and outbound network traffic. It enforces policies, collects telemetry, and manages routing without requiring changes to the application code. The control plane configures these proxies but does not handle the actual data path.

Exam trap

KCNA often tests the distinction between the control plane (management) and data plane (traffic interception), causing candidates to incorrectly choose the control plane as the component that handles traffic.

How to eliminate wrong answers

Option A is wrong because the control plane only manages and configures the sidecar proxies (e.g., distributing policies, service discovery data), but it does not sit in the data path to intercept traffic. Option B is wrong because an API gateway handles north-south traffic (external clients to services) and is not the component that intercepts east-west traffic between microservices inside the mesh. Option C is wrong because a service registry only maintains a list of available service instances for discovery; it does not intercept or manage traffic.

Practice this question →

MCQmedium

In a multi-cloud architecture, what is a common use case for a service mesh?

A.To enable secure service-to-service communication across clusters

B.To synchronize Kubernetes resources across clouds

C.To provide cloud-agnostic block storage

D.To provide a single ingress gateway for all clouds

AnswerA

A service mesh provides mutual TLS, identity-based authorisation and traffic policy between workloads, extending these controls across Kubernetes clusters on different providers. That directly satisfies the multi-cloud constraint, where native cluster networking cannot span providers, so cross-cluster service-to-service communication needs a consistent, encrypted data plane.

Why this answer

A service mesh, such as Istio or Linkerd, provides a dedicated infrastructure layer for handling service-to-service communication. In a multi-cloud architecture, its common use case is to enable secure, observable, and resilient communication between services running in different Kubernetes clusters across clouds, using mutual TLS (mTLS) for encryption and traffic policies for routing.

Exam trap

CNCF often tests the misconception that a service mesh is a general-purpose tool for all cross-cloud operations, when in reality it is specifically designed for service-to-service communication (east-west traffic) and does not handle resource synchronization, storage, or ingress gateway functions.

How to eliminate wrong answers

Option B is wrong because synchronizing Kubernetes resources across clouds is typically done by tools like Karmada, Cluster API, or Terraform, not by a service mesh, which focuses on network traffic management. Option C is wrong because cloud-agnostic block storage is provided by storage abstraction layers like CSI (Container Storage Interface) drivers or solutions like Rook/Ceph, not by a service mesh, which operates at Layer 7 (HTTP/gRPC) and Layer 4 (TCP). Option D is wrong because a single ingress gateway for all clouds is the role of a multi-cluster ingress controller or global load balancer (e.g., NGINX Ingress Controller with external-dns), while a service mesh handles east-west traffic between services, not north-south ingress traffic.

Practice this question →

Multi-Selectmedium

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

Select 3 answers

A.Persistent storage management for stateful applications.

B.Mutual TLS (mTLS) encryption between services.

C.Automatic horizontal scaling of pods.

D.Observability through distributed tracing and metrics.

E.Traffic management such as canary deployments and circuit breaking.

AnswersB, D, E

Mutual TLS encrypts service-to-service traffic in both directions, with each side verifying the other's certificate. This satisfies the stem's cloud-native security benefit: identity-based authentication and confidentiality for east-west traffic without application code changes, replacing plaintext inter-pod communication with cryptographically verified channels.

Why this answer

Option B is correct because a service mesh like Istio or Linkerd transparently provisions mutual TLS (mTLS) between sidecar proxies, giving every service-to-service call strong identity-based encryption and authentication without application code changes. Option D is correct because service meshes emit uniform telemetry from their sidecars — distributed traces (e.g., via Envoy and Zipkin/Jaeger), request metrics (latency, error rates, throughput), and access logs — providing consistent observability across heterogeneous services. Option E is correct because the mesh's control plane configures traffic routing rules that enable canary releases, blue/green rollouts, retries, timeouts, and circuit breaking at the proxy layer.

Option A is not a service mesh benefit; persistent storage for stateful workloads is handled by CSI drivers, PersistentVolumes, and StatefulSets, not by the mesh data plane. Option C is also not a mesh function; automatic horizontal pod scaling is performed by the Kubernetes Horizontal Pod Autoscaler (HPA) based on metrics, independent of the service mesh.

Exam trap

CNCF often tests the misconception that a service mesh provides infrastructure-level features like storage or scaling, when in reality it is strictly a Layer 4/7 networking and security abstraction that operates independently of compute or storage resources.

Practice this question →

MCQeasy

A platform team runs a multi-tenant Kubernetes cluster for several product groups. They want each group's workloads to be logically isolated from one another, with separate quota limits and separate RBAC bindings, while still sharing the same cluster control plane and worker nodes. Which Kubernetes construct BEST provides this isolation boundary?

A.NetworkPolicy

B.Node affinity rule

C.Namespace

D.PodDisruptionBudget

AnswerC

A Namespace is the built-in Kubernetes mechanism for partitioning a single cluster into virtual sub-clusters. ResourceQuota and LimitRange objects are scoped to a namespace, and RoleBinding/ClusterRoleBinding subjects can be limited to a namespace, so each product group gets its own quota and permission boundary without provisioning a separate control plane. This directly matches the requirement of logical isolation with shared infrastructure.

Why this answer

Namespaces are the standard way to carve one Kubernetes cluster into logical partitions for multiple teams. They scope names for objects, act as the boundary for ResourceQuota and LimitRange, and are the natural target for RoleBinding subjects, so separate groups get separate quotas and permissions while sharing the control plane and nodes. The other constructs address scheduling, traffic filtering, or eviction behaviour rather than tenancy.

Exam trap

The trap here is assuming that a Namespace provides hard security isolation, when it is really an administrative and naming boundary that needs NetworkPolicy and RBAC layered on top.

Practice this question →

MCQmedium

In an event-driven architecture using a message broker, which component is responsible for receiving events and forwarding them to subscribed services?

A.Service mesh

B.Message broker

C.API gateway

D.Load balancer

AnswerB

A message broker receives published events and routes them to subscribed services, decoupling producers from consumers. This directly satisfies the stem's requirement for the component that accepts incoming events and forwards them onward, rather than generating, storing or processing them itself.

Why this answer

In event-driven architecture, the message broker (Kafka, RabbitMQ, NATS, Pulsar) is the intermediary that receives published events and routes them to subscribers based on topics, queues, or routing keys. It decouples producers from consumers, buffers events, and handles delivery semantics. Option B names this component directly.

Exam trap

KCNA often tests whether candidates confuse the message broker (asynchronous event routing) with the API gateway (synchronous API fronting) or service mesh (service-to-service networking), so all three look like 'traffic' components.

How to eliminate wrong answers

Option A is wrong because a service mesh (Istio, Linkerd) handles service-to-service networking concerns — mTLS, traffic shifting, retries, observability — at the sidecar/proxy layer, not event routing between producers and consumers. Option C is wrong because an API gateway (Kong, Apigee) fronts synchronous HTTP/REST/gRPC APIs, handling auth, rate limiting, and routing for request/response traffic, not asynchronous event distribution. Option D is wrong because a load balancer distributes incoming connections across backend instances; it does not implement publish/subscribe semantics, topic routing, or event persistence.

Practice this question →

MCQmedium

Which of the following is a benefit of using a service mesh?

A.Simplified storage management

B.Automatic scaling of applications

C.Enhanced observability and traffic control

D.Direct database access

AnswerC

A service mesh provides mutual TLS, traffic routing and telemetry at the sidecar proxy layer, giving consistent observability and fine-grained traffic control across services without changing application code. That combination of visibility and control is the benefit the question asks for.

Why this answer

A service mesh (Istio, Linkerd, Consul Connect) injects sidecar proxies alongside application pods to intercept all service-to-service traffic, providing uniform mTLS, traffic shifting, retries, circuit breaking, and rich telemetry (latency, error rates, request tracing) without application code changes. Option C correctly identifies the two headline benefits: enhanced observability and traffic control. These capabilities are delivered at the infrastructure layer, transparently to the application.

Exam trap

KCNA often tests whether candidates attribute application-level concerns (scaling, storage, database access) to the service mesh, so options like 'automatic scaling' look plausible because the mesh does expose metrics that *feed* autoscalers.

How to eliminate wrong answers

Option A is wrong because storage management is handled by Kubernetes storage primitives (PersistentVolumes, StorageClasses, CSI drivers) or dedicated storage solutions — a service mesh does not manage storage. Option B is wrong because automatic scaling is the job of the Horizontal Pod Autoscaler, Vertical Pod Autoscaler, or KEDA — a service mesh can inform scaling decisions via metrics but does not itself scale workloads. Option D is wrong because direct database access is an application/data-layer concern; a service mesh operates at the network layer between services and does not provide database connectivity.

Practice this question →

MCQmedium

According to the 12-factor app methodology, how should an application store configuration that varies between deployments (e.g., database connection strings)?

A.In a configuration file that is version-controlled

B.In a database table

C.In environment variables

D.Hard-coded in the application code

AnswerC

Storing configuration in environment variables satisfies the 12-factor requirement to strictly separate config from code, since values vary per deployment without code changes. Environment variables are language- and OS-agnostic, avoid committing credentials to version control, and allow the same build artefact to be promoted unchanged across environments.

Why this answer

The 12-factor app recommends strict separation of config from code, storing config in environment variables.

Practice this question →

MCQmedium

Which CNCF project is at the 'Graduated' maturity level and is widely used for container orchestration?

A.Kubernetes

B.Prometheus

C.Envoy

D.Helm

AnswerA

Kubernetes is the CNCF's flagship Graduated project, having reached that maturity level in 2018. It satisfies the container orchestration constraint directly: it schedules, deploys and scales containers across clusters. No other CNCF project combines Graduated status with orchestration at this scale of adoption.

Why this answer

Kubernetes is the correct answer because it is the CNCF Graduated project specifically designed and widely adopted for container orchestration. It automates deployment, scaling, and management of containerized applications, making it the de facto standard in cloud-native environments. Note that Prometheus, Envoy, and Helm are also CNCF Graduated projects, but they serve different functions (monitoring, service proxy/networking, and package management respectively), not container orchestration.

Exam trap

CNCF often tests the distinction between a project's maturity level and its function. The trap here is that candidates may assume any popular CNCF project (like Prometheus or Envoy) is used for orchestration, when in fact Kubernetes is the project that fulfills that specific role. Remember that maturity level (Graduated) and function (orchestration) are separate attributes.

How to eliminate wrong answers

Option B (Prometheus) is wrong because, although it is a Graduated CNCF project, it is a monitoring and alerting toolkit, not a container orchestration platform. Option C (Envoy) is wrong because it is a Graduated CNCF project but functions as a high-performance proxy and service mesh data plane, not an orchestrator. Option D (Helm) is wrong because it is a package manager for Kubernetes (Incubating maturity level), not a container orchestration tool itself.

Practice this question →

MCQeasy

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

A.To distribute traffic across multiple instances

B.To stop cascading failures by preventing calls to a failing service

C.To encrypt communication between services

D.To automatically retry failed requests

AnswerB

A circuit breaker monitors calls to a dependency; once failures cross a threshold it trips open, returning errors immediately instead of queuing requests. This halts the propagation of failures through call chains, preventing one failing service from exhausting threads and cascading across the microservice estate.

Why this answer

The circuit breaker pattern wraps calls to a remote service and monitors for failures. When failures exceed a threshold, the breaker 'opens' and subsequent calls fail fast (or return a fallback) instead of being attempted, preventing a single failing dependency from exhausting threads/connections and cascading failures across the microservice graph. This is the core purpose: fault isolation and preventing cascading failures.

Exam trap

KCNA often tests the confusion between resilience patterns — candidates pick 'retry' or 'load balancing' because those also sound like ways to handle failures, but the circuit breaker's defining trait is stopping calls to a failing service to prevent cascading failure.

How to eliminate wrong answers

Option A is wrong because distributing traffic across instances is load balancing (e.g., via a load balancer or client-side LB), not circuit breaking. Option C is wrong because encrypting inter-service communication is handled by TLS/mTLS, not by a circuit breaker. Option D is wrong because automatic retries are a separate resilience pattern (retry with backoff); in fact, retries can worsen cascading failures, which is why circuit breakers are often paired with them.

Practice this question →

Multi-Selectmedium

Which TWO of the following are core principles of the 12-factor app? (Choose 2.)

Select 2 answers

A.Shared state

B.Manual deployment

C.Dependencies

D.Singleton processes

E.Config

AnswersC, E

The dependencies principle requires applications to explicitly declare and isolate dependencies via a manifest, so nothing is assumed present on the host. This satisfies the stem's requirement for a core 12-factor principle, enabling reproducible builds across environments.

Why this answer

Option C (Dependencies) is correct because the 12-factor app's Dependencies principle requires applications to explicitly declare and isolate all dependencies via a dependency declaration manifest (e.g., requirements.txt, Gemfile, package.json) and a dependency isolation tool (e.g., virtualenv, Bundler), so the app never relies on implicit system-wide packages. Option E (Config) is correct because the Config principle mandates storing configuration in environment variables rather than in code or checked-in files, keeping config strictly separate from the codebase so the same build can be deployed across environments. The unmarked options do not belong: Shared state (A) contradicts the stateless processes principle, which requires sharing nothing between processes and externalizing state to backing services; Manual deployment (B) contradicts the Build/Release/Run and CI/CD automation principles; and Singleton processes (D) contradicts the concurrency principle, which favors scaling out via multiple stateless processes rather than relying on a single long-lived instance.

Exam trap

The trap is that 'shared state' and 'singleton processes' sound like reasonable architectural choices, but 12-factor explicitly rejects both in favor of stateless, horizontally scalable processes.

Practice this question →

MCQeasy

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

A.Backing services

B.Dependencies

C.Config

D.Codebase

AnswerC

The Config factor requires configuration that varies between deployments — credentials, endpoints, feature flags — to be stored in environment variables rather than committed to code. This keeps the same build artefact portable across environments without code changes.

Why this answer

The Config factor in the 12-factor app methodology states that configuration should be stored in environment variables, not in code or config files. This allows the same codebase to be deployed across environments by injecting different configurations at runtime.

Exam trap

KCNA often tests the confusion between similar-sounding factors like Config and Backing services, causing candidates to overlook the specific emphasis on environment variables for configuration.

How to eliminate wrong answers

Option A is wrong because Backing services refers to treating external services (databases, queues) as attached resources, not configuration storage. Option B is wrong because Dependencies refers to explicitly declaring and isolating dependencies, not configuration. Option D is wrong because Codebase refers to having a single codebase tracked in version control, not configuration management.

Practice this question →

MCQeasy

Which CNCF project maturity level indicates that a project has successfully adopted the CNCF governance and is considered stable for production use?

A.Incubating

B.Experimental

C.Graduated

D.Sandbox

AnswerC

Graduated status confirms a project has adopted CNCF governance and proven production stability through broad adoption and a completed security audit. This satisfies the stem's requirement for a maturity level indicating stable, production-ready use, distinguishing it from Incubating and Sandbox projects.

Why this answer

The Graduated maturity level is the highest in the CNCF project lifecycle, indicating that a project has both successfully adopted CNCF governance and is considered stable for production use. To achieve Graduated, a project must meet rigorous criteria including adoption by multiple end users, a defined governance structure, and completion of a security audit. This distinguishes it from lower maturity levels such as Sandbox (early-stage) and Incubating (growing but not yet stable).

Exam trap

CNCF often tests the distinction between Sandbox and Incubating, where candidates mistakenly think Sandbox implies production readiness, but Sandbox is explicitly for early-stage projects that have not yet demonstrated stability or adopted full CNCF governance.

How to eliminate wrong answers

Option A is wrong because Incubating is an intermediate stage where projects have shown initial adoption and are working toward graduation, but they are not yet considered fully stable for production use. Option B is wrong because Experimental is not a CNCF maturity level; the CNCF uses Sandbox, Incubating, and Graduated, while Experimental is a term used by other foundations or early-stage projects outside the CNCF. Option D is wrong because Sandbox is the entry-level stage for early-stage projects that are not yet ready for production use and have not fully adopted CNCF governance.

Practice this question →

MCQmedium

A development team is adopting a GitOps workflow for their Kubernetes applications. They want to ensure that the cluster state always matches the desired state defined in Git. Which component is responsible for continuously reconciling the cluster with the Git repository?

A.kube-scheduler

B.GitOps operator such as Argo CD or Flux

C.Container runtime

D.Kubernetes API server

AnswerB

A GitOps operator runs in the cluster and continuously monitors the Git repository for changes. It compares the desired manifests with the live cluster state and applies any differences, ensuring reconciliation. This automated sync is the core of GitOps and directly satisfies the requirement for continuous reconciliation with Git.

Why this answer

GitOps relies on an operator like Argo CD or Flux that runs in the cluster and continuously reconciles the live state with the desired state stored in Git. This automated sync ensures that any drift is corrected, providing a declarative and version-controlled deployment model.

Exam trap

The trap here is assuming that core Kubernetes components like the API server or scheduler handle external Git reconciliation, when in fact GitOps requires a dedicated operator to pull and apply desired state from Git.

Practice this question →

MCQmedium

A platform team is designing a system that must continue serving requests for a product catalog even if the recommendation service becomes unavailable. The recommendation service calls the catalog service to fetch item details, and when it fails, the catalog service should keep responding to user traffic. Which cloud-native architecture principle BEST describes the required behavior for the catalog service?

A.Storing all catalog and recommendation data in a single shared relational database

B.Vertical scaling of the recommendation service to handle peak load

C.Loose coupling through asynchronous, queue-based communication

D.Design for failure and graceful degradation of non-critical dependencies

AnswerD

Designing for failure means assuming dependencies can become unavailable and ensuring the core function still works. The catalog service must serve user traffic even when the recommendation service fails, so it should treat that dependency as non-critical and degrade gracefully instead of failing entirely. This directly matches the stated requirement.

Why this answer

The catalog service must remain available even when the recommendation service fails. That requires treating the recommendation dependency as non-critical and designing for failure, so the catalog service can degrade gracefully rather than propagate the failure. The other choices either change communication style, scale the wrong service, or introduce tighter coupling, none of which satisfies the requirement.

Exam trap

The trap here is assuming that any resilience pattern, such as asynchronous messaging, automatically satisfies a requirement that specifically calls for tolerating a failed dependency.

Practice this question →

Multi-Selecthard

Which THREE of the following are benefits of using a service mesh? (Select three.)

Select 3 answers

A.Automatic scaling of pods

B.Increased application performance

C.Fine-grained traffic control (e.g., canary deployments)

D.Improved observability through metrics and tracing

E.Simplified service-to-service security with mutual TLS

AnswersC, D, E

Service mesh enables advanced traffic routing.

Why this answer

A service mesh, such as Istio or Linkerd, provides fine-grained traffic control through features like traffic splitting, header-based routing, and weighted load balancing. This enables canary deployments by directing a small percentage of traffic to a new version of a service, allowing safe testing in production without affecting all users.

Exam trap

CNCF often tests the misconception that a service mesh improves performance or handles autoscaling, when in fact it focuses on traffic management, security, and observability at the cost of some latency.

Practice this question →

Multi-Selectmedium

Which TWO of the following are core principles of the 12-factor app methodology? (Select TWO.)

Select 2 answers

A.Manual approval for all production deployments

B.Use of a single programming language across all services

C.Store logs in a local file system

D.Strict separation of config from code

E.Maximize robustness through fast startup and graceful shutdown

AnswersD, E

Config should be stored in environment variables.

Why this answer

The 12-factor app methodology mandates strict separation of config from code. Config includes things like database connection strings, API keys, and environment-specific values that vary between deployments. Storing these in environment variables (or external config files not checked into version control) ensures that the same codebase can be deployed to different environments without modification, which is a core principle for cloud-native portability and security.

Exam trap

CNCF often tests the misconception that logs should be stored locally for reliability, but the 12-factor methodology treats logs as event streams to stdout, relying on the execution environment (e.g., kubectl logs, log shippers) for aggregation and persistence.

Practice this question →

MCQeasy

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

A.To develop proprietary cloud software

B.To define cloud-native standards only

C.To certify cloud providers

D.To host and support open-source cloud-native projects

AnswerD

The CNCF hosts and supports open-source cloud-native projects, providing neutral governance, conformance programmes and community infrastructure for technologies such as Kubernetes, Prometheus and Envoy. It does not itself author vendor products or define proprietary standards.

Why this answer

The CNCF is a vendor-neutral organization under the Linux Foundation that hosts and supports open-source cloud-native projects like Kubernetes, Prometheus, and Envoy. Its primary role is to foster collaboration, provide governance, and manage the lifecycle of these projects to ensure their long-term sustainability. While it does define standards and certify providers, these are secondary activities that support its core mission of hosting open-source projects.

Exam trap

KCNA often tests the misconception that the CNCF's primary role is to create standards or certify providers, when in fact its core mission is to host and support open-source projects.

How to eliminate wrong answers

Option A is wrong because the CNCF does not develop proprietary software; it only supports open-source projects. Option B is wrong because defining standards is not its primary purpose; the CNCF primarily hosts projects, and standards often emerge from those projects. Option C is wrong because certifying cloud providers is a secondary activity (e.g., Kubernetes Certified Service Provider program) and not the primary purpose.

Practice this question →

MCQmedium

Which component in an event-driven architecture is responsible for decoupling event producers from consumers?

A.Config server

B.Event broker

C.API gateway

D.Service mesh

AnswerB

The event broker sits between producers and consumers, receiving published events and routing them onward, so neither side holds direct references to the other. This intermediary role provides the temporal and spatial decoupling that event-driven architectures require.

Why this answer

The event broker (e.g., Kafka, RabbitMQ, NATS) is the central component that receives events from producers and routes them to consumers, allowing producers and consumers to operate independently without direct knowledge of each other. It provides asynchronous, decoupled communication by buffering events, managing subscriptions, and ensuring delivery. This decoupling enables scalability, fault tolerance, and independent evolution of services.

Exam trap

KCNA often tests the misconception that an API gateway or service mesh handles event decoupling, but they are for synchronous communication; the event broker is the correct component for asynchronous event-driven decoupling.

How to eliminate wrong answers

Option A is wrong because a config server (e.g., Spring Cloud Config, etcd) manages configuration data, not event routing or decoupling of producers and consumers. Option C is wrong because an API gateway handles synchronous request-response traffic, routing and securing API calls, but does not provide asynchronous event decoupling. Option D is wrong because a service mesh (e.g., Istio, Linkerd) manages service-to-service communication, observability, and security for synchronous RPCs, but it does not decouple event producers and consumers in an event-driven architecture.

Practice this question →

MCQmedium

In a microservices architecture, which pattern is used to prevent cascading failures by limiting the number of concurrent requests to a service?

A.Bulkhead

B.Timeout

C.Retry

D.Circuit breaker

AnswerA

Bulkhead partitioning isolates each downstream dependency into a separate resource pool with its own concurrency limit, so exhaustion of one pool cannot starve others. This directly satisfies the stem's constraint: capping concurrent requests to a service, thereby containing failures and preventing them from cascading across the microservices architecture.

Why this answer

The bulkhead pattern isolates resources (e.g., thread pools, connection pools) for different services or operations so that a failure or overload in one area does not exhaust resources and cause cascading failures. By limiting the number of concurrent requests to a service, bulkheads contain the impact of slow or failing dependencies. This is analogous to watertight compartments in a ship.

Exam trap

KCNA often tests the distinction between bulkhead and circuit breaker; candidates may pick circuit breaker because both address failures, but only bulkhead limits concurrency.

How to eliminate wrong answers

Option B is wrong because a timeout limits how long a request waits for a response; it does not limit concurrency and can still allow resource exhaustion if many requests time out simultaneously. Option C is wrong because retry attempts to recover from transient failures by re-sending requests, which can amplify load and worsen cascading failures if not bounded. Option D is wrong because a circuit breaker stops calls to a failing service after a threshold, but it does not limit concurrent requests to a healthy service; bulkheads and circuit breakers are complementary.

Practice this question →

MCQeasy

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

A.Automated CI/CD pipelines

B.Manual configuration management

C.Tight coupling of services

D.Preferring stateful applications over stateless

AnswerA

Automated CI/CD pipelines embody the cloud-native principle of continuous delivery, enabling rapid, reliable and frequent releases through repeatable automation. This satisfies the stem's requirement for a key cloud-native practice by removing manual deployment bottlenecks, supporting small incremental changes, and allowing teams to recover quickly from failures without disrupting running services.

Why this answer

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

Exam trap

CNCF often tests the misconception that manual configuration management is acceptable in cloud-native environments, but the trap here is that candidates confuse traditional IT operations with the automated, declarative approach required for cloud-native scalability and resilience.

How to eliminate wrong answers

Option B is wrong because manual configuration management contradicts the cloud-native principle of declarative, automated infrastructure (e.g., using Kubernetes manifests or Terraform), leading to configuration drift and reduced scalability. Option C is wrong because tight coupling of services violates the microservices tenet of loose coupling, which is fundamental to independent deployability and fault isolation in cloud-native architectures. Option D is wrong because cloud-native architecture prefers stateless applications over stateful ones, as stateless services scale horizontally more easily and are simpler to manage; state is typically offloaded to external stores like databases or caches.

Practice this question →

100

Multi-Selecteasy

Which TWO of the following are essential components of a GitOps workflow? (Select two.)

Select 2 answers

A.A separate database for storing desired state

B.A monitoring dashboard for visualizations

C.A CI/CD pipeline that manually applies changes

D.An operator that synchronizes the cluster state with the Git repository

E.A Git repository storing declarative configurations

AnswersD, E

The operator continuously watches Git and applies changes.

Why this answer

A GitOps workflow relies on an operator (such as Argo CD or Flux) that continuously reconciles the actual cluster state with the desired state declared in a Git repository. This operator automatically detects drift and applies changes to ensure the cluster matches the Git source, which is the core feedback loop of GitOps.

Exam trap

CNCF often tests the misconception that a CI/CD pipeline is the core of GitOps, but the trap here is that GitOps replaces manual or pipeline-driven deployments with an automated reconciliation loop driven by an operator and a Git repository as the source of truth.

Practice this question →

101

Multi-Selectmedium

An architecture review is comparing the sidecar proxy model used by service meshes against embedding resilience logic directly in each application's code. Which TWO statements accurately describe advantages of the sidecar proxy approach? (Choose two.)

Select 2 answers

A.Each sidecar can be written in the same language as its application so behaviour stays consistent across the fleet.

B.Retries, timeouts, mutual TLS, and traffic telemetry are applied by the proxy, so application code does not need to implement them.

C.Security and traffic policy can be enforced consistently across services written in different languages and frameworks.

D.Because the sidecar runs in a separate container, it eliminates the extra network hop and reduces request latency compared with in-process libraries.

E.The sidecar automatically rewrites application source code so that existing services gain resilience features without developer effort.

AnswersB, C

Because the sidecar intercepts all inbound and outbound traffic for the Pod, cross-cutting concerns such as retries, timeouts, mutual TLS, and request metrics are handled outside the process. Teams can change policy centrally without rebuilding or redeploying the application, which is the core operational benefit of the sidecar model and the reason it is attractive for polyglot microservice fleets.

Why this answer

The sidecar pattern moves cross-cutting concerns out of application code and into a proxy that intercepts Pod traffic. That lets one team manage retries, timeouts, mutual TLS, and telemetry centrally and apply identical policy to services regardless of language, which is the main architectural advantage over per-language libraries. The pattern does not align proxy language with app language, does not remove a network hop, and does not rewrite source code.

Exam trap

The trap here is believing the sidecar removes network overhead or edits application code, when it actually adds a local hop and only manipulates traffic at runtime.

Practice this question →

102

MCQhard

In event-driven architecture, which pattern is commonly used to decouple producers and consumers, allowing asynchronous communication?

A.Event broker (message queue or event bus)

B.Shared database

C.Circuit breaker pattern

D.Synchronous REST API calls

AnswerA

An event broker sits between producers and consumers, persisting and routing messages so neither side knows the other. This satisfies the asynchronous decoupling constraint: producers publish without waiting, consumers process at their own pace, and neither blocks on the other's availability.

Why this answer

An event broker (message queue or event bus) decouples producers and consumers by allowing producers to publish events without knowing who consumes them, and consumers to subscribe and process events asynchronously. This enables loose coupling, scalability, and resilience. Examples include Apache Kafka, RabbitMQ, and cloud services like AWS EventBridge.

Exam trap

KCNA often tests the difference between synchronous and asynchronous communication; candidates may pick REST API calls because they are familiar, but they do not decouple producers and consumers.

How to eliminate wrong answers

Option B is wrong because a shared database couples producers and consumers through a common schema and creates contention, synchronous locking, and tight coupling. Option C is wrong because the circuit breaker pattern is a resilience mechanism for handling failures in synchronous calls, not a decoupling pattern for asynchronous communication. Option D is wrong because synchronous REST API calls create direct, blocking dependencies between services, which is the opposite of decoupling and asynchronous communication.

Practice this question →

103

Multi-Selectmedium

Which TWO tools are commonly used for GitOps? (Choose two.)

Select 2 answers

A.Flux

B.Jenkins

C.Helm

D.Terraform

E.ArgoCD

AnswersA, E

Flux continuously reconciles cluster state against a Git repository, automatically applying committed manifests without manual intervention. It satisfies the GitOps requirement for declarative, version-controlled delivery, alongside Argo CD. Flux's pull-based controller architecture detects drift and re-syncs, which is precisely the mechanism the question targets.

Why this answer

Flux (A) is a CNCF-graduated GitOps operator that continuously reconciles Kubernetes cluster state with manifests stored in a Git repository, making it a canonical GitOps tool. ArgoCD (E) is likewise a declarative GitOps continuous-delivery controller for Kubernetes that syncs applications from Git and detects drift, so it is also correct. Jenkins (B) is a general-purpose CI automation server; it can trigger GitOps-style pipelines but is not itself a GitOps reconciliation tool.

Helm (C) is a Kubernetes package manager for templating and releasing charts, not a GitOps controller. Terraform (D) is an infrastructure-as-code provisioning tool that applies state from configuration, but it is not a GitOps continuous reconciliation engine.

Exam trap

KCNA often tests the confusion between CI tools (Jenkins), package managers (Helm), and GitOps operators; candidates may pick Helm because it is Kubernetes-related, but it is not a GitOps tool.

Practice this question →

104

Multi-Selecthard

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

Select 2 answers

A.Eliminates need for application monitoring

B.Advanced traffic management capabilities

C.Simplified persistent storage management

D.Automatic mTLS encryption between services

E.Reduced network latency

AnswersB, D

Service meshes provide layer-7 traffic control: weighted routing, canary releases, retries, circuit breaking and fault injection, all configured declaratively rather than coded into each service. This satisfies the stem's requirement for advanced traffic management beyond Kubernetes' basic layer-4 Service load balancing.

Why this answer

Option B is correct because a service mesh provides advanced traffic management capabilities such as fine-grained routing, canary releases, blue-green deployments, retries, timeouts, circuit breaking, and traffic splitting through sidecar proxies, which are core features of tools like Istio and Linkerd. Option D is correct because service meshes automatically provision and rotate mutual TLS (mTLS) certificates between services, providing identity-based authentication and encryption-in-transit without requiring application code changes. Option A is incorrect because a service mesh does not eliminate the need for application monitoring; it enhances observability with metrics, traces, and logs, but monitoring tools and practices are still required.

Option C is incorrect because persistent storage management is handled by storage classes, CSI drivers, and persistent volume claims in Kubernetes, not by a service mesh. Option E is incorrect because service meshes typically add a sidecar proxy hop that can introduce slight latency overhead rather than reduce network latency.

Exam trap

CNCF often tests the misconception that a service mesh reduces latency or replaces monitoring, when in fact it adds a small overhead and complements, rather than replaces, existing monitoring tools.

Practice this question →

105

Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First deploy the app, then define and create the LoadBalancer service, retrieve the IP, and access it.

Practice this question →

106

MCQeasy

A startup is building a cloud-native application and wants to adopt a packaging format that bundles application code and its dependencies into a single immutable artifact that can run consistently across environments. Which technology BEST meets this requirement?

A.Configuration management script

B.Virtual machine snapshot

C.Source code repository

D.Container image

AnswerD

A container image packages application code, runtime, libraries, and settings into a single immutable artifact. It runs consistently on any container runtime that supports the image format, such as Docker or containerd. This immutability ensures identical behavior from development to production, which is a core cloud-native practice for portability and reproducibility.

Why this answer

Container images are the standard cloud-native packaging format because they encapsulate the application and its dependencies in an immutable, portable unit. This eliminates environment drift and ensures that what is tested is what runs in production. Orchestrators like Kubernetes can then schedule these images consistently across clusters.

Exam trap

The trap here is confusing packaging with automation or storage; a script or repository may help build or store code, but only a container image bundles code and dependencies into a single immutable artifact.

Practice this question →

107

MCQmedium

Which of the following is an example of Infrastructure as Code (IaC) tool?

A.Kubernetes

B.Terraform

C.Docker

D.Prometheus

AnswerB

Terraform declaratively defines and provisions infrastructure such as networks, compute and storage from configuration files, then applies those definitions through providers. That declarative, version-controlled provisioning is precisely what the stem asks for as an IaC example, unlike configuration-management or CI tools.

Why this answer

Terraform is a widely used Infrastructure as Code (IaC) tool that allows you to define and provision infrastructure using a declarative configuration language. It supports multiple cloud providers and on-premises environments, enabling version control, automation, and repeatability. Kubernetes, Docker, and Prometheus serve different purposes: container orchestration, containerization, and monitoring, respectively.

Exam trap

The trap is that Kubernetes and Docker are often used alongside IaC, so candidates may mistakenly classify them as IaC tools, but the exam expects you to identify tools specifically designed for provisioning infrastructure declaratively.

How to eliminate wrong answers

Option A is wrong because Kubernetes is a container orchestration platform, not an IaC tool, although it can be managed via IaC. Option B is correct because Terraform is specifically designed for IaC. Option C is wrong because Docker is a containerization platform for packaging applications, not for provisioning infrastructure.

Option D is wrong because Prometheus is a monitoring and alerting toolkit, not an IaC tool.

Practice this question →

108

MCQeasy

A team is adopting cloud-native architecture and wants to ensure that a single failing component does not take down the entire application. They are reviewing the design of their microservices deployment. Which characteristic of cloud-native architecture is MOST directly related to limiting the impact of a component failure?

A.Immutable infrastructure

B.Manual configuration of each service instance

C.Using a monolithic deployment for all services

D.Loose coupling and isolation between services

AnswerD

Loose coupling and isolation mean services interact through well-defined interfaces and do not share internal state or runtime resources unnecessarily. When one service fails, others can continue operating independently. This directly limits the blast radius of a failure and is the cloud-native characteristic most relevant to the scenario.

Why this answer

Loose coupling and isolation allow services to fail independently without cascading failures across the application. By keeping services separate and communicating through stable interfaces, a failure in one service does not automatically bring down others. Immutable infrastructure, monolithic deployment, and manual configuration do not provide that fault containment, so they do not satisfy the stated goal.

Exam trap

The trap here is confusing a general cloud-native practice, such as immutable infrastructure, with the specific characteristic that limits failure impact, which is isolation and loose coupling.

Practice this question →

109

MCQhard

In the context of the 12-factor app methodology, which factor requires that an app's configuration be stored in environment variables?

A.Config

B.Dependencies

C.Codebase

D.Backing services

AnswerA

The Config factor mandates strict separation of configuration from code, storing deploy-specific values such as credentials and endpoints in environment variables rather than committed files, so the same build can be promoted across environments unchanged.

Why this answer

The Config factor of the 12-factor app methodology explicitly states that configuration should be stored in environment variables, not in code or config files checked into the repository. This separates config that varies between deploys (database URLs, API keys, feature flags) from the immutable codebase, enabling the same artifact to be promoted across environments. Environment variables are language-agnostic and easily injected by the platform.

Exam trap

KCNA often tests whether candidates confuse Config with Backing Services — both involve external resources, but only Config mandates environment-variable storage.

How to eliminate wrong answers

Option B is wrong because the Dependencies factor is about explicitly declaring and isolating dependencies (e.g., via a package manager), not about configuration storage. Option C is wrong because the Codebase factor mandates a single codebase tracked in revision control with many deploys, not configuration handling. Option D is wrong because Backing services treats databases, queues, and caches as attached resources referenced via config, but the factor that specifies environment variables is Config.

Practice this question →

110

MCQhard

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

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

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

C.Create a golden AMI using Packer with all required configurations, then use Auto Scaling groups with a launch template that references the AMI and enable instance refresh for updates.

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

AnswerC

Packer builds a golden AMI containing every package and kernel parameter, and Auto Scaling groups with instance refresh replace nodes from that image, eliminating SSH drift. Nodes become identical, immutable and reproducible, satisfying the CTO's requirement on EC2.

Why this answer

It uses a golden AMI built with Packer to create identical, immutable nodes that are reproducible via Auto Scaling groups and launch templates. This approach ensures that every EC2 instance launched has the exact same kernel parameters, packages, and configuration, eliminating configuration drift. Instance refresh allows rolling updates to the AMI without manual intervention, aligning with the goal of immutable infrastructure.

Exam trap

The trap here is that candidates often confuse configuration management (Option A) with immutability, not realizing that periodic enforcement still allows drift and does not guarantee identical nodes at all times.

How to eliminate wrong answers

Option A is wrong because configuration management tools like Ansible enforce desired state via periodic runs, which still allows drift between runs and does not achieve true immutability; nodes remain mutable and can deviate. Option B is wrong because node labels and taints only control workload scheduling, they do not enforce node configuration or prevent nodes from being modified via SSH. Option D is wrong because a DaemonSet running a privileged container can attempt to enforce configuration but cannot prevent manual SSH changes or guarantee identical state across nodes, and it introduces security risks without solving the root cause of drift.

Practice this question →

111

MCQhard

Which Kubernetes resource is commonly used to implement the sidecar pattern for injecting a service mesh proxy?

A.NetworkPolicy

B.Service

C.MutatingAdmissionWebhook

D.ConfigMap

AnswerC

A MutatingAdmissionWebhook intercepts pod creation requests and mutates the pod specification, which is how sidecar containers such as service mesh proxies are injected automatically. This admission-time mutation mechanism is the standard implementation of sidecar injection in Kubernetes.

Why this answer

A MutatingAdmissionWebhook intercepts Pod creation requests and automatically injects a sidecar container (e.g., Envoy or Linkerd-proxy) into the Pod spec. This is the standard mechanism used by service mesh control planes like Istio and Linkerd to transparently add the proxy without modifying application manifests.

Exam trap

CNCF often tests the misconception that a Service or NetworkPolicy is responsible for sidecar injection, when in fact only a mutating admission webhook can automatically modify Pod specs at creation time.

How to eliminate wrong answers

Option A is wrong because NetworkPolicy controls ingress/egress traffic at the network layer using labels and CIDR rules, not container injection. Option B is wrong because a Service provides a stable IP and DNS name for Pod discovery and load balancing, not sidecar injection. Option D is wrong because a ConfigMap stores non-sensitive configuration data as key-value pairs or files, but cannot mutate Pod specs at creation time.

Practice this question →

112

MCQhard

In event-driven architecture, which component is responsible for decoupling event producers from consumers?

A.Event broker

B.Event consumer

C.Event producer

D.API gateway

AnswerA

An event broker sits between producers and consumers, receiving published events and routing them to subscribers, so neither side needs direct knowledge of the other. This intermediary role satisfies the decoupling constraint: producers publish without waiting, and consumers subscribe independently, enabling asynchronous, scalable communication across the event-driven architecture.

Why this answer

The event broker (e.g., Apache Kafka, RabbitMQ, or AWS EventBridge) acts as an intermediary that receives events from producers and forwards them to consumers. By decoupling the two, the producer does not need to know the consumer's location or status, and the consumer does not need to be actively listening when the event is published. This enables asynchronous, scalable, and fault-tolerant communication in event-driven architectures.

Exam trap

CNCF often tests the distinction between synchronous and asynchronous communication patterns, and the trap here is that candidates mistakenly think an API gateway (which handles synchronous requests) can decouple producers and consumers in an event-driven architecture, when in fact it only routes requests without persistent event storage or asynchronous delivery.

How to eliminate wrong answers

Option B (Event consumer) is wrong because the consumer is the recipient of events, not the component that decouples producers from consumers; it relies on the broker for decoupling. Option C (Event producer) is wrong because the producer generates events but has no built-in mechanism to decouple itself from consumers without an intermediary. Option D (API gateway) is wrong because an API gateway is designed for synchronous request-response patterns (e.g., REST APIs) and does not provide the persistent, asynchronous event buffering and routing that decouples producers from consumers.

Practice this question →

113

MCQmedium

A company wants to manage its Kubernetes resources using Git as the single source of truth, with automated synchronization. Which approach should they use?

A.Using Helm charts without version control

B.Infrastructure as Code with Terraform

C.Using kubectl apply -f with a CI/CD pipeline

D.GitOps with ArgoCD or Flux

AnswerD

GitOps treats a Git repository as the declarative source of truth, with agents such as ArgoCD or Flux continuously reconciling cluster state to match committed manifests. This delivers the automated synchronisation the company requires, detecting drift and reapplying desired configuration without manual kubectl intervention.

Why this answer

GitOps uses Git as the declarative source of truth for cluster state, with an in-cluster agent (ArgoCD or Flux) continuously reconciling the live cluster to match the repository. This provides automated synchronization, drift detection, and auditable change history via Git commits and pull requests. It is the canonical answer when the requirement is 'Git as single source of truth with automated sync.'

Exam trap

The trap is confusing IaC with GitOps — candidates pick Terraform because it is 'infrastructure as code,' but GitOps specifically means continuous reconciliation of Kubernetes state from Git, which Terraform does not do.

How to eliminate wrong answers

Option A is wrong because Helm charts without version control lose the auditability and single-source-of-truth property that GitOps requires. Option B is wrong because Terraform is infrastructure-as-code for provisioning cloud resources, not for continuously reconciling Kubernetes manifests to a cluster. Option C is wrong because kubectl apply from a CI pipeline is push-based and imperative; it lacks continuous reconciliation and drift correction, so it is not GitOps.

Practice this question →

114

MCQmedium

What is the primary purpose of a service mesh in a cloud-native architecture?

A.To compile application code

B.To provide a dedicated infrastructure layer for handling service-to-service communication

C.To replace container orchestration

D.To store application configuration

AnswerB

A service mesh supplies a dedicated infrastructure layer, typically via sidecar proxies, that handles service-to-service communication concerns such as traffic routing, mutual TLS, retries and observability. This offloads those functions from application code, satisfying the cloud-native communication requirement.

Why this answer

A service mesh provides a dedicated infrastructure layer for managing service-to-service communication, typically using sidecar proxies. It handles traffic management, security, and observability without requiring changes to application code. This allows developers to focus on business logic while the mesh handles cross-cutting concerns.

Exam trap

KCNA often tests the confusion between service mesh and container orchestration, leading candidates to think a service mesh replaces Kubernetes or handles scaling, when it actually focuses on communication.

How to eliminate wrong answers

Option A is wrong because service meshes do not compile application code; that is the role of build tools and compilers. Option C is wrong because service meshes complement container orchestration (like Kubernetes) rather than replace it; orchestration handles deployment and scaling, while the mesh handles communication. Option D is wrong because storing application configuration is typically handled by configuration management systems (e.g., ConfigMaps, Consul), not service meshes.

Practice this question →

115

Multi-Selecteasy

Which TWO of the following are examples of Infrastructure as Code (IaC) tools? (Choose two.)

Select 2 answers

A.Docker

B.Terraform

C.Kubernetes

D.Prometheus

E.Pulumi

AnswersB, E

Terraform is an IaC tool by HashiCorp.

Why this answer

Terraform (B) is an Infrastructure as Code (IaC) tool that uses declarative configuration files (HashiCorp Configuration Language, HCL) to define and provision cloud and on-premises resources. It manages the full lifecycle of infrastructure through a state file and provider plugins, enabling version-controlled, repeatable deployments.

Exam trap

CNCF often tests the distinction between containerization/orchestration tools (Docker, Kubernetes) and actual IaC tools, leading candidates to confuse tools that manage applications with those that provision infrastructure.

Practice this question →

116

Multi-Selecthard

Which THREE of the following are resiliency patterns commonly used in cloud native applications? (Choose three.)

Select 3 answers

A.Retry

B.Timeout

C.Singleton pattern

D.Circuit breaker

E.Round-robin load balancing

AnswersA, B, D

Retrying failed operations can handle transient failures.

Why this answer

The Retry pattern is a fundamental resiliency mechanism in cloud-native applications. When a transient failure occurs (e.g., a network timeout or a temporary database unavailability), the application automatically reattempts the failed operation. This pattern is often implemented with exponential backoff and jitter to avoid overwhelming the downstream service, as seen in libraries like Netflix Hystrix or Kubernetes client-go retry logic.

Exam trap

CNCF often tests the distinction between design patterns (like Singleton) and cloud-native resiliency patterns (like Retry, Timeout, Circuit Breaker), so candidates mistakenly select Singleton because it is a well-known pattern, but it does not address fault tolerance or failure recovery.

Practice this question →

117

MCQeasy

Which CNCF project provides a graduated service mesh implementation that includes features like traffic management, security, and observability?

A.Linkerd

B.Consul

C.Envoy

D.Istio

AnswerA

Correct. Linkerd is a graduated CNCF service mesh.

Why this answer

Linkerd is a graduated CNCF project that provides a service mesh with features like traffic management, security (mTLS), and observability. Istio is also a service mesh but is incubating, not graduated. Envoy is a graduated proxy but not a full service mesh.

Consul is not a CNCF project.

Practice this question →

118

MCQhard

In a serverless architecture using Knative, what happens to a service that has not received traffic for an extended period?

A.It throws an error and must be redeployed

B.It continues running with one replica to reduce cold start latency

C.It scales down to zero replicas and is reactivated on the next request

D.It is automatically deleted

AnswerC

Knative's autoscaler, via the Activator and queue-proxy, reduces idle services to zero replicas after the configured scale-to-zero window, eliminating compute cost. The next incoming request is buffered by the Activator, which spins up a pod and forwards traffic.

Why this answer

Knative scales to zero when idle, meaning no pods are running, thus no cost incurred.

Practice this question →

119

Multi-Selecthard

Which THREE of the following are features typically provided by a service mesh? (Choose three.)

Select 3 answers

A.Observability through metrics and tracing

B.Auto-scaling of pods based on CPU

C.Traffic management between services

D.Security with mutual TLS (mTLS)

E.Service discovery

AnswersA, C, D

Service meshes collect per-request telemetry from sidecar proxies, exposing golden signals such as latency, error rates and request volume, plus distributed traces across service hops. This satisfies the stem's observability feature, giving uniform metrics and tracing without instrumenting each application.

Why this answer

A service mesh like Istio or Linkerd provides observability by collecting metrics and distributed traces from the sidecar proxies (e.g., Envoy) that intercept service-to-service traffic, so option A is correct. It also delivers traffic management capabilities such as routing rules, retries, timeouts, circuit breaking, and canary or blue-green deployments, making option C correct. Additionally, a service mesh secures service-to-service communication with mutual TLS (mTLS), automatically issuing and rotating certificates and enforcing encryption and identity between workloads, so option D is correct.

Option B is wrong because pod auto-scaling based on CPU is handled by the Kubernetes Horizontal Pod Autoscaler (HPA), not by a service mesh. Option E is wrong because service discovery is a core Kubernetes function (via kube-dns/CoreDNS and Services), not a feature typically attributed to the service mesh itself.

Exam trap

KCNA often tests the confusion between service mesh features and orchestration features, leading candidates to select auto-scaling or service discovery as mesh responsibilities.

Practice this question →

120

MCQmedium

A team is implementing a multi-cloud strategy to avoid vendor lock-in. Which Kubernetes feature is most helpful for abstracting the underlying cloud provider?

A.Services

B.ConfigMaps

C.Namespaces

D.Kubernetes API

AnswerD

The Kubernetes API provides a consistent declarative interface that abstracts underlying infrastructure, so workloads defined against it remain portable across clouds. This decoupling from provider-specific APIs directly satisfies the vendor lock-in avoidance goal of the multi-cloud strategy.

Why this answer

The Kubernetes API is the abstraction layer that decouples workloads from any specific cloud provider — manifests, controllers, and clients interact with the API server, not with AWS, GCP, or Azure APIs directly. This portability is what enables multi-cloud and avoids vendor lock-in. While Services, ConfigMaps, and Namespaces are API objects, the API itself is the unifying abstraction.

Exam trap

KCNA often tests whether candidates confuse a specific API object (Service, ConfigMap, Namespace) with the API itself as the abstraction layer — the trap is picking a familiar resource instead of the unifying API.

How to eliminate wrong answers

Option A is wrong because Services provide stable networking and load balancing within a cluster, but they do not abstract cloud provider differences — LoadBalancer Services actually depend on cloud-specific controllers. Option B is wrong because ConfigMaps store configuration data and do not abstract infrastructure or provider APIs. Option C is wrong because Namespaces provide logical isolation and resource scoping, not provider abstraction.

Practice this question →

121

MCQmedium

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

A.Change the database service type from ClusterIP to NodePort.

B.Implement read replicas for the database and configure the application to use them for read operations.

C.Increase the number of application pod replicas.

D.Store database configuration in a ConfigMap to improve startup time.

AnswerB

Read replicas offload read queries from the primary database, distributing CPU load across additional nodes so the CPU-bound database pods are no longer saturated. Configuring the application to route reads to replicas directly reduces the wait time for application pods, addressing the bottleneck identified during the flash sale.

Why this answer

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

Exam trap

CNCF often tests the misconception that scaling application pods (Option C) is a universal fix for performance issues, but here it would amplify the database bottleneck rather than resolve it.

How to eliminate wrong answers

Option A is wrong because changing the service type from ClusterIP to NodePort exposes the database externally but does nothing to reduce its CPU load or improve query processing speed. Option C is wrong because increasing application pod replicas would only increase the number of requests hitting the already CPU-bound database, worsening the bottleneck. Option D is wrong because storing database configuration in a ConfigMap improves manageability and startup time but has no impact on runtime database CPU utilization or query latency.

Practice this question →

122

Multi-Selecteasy

Which TWO of the following are examples of Infrastructure as Code (IaC) tools? (Choose 2.)

Select 2 answers

A.Terraform

B.kubectl

C.Pulumi

D.Helm

E.Docker Compose

AnswersA, C

Terraform declares infrastructure in HashiCorp Configuration Language and reconciles real resources against that desired state, making it a declarative provisioning tool. This satisfies the IaC requirement, unlike configuration-management or container-orchestration tools that operate after infrastructure already exists.

Why this answer

Terraform (A) is a declarative Infrastructure as Code tool that uses HCL configuration files and providers to provision and manage cloud and on-premises resources through a state file. Pulumi (C) is also an IaC tool, allowing infrastructure to be defined in general-purpose programming languages such as TypeScript, Python, Go, and C# and deployed via its engine. kubectl (B) is a command-line client for interacting with Kubernetes clusters, not an IaC provisioning tool. Helm (D) is a Kubernetes package manager that templates and deploys manifests, and Docker Compose (E) orchestrates multi-container Docker applications from a YAML file; both manage application deployment rather than provisioning infrastructure as code.

Exam trap

KCNA often tests the distinction between infrastructure provisioning tools (Terraform, Pulumi) and cluster/application tooling (kubectl, Helm, Docker Compose), so candidates who conflate 'managing YAML' with 'Infrastructure as Code' pick Helm or kubectl incorrectly.

Practice this question →

123

MCQmedium

A team wants to deploy a serverless function that scales to zero when not in use. Which CNCF project is specifically designed for this purpose?

A.Helm

B.Prometheus

C.Envoy

D.Knative

AnswerD

Knative extends Kubernetes with request-driven autoscaling, including scale-to-zero, which directly satisfies the stem's requirement that idle functions consume no compute. Its Serving component activates pods on incoming requests and removes them when traffic stops, making it the CNCF project purpose-built for serverless workloads.

Why this answer

Knative is the correct answer because it is a CNCF project built on Kubernetes that provides a serverless platform specifically designed to scale workloads to zero when not in use. It achieves this through its Serving component, which automatically scales pods down to zero replicas based on traffic, and scales up from zero on the first request, enabling true serverless behavior.

Exam trap

CNCF often tests the distinction between infrastructure tools (Helm, Prometheus, Envoy) and serverless platforms (Knative), trapping candidates who confuse package management, monitoring, or proxy functions with serverless scaling capabilities.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys applications using charts, but it does not provide any serverless scaling or scale-to-zero functionality. Option B is wrong because Prometheus is a monitoring and alerting toolkit that collects metrics, not a serverless platform; it cannot scale functions to zero. Option C is wrong because Envoy is a high-performance sidecar proxy used for service mesh communication (e.g., in Istio), not a serverless framework for scaling functions to zero.

Practice this question →

124

Multi-Selectmedium

Which TWO of the following are principles of the 12-factor app? (Choose two.)

Select 2 answers

A.Monolithic deployment

B.Stateful sessions

C.Config

D.Disposability

E.Manual provisioning

AnswersC, D

Config is a 12-factor principle.

Why this answer

Config is a core principle of the 12-factor app methodology, which mandates strict separation of configuration from code. Configuration (such as database URLs, credentials, or hostnames) must be stored in environment variables, not hardcoded in the application source. This allows the same codebase to be deployed across different environments (development, staging, production) without modification, adhering to the principle of config-driven behavior.

Exam trap

CNCF often tests the 12-factor app principles by pairing a correct principle like 'Config' with a plausible-sounding but incorrect option like 'Stateful sessions', exploiting the common misconception that statefulness is acceptable in cloud-native apps when in fact it must be externalized.

Practice this question →

125

MCQhard

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

A.It stores events and enables asynchronous communication between producers and consumers

B.It executes business logic in response to events

C.It provides a user interface to view events

D.It converts events into HTTP requests

AnswerA

An event broker decouples producers from consumers by persisting events in a durable log, letting each consumer read independently at its own pace. This satisfies the asynchronous communication requirement in the stem: producers publish without waiting for consumers, and consumers retrieve events later, even after downtime.

Why this answer

An event broker acts as a central intermediary that receives events from producers, stores them durably (often in a log or queue), and delivers them to consumers asynchronously. This decouples producers and consumers, allowing them to operate independently without blocking or direct knowledge of each other. Technologies like Apache Kafka, RabbitMQ, or AWS Kinesis exemplify this role by persisting events and enabling replay, fan-out, and load-leveling.

Exam trap

CNCF often tests the distinction between the broker's role (storage and routing) and the consumer's role (processing logic), so candidates mistakenly pick B when they conflate event handling with event brokering.

How to eliminate wrong answers

Option B is wrong because executing business logic in response to events is the role of an event consumer or a serverless function (e.g., AWS Lambda), not the broker itself — the broker only routes and stores events. Option C is wrong because providing a user interface to view events is a monitoring or management tool (e.g., Kafka UI or Confluent Control Center), not a core function of the event broker. Option D is wrong because converting events into HTTP requests is a protocol translation task typically performed by an adapter or gateway (e.g., Kafka REST Proxy), not the event broker's native role — brokers use their own protocols (e.g., Kafka protocol, AMQP) for communication.

Practice this question →

126

Multi-Selectmedium

Which TWO of the following are benefits of using a service mesh? (Choose two.)

Select 2 answers

A.Improved observability of service-to-service communication

B.Direct management of virtual machines

C.Automated container image building

D.Replacing the need for a container runtime

E.Traffic management capabilities such as canary deployments

AnswersA, E

A service mesh injects sidecar proxies alongside each workload, so every service-to-service request passes through them. Those proxies emit uniform telemetry — latency, error rates, request volume — without application code changes, directly satisfying the stem's observability benefit for inter-service communication.

Why this answer

Service mesh provides improved observability and enables traffic management features like canary deployments.

Practice this question →

127

MCQmedium

An organization wants to manage infrastructure using code to ensure consistent and repeatable deployments across multiple cloud providers. Which tool is MOST suitable for this multi-cloud Infrastructure as Code approach?

A.Terraform

B.Kuberntes manifests

C.AWS CloudFormation

D.Azure Resource Manager Templates

AnswerA

Terraform uses providers to manage resources across AWS, Azure and Google Cloud from one declarative configuration and state file. This provider-based architecture delivers consistent, repeatable multi-cloud infrastructure as code, which single-cloud native tools such as CloudFormation cannot match.

Why this answer

Terraform is provider-agnostic and supports AWS, Azure, GCP, and hundreds of other providers through a plugin architecture, making it the most suitable tool for defining infrastructure as code across multiple clouds with a single workflow and state model. Its HCL configuration and plan/apply cycle give consistent, repeatable deployments regardless of the target cloud.

Exam trap

KCNA often tests whether candidates recognize that cloud-native IaC tools (CloudFormation, ARM) are single-cloud by design, so they incorrectly pick one of them for a multi-cloud requirement.

How to eliminate wrong answers

Option B is wrong because Kubernetes manifests describe workloads and cluster resources, not cloud infrastructure — they cannot provision VPCs, IAM roles, or managed databases across providers. Option C is wrong because AWS CloudFormation is proprietary to AWS and cannot manage Azure or GCP resources. Option D is wrong because Azure Resource Manager templates are proprietary to Azure and cannot manage AWS or GCP resources.

Practice this question →

128

MCQeasy

A startup is building a cloud-native application and wants to ensure that its services can be discovered and communicated with dynamically as they scale up and down. Which CNCF project provides a distributed key-value store that is commonly used for service discovery and configuration management in Kubernetes?

A.Prometheus

B.Jaeger

C.Fluentd

D.etcd

AnswerD

etcd is a distributed key-value store that provides reliable data storage for service discovery and configuration management. In Kubernetes, etcd is used as the backing store for all cluster data, and it is also used by many cloud-native applications for service discovery and dynamic configuration. Its watch feature allows clients to be notified of changes, enabling dynamic reconfiguration.

Why this answer

etcd is the correct choice because it is a distributed key-value store designed for reliable data storage, often used for service discovery and configuration management. In Kubernetes, etcd stores the entire cluster state, and many cloud-native applications use it directly for dynamic configuration and service registration. Its strong consistency and watch capabilities make it ideal for these tasks.

Exam trap

The trap here is confusing monitoring or logging tools with a key-value store for service discovery.

Practice this question →

129

MCQhard

An engineering team runs a Kubernetes cluster and wants to ensure that a critical payment service continues to function during a partial network partition between two availability zones. The service currently depends on a single external authentication API in one zone. Which architectural change BEST supports the goal of maintaining payment processing during the partition?

A.Deploy the authentication API in the same zone as the payment service only

B.Increase the replica count of the payment service to three

C.Add a circuit breaker and a local authentication cache to the payment service

D.Move the payment service to a serverless platform

AnswerC

A circuit breaker stops calls to a failing dependency and allows the payment service to continue operating, while a local authentication cache can provide recently validated credentials during the partition. Together they reduce the impact of the external authentication API becoming unreachable, which directly supports continued payment processing during a network partition.

Why this answer

During a network partition, the external authentication API may become unreachable. A circuit breaker prevents the payment service from repeatedly calling a failing dependency, and a local authentication cache allows recently validated credentials to be used while the dependency is unavailable. These changes directly support continued payment processing.

Replica scaling, single-zone placement, or changing the compute platform do not address the dependency failure.

Exam trap

The trap here is assuming that scaling the service or moving it to another platform solves an external dependency failure, when the real issue is the unreachable authentication API.

Practice this question →

130

MCQeasy

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

A.Loose coupling

B.Immutable infrastructure

C.Statelessness

D.Service discovery

AnswerA

Loose coupling lets each microservice be changed, deployed and scaled without coordinating with others, since services interact through well-defined interfaces rather than tight dependencies. That directly satisfies the team's requirement for independent development, deployment and scaling.

Why this answer

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

Exam trap

The trap here is that candidates often confuse 'statelessness' with 'loose coupling' because both enable scaling, but statelessness is about session data management, not the architectural independence of service development and deployment.

How to eliminate wrong answers

Option B (Immutable infrastructure) is wrong because it focuses on replacing rather than modifying infrastructure components, which supports consistency and reliability but does not directly address independent development and scaling of microservices. Option C (Statelessness) is wrong because it refers to services not storing session state locally, which aids scalability but is not the primary principle for independent development and deployment; stateful services can also be loosely coupled. Option D (Service discovery) is wrong because it is a mechanism for services to find each other dynamically, which enables loose coupling but is not the principle itself; it is an implementation detail that supports the broader goal of loose coupling.

Practice this question →

131

Multi-Selecthard

Which THREE are key characteristics of event-driven architecture? (Choose three.)

Select 3 answers

A.Event processing can trigger multiple downstream actions

B.Requires a central database for state

C.Synchronous communication between components

D.Components communicate by emitting and reacting to events

E.Loose coupling between event producers and consumers

AnswersA, D, E

A single published event can be delivered to many independent subscribers, each performing its own downstream action. This fan-out satisfies the stem's requirement, since one producer action propagates to multiple consumers without the producer orchestrating or even knowing about them.

Why this answer

Event-driven architecture is based on producing, detecting, and reacting to events, with loose coupling between components and asynchronous communication.

Practice this question →

132

MCQmedium

A team wants every microservice to ship its logs and metrics to a central backend, and they want to avoid running a separate agent container inside each application Pod. Which cloud native approach BEST fits this requirement while keeping collection decoupled from the application?

A.Run a logging and metrics agent as a DaemonSet so one agent instance runs on every node and collects from all Pods on that node.

B.Configure each application to push directly to the backend using its own vendor SDK and credentials.

C.Create a single centralized collector Deployment with one replica that all Pods send telemetry to.

D.Add a sidecar container to every application Pod that forwards logs and metrics to the backend.

AnswerA

A DaemonSet guarantees one agent Pod per eligible node, so collection is handled at the node level rather than inside each application Pod. Applications write to standard output or a node-local path, and the node agent forwards data to the central backend. This decouples telemetry from application containers, requires no per-service agent container, and automatically covers new nodes as they join.

Why this answer

Running the collection agent as a DaemonSet places exactly one agent on each node, where it can read container logs and node-local metrics for every Pod on that node. That decouples telemetry from application containers, eliminates per-Pod sidecars, and scales naturally with the cluster. Sidecars, application push, and a single centralized collector all either violate the no-per-Pod-agent requirement or introduce coupling and availability problems.

Exam trap

The trap here is reaching for a sidecar because telemetry is per-Pod, when a per-node DaemonSet agent already covers all Pods without touching each workload.

Practice this question →

133

MCQmedium

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

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

B.The readiness probe is checking /ready which is not returning a 200 OK response.

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

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

AnswerB

Kubernetes only adds a pod to a Service's Endpoints when its readiness probe succeeds. If /ready returns anything other than 200 OK, the pod stays NotReady, so the Service has no endpoints despite the containers running.

Why this answer

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

Exam trap

CNCF often tests the distinction between readiness and liveness probes: candidates confuse a failing liveness probe (which restarts pods) with a failing readiness probe (which removes traffic but keeps the pod running).

How to eliminate wrong answers

Option A is wrong because a short periodSeconds does not cause the probe to overload the container; it merely increases the frequency of checks, and the symptom would be high CPU usage, not missing endpoints. Option C is wrong because the readiness probe is checking /ready, not /healthz; the absence of /healthz is irrelevant unless that path is configured. Option D is wrong because a failing liveness probe would restart the pod, but the pods are running, so the liveness probe is passing.

Practice this question →

134

Multi-Selectmedium

A company is evaluating cloud-native observability practices for its Kubernetes-based microservices. Which TWO practices are essential for achieving effective observability? (Choose two.)

Select 2 answers

A.Aggregating logs into a centralized system

B.Collecting metrics from all services and infrastructure

C.Storing all data in a single monolithic database

D.Disabling health checks to reduce overhead

E.Using only manual inspection of individual pod logs

AnswersA, B

Logs capture discrete events and errors that are crucial for debugging and root cause analysis. Centralizing logs from distributed services allows correlation across components. In dynamic environments where pods are ephemeral, centralized log aggregation is essential to retain and query logs, making it a fundamental observability practice.

Why this answer

Effective observability in cloud-native systems relies on the three pillars: metrics, logs, and traces. Collecting metrics and aggregating logs are foundational because they provide quantitative and qualitative insights into distributed applications. Together they enable monitoring, alerting, and debugging across ephemeral and dynamic environments.

Exam trap

The trap here is equating observability with simple log checking or assuming that reducing overhead by disabling health checks is beneficial, when in fact observability requires automated collection of metrics and centralized logs.

Practice this question →

135

MCQmedium

Which component of an API gateway pattern is responsible for routing requests to the appropriate microservice based on the request path?

A.API Gateway

B.Load balancer

C.Service registry

D.Sidecar proxy

AnswerA

The API Gateway is the entry point that receives client requests and forwards each one to the correct backend microservice by matching the request path against configured routes. It also handles cross-cutting concerns such as authentication, rate limiting and protocol translation before routing.

Why this answer

In an API gateway pattern, the API Gateway is the entry point that receives client requests and routes them to the appropriate backend microservice based on the request path, method, or other attributes. It acts as a reverse proxy and centralizes cross-cutting concerns such as authentication, rate limiting, and request transformation.

Exam trap

KCNA often tests the distinction between routing, discovery, and load balancing — the trap is choosing 'load balancer' or 'service registry' because they are related to traffic management, when the question specifically asks about path-based routing to microservices.

How to eliminate wrong answers

Option B is wrong because a load balancer distributes traffic across multiple instances of the same service but does not perform path-based routing to different microservices — it operates at a lower level (L4 or L7) without application-aware routing logic. Option C is wrong because a service registry maintains a catalog of available service instances and their locations for service discovery; it does not route requests itself. Option D is wrong because a sidecar proxy handles communication for a single service instance (e.g., in a service mesh) but is not the central routing component that maps request paths to services.

Practice this question →

136

Multi-Selectmedium

Which TWO of the following are principles of the 12-factor app methodology? (Choose two.)

Select 2 answers

A.Perform manual deployment to avoid automation errors

B.Maximize robustness through stateful sessions

C.Ensure fast startup and graceful shutdown (disposability)

D.Build monolithic applications for simplicity

E.Store configuration in environment variables

AnswersC, E

Disposability is a core 12-factor principle: processes should start quickly and shut down gracefully on SIGTERM, enabling rapid scaling, deployment and recovery. This satisfies the stem's requirement for a genuine factor, distinct from build/release/run separation or config handling.

Why this answer

Option C is correct because the 12-factor methodology's Disposability factor explicitly requires processes to start fast and shut down gracefully, enabling rapid scaling, quick deployment of new code, and resilience to sudden termination. Option E is correct because the Config factor mandates storing configuration in the environment (environment variables) rather than in code, so the same build can be deployed across environments without modification. Option A is wrong because 12-factor apps favor automated, repeatable deployments and CI/CD, not manual deployment.

Option B is wrong because 12-factor apps should be stateless processes, storing any needed state in backing services such as databases or caches, not in sticky sessions. Option D is wrong because 12-factor apps are typically decomposed into smaller, independent services rather than built as a single monolith.

Exam trap

KCNA often tests the specific factors of the 12-factor app, and candidates may confuse 'disposability' with 'statelessness' or overlook that configuration should be in environment variables, not files.

Practice this question →

137

MCQhard

Which of the following is a key difference between a service mesh and an API gateway?

A.Service mesh is only used in multi-cloud environments, while API gateway is for single-cloud

B.Service mesh manages east-west traffic between services, while API gateway manages north-south traffic from external clients

C.Service mesh provides authentication and authorization, while API gateway does not

D.Service mesh handles north-south traffic, while API gateway handles east-west traffic

AnswerB

A service mesh deploys sidecar proxies alongside each workload, governing east-west service-to-service calls with mutual TLS, retries and telemetry. An API gateway instead fronts north-south ingress, handling external client authentication, rate limiting and routing into the cluster. This split directly answers the stem's request for a key architectural difference.

Why this answer

A service mesh (Istio, Linkerd) operates at the data-plane level, intercepting east-west traffic between internal microservices for mTLS, retries, and observability. An API gateway (Kong, Apigee, AWS API Gateway) sits at the network edge and manages north-south traffic — external client requests entering the cluster — handling authentication, rate limiting, and routing.

Exam trap

KCNA often tests the directionality mnemonic — candidates confuse east-west (service mesh) with north-south (API gateway), or assume only one layer handles auth, when in reality both do at different scopes.

How to eliminate wrong answers

Option A is wrong because service mesh is not limited to multi-cloud; it works in single-cluster, single-cloud, and on-premises Kubernetes environments. Option C is wrong because API gateways absolutely provide authentication and authorization (API keys, OAuth2, JWT validation) — this is one of their core functions. Option D is wrong because it reverses the traffic directions: service mesh handles east-west (service-to-service), API gateway handles north-south (external-to-internal).

Practice this question →

138

MCQhard

Which of the following best describes the GitOps pattern?

A.Imperative commands applied to the cluster and tracked in Git

B.Using Git as a backup for Kubernetes manifests

C.Using Git hooks to trigger CI/CD pipelines

D.Declarative configuration stored in Git, with automated deployment via a controller

AnswerD

GitOps stores the entire desired state declaratively in Git as the single source of truth, and a controller running in the cluster continuously reconciles live state to match it, automating deployment without manual kubectl or pipeline pushes.

Why this answer

GitOps is a pattern where the entire system's desired state is declared in a Git repository, and an automated controller (such as Argo CD or Flux) continuously reconciles the live cluster state with that declarative configuration. This ensures that Git is the single source of truth, and any drift from the declared state is automatically corrected without manual intervention.

Exam trap

CNCF often tests the misconception that GitOps is simply about storing YAML files in Git or using Git as a trigger for CI/CD, when the defining characteristic is the automated reconciliation loop that enforces the desired state from Git.

How to eliminate wrong answers

Option A is wrong because GitOps relies on declarative configuration, not imperative commands; imperative commands (like kubectl run) are applied directly and are not idempotent or easily reconciled, violating the core GitOps principle of desired state stored in Git. Option B is wrong because Git is not used merely as a backup; it is the single source of truth for the desired state, and the controller actively enforces that state, not just stores copies. Option C is wrong because Git hooks are external triggers for CI/CD pipelines, but GitOps uses a pull-based model where the controller inside the cluster watches the Git repository for changes, not a push-based pipeline triggered by hooks.

Practice this question →

139

Multi-Selecteasy

Which TWO of the following are benefits of using a multi-cloud strategy? (Select TWO.)

Select 2 answers

A.Reduced network latency

B.Improved resilience and disaster recovery

C.Avoiding vendor lock-in

D.Simplified compliance

E.Increased vendor lock-in

AnswersB, C

Distributing workloads across independent cloud providers removes a single point of failure, so an outage at one vendor cannot take down the whole estate. This directly satisfies the stem's resilience and disaster-recovery benefit, since failover targets sit on separate infrastructure with no shared control plane.

Why this answer

A multi-cloud strategy distributes workloads across multiple cloud providers, so if one provider experiences an outage, applications can failover to another provider, improving overall resilience and disaster recovery. Option C is correct because using multiple cloud providers prevents dependency on a single vendor's proprietary services, avoiding vendor lock-in and giving you leverage for pricing and feature negotiations.

Exam trap

The trap here is that candidates confuse multi-cloud with hybrid cloud, assuming multi-cloud automatically improves latency or simplifies compliance, when in fact multi-cloud often increases complexity in both areas.

Practice this question →

140

MCQeasy

Which tool is used to manage infrastructure as code and can provision resources across multiple cloud providers?

A.Helm

B.Terraform

C.Ansible

D.AWS CloudFormation

AnswerB

Terraform's declarative HCL configuration and provider plugin architecture let a single workflow provision resources across AWS, Azure and GCP, satisfying the multi-cloud requirement. Its state file tracks real infrastructure, enabling idempotent planning and applying, unlike single-provider tools such as CloudFormation or ARM templates.

Why this answer

Terraform is the correct tool because it is an open-source infrastructure as code (IaC) software tool by HashiCorp that uses declarative configuration files (HCL) to provision and manage resources across multiple cloud providers (AWS, Azure, GCP, etc.) via provider plugins. Unlike single-cloud tools, Terraform's provider architecture allows it to manage heterogeneous environments consistently, making it the standard multi-cloud IaC solution.

Exam trap

CNCF often tests the distinction between configuration management tools (Ansible) and infrastructure provisioning tools (Terraform), leading candidates to pick Ansible because they associate 'automation' with infrastructure, but Ansible lacks native multi-cloud resource lifecycle management and state tracking.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys and manages applications on Kubernetes clusters using charts, not a tool for provisioning infrastructure across multiple cloud providers. Option C is wrong because Ansible is primarily a configuration management and automation tool that uses procedural playbooks (YAML) and agentless SSH/PowerShell connections, but it is not designed as a declarative IaC tool for multi-cloud resource provisioning; it focuses on state enforcement on existing servers rather than resource lifecycle management. Option D is wrong because AWS CloudFormation is a native AWS service that provisions resources only within the AWS ecosystem using JSON/YAML templates, and it cannot manage resources across other cloud providers like Azure or GCP.

Practice this question →

141

MCQmedium

A company is adopting a multi-cloud strategy to avoid vendor lock-in. Which pattern BEST supports deploying applications across different cloud providers with minimal changes?

A.Use a hybrid cloud approach with a single cloud for all workloads

B.Deploy applications using Kubernetes on each cloud

C.Use each cloud provider's native services directly

D.Write application code that checks the cloud provider and adapts

AnswerB

Kubernetes abstracts compute, networking and storage behind a consistent API, so the same manifests and workloads run on any conformant cluster. This directly satisfies the stem's vendor lock-in constraint: portability across providers comes from the open API surface, not from provider-specific services.

Why this answer

Deploying applications using Kubernetes on each cloud provides a consistent orchestration and API layer across providers, so workloads can be moved with minimal changes. Kubernetes abstracts compute, networking, and storage through standard primitives (Pods, Services, PVCs), reducing provider-specific coupling. This is the core pattern for portable multi-cloud deployments.

Exam trap

KCNA often tests the misconception that using native cloud services or provider-detection code achieves portability — candidates miss that Kubernetes provides the abstraction layer that minimizes changes across clouds.

How to eliminate wrong answers

Option A is wrong because a hybrid cloud with a single cloud for all workloads is not multi-cloud and does not avoid vendor lock-in. Option C is wrong because using each cloud provider's native services directly maximizes lock-in by tying the application to proprietary APIs. Option D is wrong because writing code that detects the cloud provider and adapts creates provider-specific branches, increasing complexity and coupling rather than minimizing changes.

Practice this question →

142

MCQhard

A team wants to deploy a workload that must run on every node in a Kubernetes cluster, including new nodes added later. Which resource type should they use?

A.Deployment

B.Job

C.DaemonSet

D.StatefulSet

AnswerC

A DaemonSet ensures one pod replica runs on every eligible node, and the controller automatically schedules pods onto nodes added later. This matches the requirement for cluster-wide coverage including future nodes, unlike Deployments or StatefulSets.

Why this answer

A DaemonSet ensures that a copy of a specific pod runs on every node in the cluster, including nodes added later. This is ideal for cluster-wide services like log collectors, monitoring agents, or network plugins that must run on all nodes.

Exam trap

KCNA often tests the difference between workload types, and candidates may confuse DaemonSet with Deployment, thinking Deployments can ensure one pod per node.

How to eliminate wrong answers

Option A is wrong because a Deployment manages replicated pods but does not guarantee one pod per node; it schedules pods based on available resources. Option B is wrong because a Job runs pods to completion for batch tasks, not continuously on every node. Option D is wrong because a StatefulSet is for stateful applications requiring stable identities and persistent storage, not for running on every node.

Practice this question →

143

MCQhard

A team is building a serverless application using Knative. They want the application to scale to zero when idle. Which Knative resource type should they use?

A.Knative Serving

B.Knative Trigger

C.Knative Build

D.Knative Eventing

AnswerA

Knative Serving provides request-driven autoscaling, including scale-to-zero, by routing traffic through the Activator and manipulating Kubernetes Deployments via the autoscaler. This directly satisfies the stem's idle scale-to-zero constraint, which Knative Eventing and other resource types cannot deliver.

Why this answer

Knative Serving is the component that manages request-driven workloads and provides scale-to-zero (and scale-from-zero) capabilities. It deploys containerized services with automatic scaling based on incoming requests, including scaling down to zero replicas when idle.

Exam trap

KCNA often tests the Serving vs Eventing boundary — candidates pick Eventing or Trigger because 'serverless' sounds event-driven, but scale-to-zero for request-driven apps is a Serving feature.

How to eliminate wrong answers

Option B is wrong because a Knative Trigger is an Eventing construct that connects an event source to a subscriber (a Broker/Trigger pattern), not a compute resource with scale-to-zero. Option C is wrong because Knative Build was a deprecated build component (superseded by Tekton) for building container images, not for running serverless workloads. Option D is wrong because Knative Eventing handles event routing, brokering, and delivery — it does not provide request-driven autoscaling or scale-to-zero for application workloads.

Practice this question →

144

MCQeasy

Which of the following is a primary goal of the Cloud Native Computing Foundation (CNCF)?

A.To develop the Kubernetes container orchestration platform

B.To host proprietary cloud-native solutions

C.To foster and sustain the cloud-native ecosystem of open source projects

D.To provide commercial support for Kubernetes

AnswerC

The CNCF exists to foster and sustain the cloud-native ecosystem by hosting open source projects such as Kubernetes, Prometheus and Envoy under neutral vendor governance. This differs from standards bodies that publish specifications only; the foundation actively nurtures project maturity through graduated tiers.

Why this answer

The CNCF is a vendor-neutral foundation under the Linux Foundation whose primary mission is to foster and sustain the cloud-native ecosystem by hosting and nurturing open source projects such as Kubernetes, Prometheus, Envoy, and containerd. It provides governance, legal, and marketing support to projects rather than developing them directly. This makes option C the correct description of its core goal.

Exam trap

KCNA often tests the distinction between the CNCF as a neutral foundation that hosts projects versus organizations that develop or commercially support them, so candidates must not confuse hosting with development.

How to eliminate wrong answers

Option A is wrong because Kubernetes was originally developed by Google and then donated to the CNCF; the CNCF hosts and governs the project but does not develop it. Option B is wrong because the CNCF explicitly hosts open source, vendor-neutral projects and does not support proprietary solutions. Option D is wrong because commercial support for Kubernetes is provided by vendors and service providers, not by the CNCF itself, which is a non-profit foundation.

Practice this question →

145

Multi-Selectmedium

Which TWO of the following are core principles of cloud native architecture? (Choose two.)

Select 2 answers

A.Manual infrastructure provisioning

B.Monolithic application design

C.Tight coupling between services

D.Containerization

E.Microservices

AnswersD, E

Containers provide lightweight, consistent environments.

Why this answer

Containerization (Option D) is a core principle of cloud native architecture because it packages applications and their dependencies into isolated, lightweight containers, enabling consistent deployment across environments and efficient resource utilization. This aligns with the cloud native goal of portability and scalability, as containers can be orchestrated by platforms like Kubernetes to manage dynamic workloads.

Exam trap

CNCF often tests the misconception that cloud native architecture requires a specific technology like Kubernetes or Docker, but the core principles are about architectural patterns (e.g., microservices, containerization) rather than any single tool, so candidates may incorrectly select options that describe operational practices (like manual provisioning) instead of architectural principles.

Practice this question →

146

MCQmedium

Which component in a service mesh is responsible for collecting telemetry data and enforcing traffic policies?

A.Control plane

B.Sidecar proxy (data plane)

C.Certificate authority

D.Service mesh ingress gateway

AnswerB

The sidecar proxy sits alongside each workload in the data plane, intercepting all inbound and outbound traffic. It enforces routing and access policies while emitting metrics, logs and traces to the control plane's telemetry collectors.

Why this answer

In a service mesh, the sidecar proxy (part of the data plane) is the component that actually intercepts service-to-service traffic, enforces traffic policies (routing, retries, timeouts, mTLS), and emits telemetry (metrics, logs, traces) for each request. The control plane configures the sidecars but does not handle live traffic itself.

Exam trap

The trap is confusing the control plane (which configures policy) with the data plane (which enforces it) — candidates often pick 'control plane' because it sounds like the brain of the mesh, but telemetry collection and runtime policy enforcement happen in the sidecar proxy.

How to eliminate wrong answers

Option A is wrong because the control plane (e.g., Istio's istiod, Linkerd's control plane) is responsible for configuration, certificate issuance, and pushing policy to the data plane — it does not sit in the request path and therefore does not collect per-request telemetry or enforce runtime traffic policies. Option C is wrong because the certificate authority is a component that issues and rotates workload certificates for mTLS; it is part of the control plane's security function and does not process traffic or collect telemetry. Option D is wrong because the ingress gateway handles north-south traffic entering the mesh from outside, not the east-west service-to-service traffic where sidecar proxies enforce policy and collect telemetry.

Practice this question →

147

MCQmedium

Which of the following best describes the 12-factor app methodology's approach to configuration?

A.Configuration is hardcoded in the application code

B.Configuration is stored in environment variables

C.Configuration is stored in a database and accessed at runtime

D.Configuration is managed by a configuration server

AnswerB

The 12-factor methodology mandates strict separation of config from code, storing it in environment variables so the same build can be deployed across environments. This satisfies the stem by naming environment variables as the prescribed storage mechanism rather than files or baked-in values.

Why this answer

The 12-factor app methodology's third factor, 'Config,' states that configuration should be stored in environment variables, keeping it strictly separate from code. This allows the same codebase to be deployed across environments without modification. Environment variables are language- and OS-agnostic, making them the recommended mechanism.

Exam trap

The trap is over-engineering the answer by choosing a configuration server or database, which sounds robust but contradicts the 12-factor methodology's explicit preference for environment variables.

How to eliminate wrong answers

Option A is wrong because hardcoding configuration in code violates the factor's core principle and makes the app non-portable across environments. Option C is wrong because storing config in a database and reading it at runtime is not the 12-factor recommendation; it couples config to a runtime dependency and complicates deployment. Option D is wrong because a configuration server, while used in some architectures, is not what the 12-factor methodology prescribes; the factor explicitly calls for environment variables.

Practice this question →

148

Multi-Selecteasy

Which THREE of the following are benefits of using a service mesh in a cloud native architecture?

Select 3 answers

A.Management of application state across services

B.Traffic management capabilities like canary deployments

C.Reduction of container image sizes

D.Improved security through mutual TLS encryption

E.Enhanced observability with metrics and tracing

AnswersB, D, E

A service mesh provides layer 7 traffic management through sidecar proxies, enabling fine-grained routing rules that split traffic between service versions. This directly supports canary deployments, where a small percentage of requests route to a new version before full rollout, satisfying the stem's requirement for progressive delivery without changing application code.

Why this answer

Option B is correct because a service mesh provides layer-7 traffic management (e.g., weighted routing, header-based routing) that enables canary deployments and blue/green releases without changing application code. Option D is correct because service meshes like Istio and Linkerd automatically provision and rotate mutual TLS (mTLS) certificates between sidecar proxies, giving strong service-to-service authentication and encryption. Option E is correct because sidecar proxies emit uniform telemetry—request metrics, distributed traces, and access logs—across all services, improving observability without per-service instrumentation.

Option A is not a service mesh benefit: application state management is handled by databases, caches, or stateful orchestration, not by the mesh's data plane. Option C is also incorrect because the mesh adds sidecar proxies and control-plane components, which tend to increase rather than reduce container image sizes.

Exam trap

KCNA often tests the core responsibilities of a service mesh; candidates may confuse it with other cloud native tools like container registries or state management solutions, leading them to select options that are not service mesh benefits.

Practice this question →

149

Multi-Selectmedium

Which TWO of the following are common characteristics of serverless computing? (Choose two.)

Select 2 answers

A.Auto-scaling to zero when idle

B.Event-driven execution

C.Manual scaling based on predicted load

D.Always-on dedicated servers

E.Long-running stateful processes

AnswersA, B

Auto-scaling to zero when idle is a defining trait of serverless platforms such as AWS Lambda and Azure Functions, where the provider provisions no instances during inactivity. This satisfies the stem's demand for common characteristics, since consumption-based billing and event-driven invocation both depend on capacity dropping to zero rather than idling at a baseline.

Why this answer

Option A (Auto-scaling to zero when idle) is correct because serverless platforms such as AWS Lambda, Azure Functions, and Google Cloud Functions provision no compute instances when there are no invocations, so you pay nothing during idle periods and capacity scales down to zero automatically. Option B (Event-driven execution) is correct because serverless functions are invoked in response to events — HTTP requests via API Gateway, object uploads to S3, messages in SQS, database changes, or scheduled timers — rather than running continuously. Option C is incorrect because manual scaling based on predicted load describes traditional provisioned servers or reserved capacity, not the automatic, demand-based scaling of serverless.

Option D is incorrect because serverless abstracts away servers entirely; there are no always-on dedicated servers allocated to the customer. Option E is incorrect because serverless functions are designed to be short-lived and stateless, with state externalized to services like DynamoDB, S3, or Redis rather than held in long-running processes.

Exam trap

The trap is selecting options that sound 'efficient' (manual scaling, dedicated servers) because they are familiar from traditional infrastructure — candidates must remember that serverless is defined by automatic elasticity to zero and event-driven invocation, not by any form of pre-provisioned capacity.

Practice this question →