Kubernetes and Cloud Native Associate KCNA KCNA Questions 226–300 | Page 4/13

226

MCQeasy

What is the primary purpose of a container orchestration platform like Kubernetes?

A.To provide a lightweight runtime for running a single container

B.To automate the deployment, scaling, and management of containerized applications

C.To manage virtual machines and their hypervisors

D.To compile source code into container images

AnswerB

Kubernetes automates deployment, scaling and management of containerised applications, satisfying the stem's demand for the platform's primary purpose. Its control plane reconciles desired state against actual state, handling scheduling, self-healing and horizontal scaling across nodes — capabilities manual container management cannot provide at scale.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across clusters of hosts. It handles scheduling, load balancing, self-healing, and rolling updates, which are beyond the scope of a single container runtime.

Exam trap

The exam often tests the distinction between a container runtime (e.g., Docker) and an orchestration platform (e.g., Kubernetes), so candidates mistakenly think orchestration is just about running containers rather than managing them at scale.

How to eliminate wrong answers

Option A is wrong because a lightweight runtime for running a single container is the purpose of a container engine like Docker or containerd, not an orchestration platform. Option C is wrong because managing virtual machines and their hypervisors is the role of a hypervisor or VM orchestration tool like vSphere or OpenStack, not Kubernetes, which abstracts pods over VMs or bare metal. Option D is wrong because compiling source code into container images is the function of a build tool like Docker Build or Kaniko, not a runtime orchestrator like Kubernetes.

Full explanation →

227

MCQhard

A platform team wants to implement observability for a Kubernetes cluster running 500+ microservices. They need to reduce the cost of storing logs while retaining the ability to search for specific error patterns. Which strategy best achieves this?

A.Increase log retention to one year for compliance

B.Store all logs in a centralized Elasticsearch cluster with high retention

C.Aggregate logs into a single pod for easier indexing

D.Use structured logging and sample debug logs, retaining error logs fully

AnswerD

Structured logging plus sampling debug output slashes stored log volume, directly cutting storage cost, while retaining error logs in full preserves searchability for specific error patterns. This balances the cost constraint against the required troubleshooting capability.

Why this answer

Structured logging (e.g., JSON format) enables efficient indexing and querying of logs, while sampling debug logs and retaining error logs fully reduces storage costs without losing critical error patterns. This approach balances observability needs with cost optimization, a key principle in cloud-native environments.

Exam trap

The trap here is that candidates may assume centralized storage (Elasticsearch) or longer retention always improves observability, ignoring the cost and scalability constraints of 500+ microservices in a cloud-native environment.

How to eliminate wrong answers

Option A is wrong because increasing log retention to one year for compliance does not address cost reduction; it increases storage costs and may violate data minimization principles. Option B is wrong because storing all logs in a centralized Elasticsearch cluster with high retention is expensive and inefficient, as it retains unnecessary debug logs and scales poorly for 500+ microservices. Option C is wrong because aggregating logs into a single pod creates a single point of failure, violates pod isolation, and does not reduce storage costs or improve searchability.

Full explanation →

228

MCQeasy

Which component is the primary entry point for all administrative tasks and API requests in a Kubernetes cluster?

A.kube-controller-manager

B.kube-apiserver

C.etcd

D.kube-scheduler

AnswerB

The kube-apiserver exposes the REST API that every administrative tool, including kubectl, and every internal component uses to read or mutate cluster state. It is the only component that communicates directly with etcd, making it the sole entry point.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative tasks and API requests. It exposes the Kubernetes API (over HTTPS), validates and processes RESTful operations (e.g., kubectl commands, pod creation), and serves as the communication gateway between internal components (e.g., etcd, scheduler, controller-manager) and external clients. Without the API server, no administrative action or resource change can be initiated in the cluster.

Exam trap

A common trap is believing that etcd is the primary entry point because it stores all cluster data. However, etcd is a backend storage component and is never accessed directly by users or administrative tools—all reads and writes must pass through the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager is not an entry point for API requests; it runs controller loops (e.g., Node Controller, Replication Controller) that watch the API server for desired state changes and reconcile the current state, but it does not accept external administrative tasks. Option C is wrong because etcd is a distributed key-value store that holds cluster state data, but it is not directly accessible for administrative tasks or API requests—all interactions with etcd must go through the kube-apiserver to ensure consistency and authorization. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints; it does not serve as an entry point for administrative tasks or API calls, and it only interacts with the API server to read pod specs and write scheduling decisions.

Full explanation →

229

Multi-Selectmedium

Which THREE of the following are key benefits of container orchestration? (Choose 3)

Select 3 answers

A.Built-in network isolation between all containers

B.Declarative management using desired state configuration

C.High availability through replication and load balancing

D.Automatic code compilation from source repositories

E.Self-healing capabilities that restart failed containers

AnswersB, C, E

Users define the desired state, and the orchestrator works to achieve and maintain it.

Why this answer

Declarative management using desired state configuration is a core benefit of container orchestration platforms like Kubernetes. Instead of manually issuing commands to start, stop, or scale containers, you define the desired state of your application (e.g., 'run 3 replicas of nginx:1.25') in a YAML or JSON manifest. The orchestrator's control loop continuously reconciles the actual state with this desired state, automatically making changes to achieve and maintain it.

Exam trap

The CNCF exam often tests the distinction between features provided by the container runtime (like network isolation) versus features provided by the orchestrator (like desired state management and self-healing), leading candidates to incorrectly select runtime features as orchestration benefits.

Full explanation →

230

MCQhard

You have a ConfigMap named 'app-config' and a Secret named 'db-password'. You want to mount them into a pod. Which statement is correct?

A.Secrets can be mounted as volumes, but ConfigMaps cannot

B.Both ConfigMaps and Secrets can be mounted as volumes

C.ConfigMaps can be mounted as volumes, but Secrets cannot

D.ConfigMaps and Secrets can only be exposed as environment variables

AnswerB

Both ConfigMaps and Secrets are API objects whose data can be projected into a pod as files via a volume mount. Each key becomes a file, so either can be mounted alongside the other in the same pod.

Why this answer

Both ConfigMaps and Secrets are Kubernetes API objects designed to decouple configuration data from container images. They can be mounted as volumes into pods, allowing files to be created in the container's filesystem with the data from the ConfigMap or Secret. This is a core feature for managing configuration and sensitive data in Kubernetes.

Exam trap

CNCF often tests the misconception that Secrets and ConfigMaps have different mounting capabilities, when in fact both support volume mounts and environment variable injection, with the key difference being that Secrets are base64-encoded and intended for sensitive data.

How to eliminate wrong answers

Option A is wrong because ConfigMaps can indeed be mounted as volumes, just like Secrets. Option C is wrong because Secrets can be mounted as volumes, just like ConfigMaps. Option D is wrong because both ConfigMaps and Secrets can be exposed as environment variables AND mounted as volumes, not only as environment variables.

Full explanation →

231

MCQeasy

A cluster administrator wants to ensure that a specific Pod always runs on a node with an SSD. The node has the label disktype=ssd. Which Kubernetes feature should the administrator use?

A.Pod affinity

B.Taints and tolerations

C.Resource requests and limits

D.nodeSelector

AnswerD

nodeSelector is a simple field in the Pod spec that specifies a map of key-value pairs. The Pod will only be scheduled on nodes that have all the specified labels. Here, setting nodeSelector: disktype: ssd ensures the Pod lands on an SSD node.

Why this answer

nodeSelector is the simplest way to constrain a Pod to nodes with specific labels. By specifying a label like disktype=ssd, the scheduler only considers nodes that have that label. This directly satisfies the requirement of running on an SSD node.

Exam trap

The trap here is confusing node selection mechanisms, such as using taints and tolerations or affinity when a simple nodeSelector is sufficient.

Full explanation →

232

MCQmedium

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

A.To automatically apply changes from a Git repository to a Kubernetes cluster

B.To monitor application performance

C.To create Docker images from source code

D.To manage container registries

AnswerA

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

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

233

MCQhard

A cluster administrator needs to ensure that a Deployment named 'frontend' in namespace 'web' is updated with a new image version using a rolling update strategy. The current deployment has 4 replicas. The administrator runs: kubectl set image deployment/frontend frontend=nginx:1.21 -n web. Which of the following describes the expected behavior?

A.The Deployment will create a new ReplicaSet and gradually replace old pods with new ones

B.All existing pods will be deleted immediately and new pods will be created with the new image

C.The command will fail because you cannot update a Deployment using kubectl set image

D.The Deployment's image will be updated, but only the container named 'app' will be affected

AnswerA

Changing the container image updates the pod template, so the Deployment controller creates a new ReplicaSet and scales it up while scaling the old one down, honouring the rolling update strategy and its maxSurge/maxUnavailable settings across the 4 replicas.

Why this answer

`kubectl set image deployment/frontend frontend=nginx:1.21 -n web` updates the container image in the Deployment's pod template, triggering a rolling update. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime and maintaining the desired replica count of 4.

Exam trap

The trap here is that candidates may confuse the container name in the command (which must match the container name in the Deployment spec) with a generic name like 'app', leading them to incorrectly assume only a container named 'app' is affected.

How to eliminate wrong answers

Option B is wrong because it describes a 'Recreate' strategy, not the default 'RollingUpdate' strategy; a rolling update does not delete all pods immediately. Option C is wrong because `kubectl set image` is a valid command for updating container images in Deployments, StatefulSets, and other workloads. Option D is wrong because the command explicitly targets the container named 'frontend' (as specified in the command), not a container named 'app'; only the named container's image is updated.

Full explanation →

234

MCQeasy

What is the primary benefit of using containers over virtual machines?

A.Containers provide stronger isolation between applications

B.Containers include a full operating system per instance

C.Containers require a hypervisor to run

D.Containers are lightweight and share the host OS kernel

AnswerD

Containers share the host operating system kernel, so each container packages only the application and its dependencies rather than a full guest OS. This removes hypervisor and duplicate-kernel overhead, making containers lighter and faster to start than virtual machines.

Why this answer

Containers are lightweight because they share the host OS kernel, avoiding the overhead of a separate guest OS per instance. Unlike VMs, which require a hypervisor and a full OS for each virtual machine, containers run as isolated processes on the same kernel, enabling faster startup times and higher density. This shared-kernel model is the primary benefit, as it reduces resource consumption and improves efficiency in orchestrated environments like Kubernetes.

Exam trap

The trap here is that candidates confuse 'isolation' with 'security' and assume containers are more secure because they are lightweight, but the primary benefit is resource efficiency, not stronger isolation—VMs actually provide better isolation via hardware virtualization.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than virtual machines, as they share the host kernel and rely on namespaces and cgroups for process-level separation, whereas VMs use hardware-level virtualization with a hypervisor for stronger isolation. Option B is wrong because containers do not include a full operating system per instance; they package only the application and its dependencies, while the OS kernel is shared from the host. Option C is wrong because containers do not require a hypervisor to run; they run directly on the host OS using the kernel's container runtime (e.g., runc), whereas VMs require a hypervisor (e.g., KVM, VMware) to virtualize hardware.

Full explanation →

235

MCQeasy

What is the primary difference between a container and a virtual machine (VM)?

A.Containers are slower to start than VMs

B.Containers require a hypervisor to run

C.Containers share the host OS kernel, whereas VMs each have their own guest OS

D.Containers virtualize hardware, while VMs virtualize the operating system

AnswerC

Containers share the host OS kernel, so each container image excludes a kernel and starts in seconds with minimal overhead. VMs run a full guest OS per instance on the hypervisor, consuming far more memory and disk. This kernel-sharing boundary is the defining architectural difference the question asks for.

Why this answer

The primary difference is that containers share the host operating system kernel, while each virtual machine runs its own complete guest OS. This means containers are lightweight processes with isolated user spaces, whereas VMs include a full OS stack (kernel, drivers, libraries) per instance. This architectural distinction is why containers start in seconds and have minimal overhead, while VMs require booting a guest OS and consume more resources.

Exam trap

Commonly tested misconception: candidates often think containers are 'lightweight VMs' or that they virtualize hardware, when in fact containers share the host kernel and use OS-level virtualization, which is a fundamentally different isolation model.

How to eliminate wrong answers

Option A is wrong because containers are faster to start than VMs — containers start in milliseconds as they are just processes on the host kernel, whereas VMs require booting a full guest OS, which takes seconds to minutes. Option B is wrong because containers do not require a hypervisor; they run directly on the host OS using kernel features like cgroups and namespaces, while VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware. Option D is wrong because it reverses the concepts: containers virtualize the operating system (via OS-level virtualization), while VMs virtualize hardware (via hypervisor and guest OS).

Full explanation →

236

MCQeasy

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

A.VerticalPodAutoscaler

B.Cluster Autoscaler

C.HorizontalPodAutoscaler

D.PodDisruptionBudget

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

237

MCQmedium

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

A.Use environment variables

B.Store configuration in a config file that is version-controlled

C.Use a centralized database for configuration

D.Hard-code the configuration in the application code

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

238

Multi-Selecthard

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

Select 3 answers

A.Container image building

B.Traffic routing and load balancing

C.Observability including metrics and distributed tracing

D.Security through mTLS and access policies

E.Database schema migrations

AnswersB, C, D

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

Why this answer

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

Full explanation →

239

Multi-Selectmedium

Which THREE are benefits of using a container orchestration platform? (Select 3)

Select 3 answers

A.Guarantees zero downtime during deployments

B.Declarative configuration management

C.Automated scaling based on demand

D.Eliminates the need for cloud infrastructure

E.High availability through automatic failover

AnswersB, C, E

Declarative configuration management lets you define the desired state of workloads in manifests, and the orchestrator continuously reconciles actual state to match it. This satisfies the stem's benefit requirement by automating scheduling, self-healing and scaling without manual intervention, ensuring consistent, reproducible deployments across the cluster.

Why this answer

Option B is correct because container orchestration platforms such as Kubernetes use declarative configuration management, where you define the desired state in manifests (YAML) and the control plane continuously reconciles actual state to match it. Option C is correct because orchestration platforms provide automated scaling based on demand, for example Kubernetes Horizontal Pod Autoscaler adjusts replica counts using metrics like CPU utilization. Option E is correct because orchestration platforms deliver high availability through automatic failover, rescheduling pods onto healthy nodes when a node or container fails, and supporting self-healing and rolling updates.

Option A is not correct because zero downtime is not guaranteed; it depends on proper configuration such as readiness probes, rolling update strategy, and sufficient capacity, so downtime can still occur. Option D is not correct because orchestration platforms run on infrastructure, including cloud or on-premises resources, and do not eliminate the need for cloud infrastructure.

Exam trap

The trap is the absolute language in option A ('guarantees zero downtime') — exam writers include absolute claims as distractors because orchestration reduces downtime but cannot guarantee its complete elimination without application-level cooperation.

Full explanation →

240

Multi-Selectmedium

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

Select 2 answers

A.Static scaling based on predefined thresholds

B.Microservices architecture

C.Dynamic orchestration

D.Manual infrastructure management

E.Monolithic deployment

AnswersB, C

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

Why this answer

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

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

Full explanation →

241

MCQhard

A pod is stuck in the Pending state. The administrator runs 'kubectl describe pod' and sees the event '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

A.The nodes are cordoned and cannot accept new pods.

B.The pod's CPU limit is set too low, causing it to be rejected.

C.The pod's CPU request is higher than the available CPU on any node.

D.The pod has a nodeSelector that does not match any node labels.

AnswerC

The scheduler reports 'Insufficient cpu' when no node has enough allocatable CPU to satisfy the pod's CPU request. This means the sum of CPU requests of existing pods plus the new pod's request exceeds the node's capacity. The pod remains Pending until resources are freed or the request is lowered. This is the direct cause of the event.

Why this answer

The event 'Insufficient cpu' indicates that the scheduler cannot find a node with enough allocatable CPU to meet the pod's CPU request. This is a resource constraint issue, not related to limits, cordoning, or node selectors. The pod will remain Pending until sufficient CPU is available or the request is reduced.

Exam trap

The trap here is confusing CPU limits with requests; only requests affect scheduling, while limits affect runtime throttling.

Full explanation →

242

Drag & Dropmedium

Drag and drop the steps to create a ConfigMap from a file in Kubernetes into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

The correct sequence to create a ConfigMap from a file in Kubernetes is: first prepare the configuration file, then create the ConfigMap using kubectl create configmap, next verify the ConfigMap with kubectl get configmaps, then optionally describe it with kubectl describe configmap, and finally use it in a Pod as environment variables or volume mounts. This order ensures the ConfigMap is available and correctly configured before consumption.

Full explanation →

243

Multi-Selecteasy

Which TWO are benefits of using a container orchestration platform like Kubernetes? (Select TWO.)

Select 2 answers

A.Increases application complexity

B.Requires a dedicated hypervisor for each container

C.Automatic service discovery and load balancing

D.Self-healing (automatic restart of failed containers)

E.Manual scaling of applications

AnswersC, D

Kubernetes assigns each Service a stable virtual IP and DNS name, then distributes traffic across matching healthy pods automatically. This removes the need for applications to track individual pod addresses, satisfying the requirement for built-in service discovery and load balancing.

Why this answer

Option C is correct because Kubernetes provides built-in service discovery through Services and DNS (CoreDNS), automatically routing traffic to healthy Pods and distributing load across replicas via kube-proxy, eliminating manual endpoint configuration. Option D is correct because Kubernetes controllers such as the ReplicaSet and kubelet continuously reconcile desired state, automatically restarting or rescheduling failed containers to maintain the declared replica count. Option A is incorrect because orchestration platforms are designed to reduce operational complexity by abstracting infrastructure management, not increase application complexity.

Option B is incorrect because Kubernetes runs containers via a container runtime (containerd, CRI-O) on shared nodes; it does not require a dedicated hypervisor per container. Option E is incorrect because Kubernetes supports automatic horizontal scaling through the Horizontal Pod Autoscaler (HPA) based on CPU, memory, or custom metrics, rather than requiring manual scaling.

Exam trap

CNCF often tests the distinction between manual and automatic scaling; candidates may incorrectly select manual scaling as a benefit because they confuse it with the ability to scale, but the question asks for benefits of using the platform, which include automation, not manual effort.

Full explanation →

244

MCQmedium

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

A.Monolithic architecture

B.Microservices architecture

C.Serverless architecture

D.Service mesh

AnswerB

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

Why this answer

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

Exam trap

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

Full explanation →

245

MCQmedium

A DevOps team wants to collect logs from all Kubernetes nodes and forward them to a central log storage system. Which tool is specifically designed for lightweight log aggregation and forwarding on Kubernetes nodes?

A.Elasticsearch

B.Prometheus

C.Fluent Bit

D.Grafana

AnswerC

Fluent Bit is a lightweight, low-footprint log processor and forwarder designed for constrained environments, typically deployed as a DaemonSet so one pod runs per node. It tails node and container logs and ships them to central storage, matching the aggregation requirement.

Why this answer

Fluent Bit is a lightweight, high-performance log processor and forwarder designed specifically for resource-constrained environments like Kubernetes nodes. It runs as a DaemonSet, tails container log files from /var/log/containers, and forwards them to a central backend such as Elasticsearch, Loki, or Splunk. Its low CPU and memory footprint make it the standard choice for node-level log aggregation.

Exam trap

The trap is conflating log storage/search tools (Elasticsearch, Kibana) with log collection/forwarding tools — the question asks specifically about the node-level agent, which is Fluent Bit.

How to eliminate wrong answers

Option A is wrong because Elasticsearch is a storage and search engine for logs, not a node-level collector/forwarder. Option B is wrong because Prometheus is a metrics monitoring system using a pull model, not a log aggregation tool. Option D is wrong because Grafana is a visualization and dashboarding layer that queries data sources — it does not collect or forward logs from nodes.

Full explanation →

246

MCQmedium

What is the role of etcd in a Kubernetes cluster?

A.It manages network policies

B.It stores the cluster state and configuration

C.It schedules pods onto nodes

D.It provides DNS resolution for services

AnswerB

etcd is the distributed key-value store holding all cluster state and configuration, including object specs, node registrations and Secrets. The API server reads and writes every object through it, so it is the single source of truth for the cluster's desired and observed state.

Why this answer

etcd is a distributed, consistent key-value store that serves as Kubernetes' primary data store. It holds the entire cluster state, including all object definitions (Pods, Services, Deployments, etc.), configuration data, and secrets. The kube-apiserver is the only component that interacts directly with etcd, ensuring that all state changes go through a consistent, transactional backend.

Without etcd, the cluster would have no persistent record of its desired or current state.

Exam trap

A common misconception is that etcd is a general-purpose database or that it directly participates in scheduling or networking decisions, when in fact it is a highly specialized, consistent key-value store that only the API server communicates with, and all other components read/write cluster state through the API server.

How to eliminate wrong answers

Option A is wrong because network policies are managed by a Network Policy controller (e.g., Calico, Cilium) or the kube-controller-manager, not by etcd; etcd only stores the policy objects as data. Option C is wrong because pod scheduling onto nodes is performed by the kube-scheduler, which reads node and pod state from etcd via the API server but does not itself store or manage that state. Option D is wrong because DNS resolution for services is provided by CoreDNS (or kube-dns in older clusters), which runs as a set of Pods and uses the Kubernetes API to watch Services and Endpoints; etcd merely stores the DNS configuration objects.

Full explanation →

247

MCQmedium

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

A.ArgoCD

B.Helm

C.Jenkins

D.Terraform

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

248

Multi-Selecthard

Which TWO statements are true about Kubernetes namespaces? (Select 2)

Select 2 answers

A.All Kubernetes resources are namespaced

B.Namespaces provide network isolation by default

C.Resource quotas can be applied to a namespace to limit resource usage

D.Namespaces can be used to separate environments like dev and prod

E.Deleting a namespace automatically deletes all resources in it, including cluster-scoped resources

AnswersC, D

ResourceQuota objects are applied per namespace, capping aggregate CPU, memory, object counts and storage consumed by workloads within that namespace. This enforces multi-tenant limits, confirming the statement that quotas can restrict resource usage at namespace scope.

Why this answer

Option C is correct because ResourceQuota objects are applied at the namespace level to cap aggregate resource consumption (e.g., requests.cpu, limits.memory, pods) for all workloads within that namespace. Option D is correct because namespaces are the standard Kubernetes mechanism for logical multi-tenancy, allowing teams to isolate dev, staging, and prod workloads with separate RBAC, quotas, and naming scopes. Option A is wrong because several resources are cluster-scoped rather than namespaced, such as Node, PersistentVolume, ClusterRole, and Namespace itself.

Option B is wrong because namespaces do not enforce network isolation by default; that requires NetworkPolicy objects (and a CNI plugin that supports them). Option E is wrong because deleting a namespace cascades to its namespaced resources only, not cluster-scoped resources, which persist independently.

Exam trap

A common misconception is that namespaces inherently provide network isolation, but in reality, network policies are required to enforce traffic rules between namespaces.

Full explanation →

249

MCQmedium

A developer wants to expose a set of pods running a web application internally within the cluster using a stable IP address. Which Kubernetes resource should they create?

A.Ingress

B.ConfigMap

C.Deployment

D.Service

AnswerD

A Service provides a stable virtual IP and DNS name that load-balances across a set of pods selected by labels, decoupling clients from individual pod IPs. Creating a Service satisfies the stem's requirement for exposing pods internally with a stable IP address.

Why this answer

A Service of type ClusterIP provides a stable virtual IP address and DNS name that load-balances traffic to a set of pods, making it the correct resource for internal cluster exposure. Unlike other resources, a Service abstracts the pod IPs and ensures connectivity even if pods are rescheduled or scaled.

Exam trap

The trap here is that candidates often confuse a Deployment's ability to manage pods with network exposure, forgetting that a Deployment alone does not provide a stable IP or load-balanced endpoint — a Service is always required for that purpose.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to services, typically routing traffic from outside the cluster, not providing a stable internal IP. Option B is wrong because a ConfigMap is used to store non-confidential configuration data in key-value pairs and does not expose pods or provide network connectivity. Option C is wrong because a Deployment manages the desired state of replica sets and pods (e.g., rolling updates), but it does not create a stable network endpoint; a separate Service is required for that.

Full explanation →

250

MCQhard

A developer creates a Pod with a container that writes logs to a file in an emptyDir volume. The Pod is then deleted, and a new Pod is created with the same emptyDir volume definition. What happens to the data in the emptyDir volume?

A.The data is preserved because emptyDir volumes persist across Pod deletions.

B.The data is lost because emptyDir volumes are deleted when the Pod is deleted.

C.The data is preserved if the emptyDir volume is mounted with a persistentVolumeClaim.

D.The data is preserved if the new Pod is scheduled to the same node.

AnswerB

emptyDir volumes are created when a Pod is assigned to a node and exist as long as that Pod is running on that node. When the Pod is deleted, the emptyDir volume is deleted, and its data is permanently lost. A new Pod with a new emptyDir volume starts with an empty directory. This is the correct behavior for emptyDir volumes.

Why this answer

emptyDir volumes are ephemeral and are deleted when the Pod is deleted. They are designed for temporary storage that is shared among containers in a Pod or used as a scratch space. When the Pod is removed, the data is lost, and a new Pod will have a fresh emptyDir volume.

This behavior is consistent regardless of whether the new Pod is scheduled to the same node or not.

Exam trap

The trap here is assuming that emptyDir data persists if the Pod is rescheduled to the same node, confusing it with hostPath or persistent volumes.

Full explanation →

251

MCQhard

A cluster runs the Horizontal Pod Autoscaler (HPA) v2 for a Deployment named queue-worker. The HPA is configured with minReplicas: 2, maxReplicas: 10, and a target average CPU utilization of 60%. Metrics Server is installed and reports CPU for the Pods. During a burst, CPU utilization rises to 95% and stays there, but the Deployment remains at 2 replicas. Which condition most likely explains why the HPA is not scaling out?

A.The Deployment's Pod template does not set CPU requests, so the HPA cannot compute utilization.

B.The HPA needs a PodDisruptionBudget before it can scale the Deployment.

C.The HPA's maxReplicas of 10 is lower than the current node capacity, so it refuses to scale.

D.Metrics Server only reports node metrics, so the HPA must use custom metrics instead.

AnswerA

HPA calculates CPU utilization as a percentage of the requested CPU, not the limit or node capacity. If the container spec omits resources.requests.cpu, the HPA cannot derive a utilization percentage and reports unknown metrics, so it will not scale even when actual usage is high. Setting CPU requests on the Pod template is required for CPU-based autoscaling to function.

Why this answer

The HPA computes CPU utilization against the container's CPU request. Without resources.requests.cpu in the Pod template, the utilization metric is unavailable and the HPA cannot decide to scale, so replicas remain at the minimum even during sustained high CPU. PodDisruptionBudgets, Metrics Server scope, and maxReplicas are not the cause in this scenario.

Exam trap

The trap here is assuming the HPA scales on raw CPU usage, when it actually scales on CPU utilization relative to the container's CPU request.

Full explanation →

252

Multi-Selecthard

Which three of the following are benefits of container orchestration? (Choose three.)

Select 3 answers

A.High availability through replication

B.Scaling services up or down

C.Manual deployment of containers to specific hosts

D.Self-healing by restarting failed containers

E.Bare metal performance

AnswersA, B, D

Replication controllers and ReplicaSets maintain the desired pod count across nodes, automatically rescheduling workloads when a node fails. This directly delivers the high availability the stem asks for, since orchestration continuously reconciles observed state against declared state rather than relying on manual intervention or a single host staying healthy.

Why this answer

Container orchestration platforms such as Kubernetes and Docker Swarm provide high availability through replication (A) by running multiple identical instances of a service across nodes, so the failure of one replica or node does not take the service down. They also enable scaling services up or down (B) declaratively, adjusting the number of replicas to match demand via controllers like Deployments or ReplicaSets. Self-healing by restarting failed containers (D) is a core orchestration capability: the orchestrator monitors container and node health and automatically reschedules or restarts containers that crash or become unresponsive.

Option C is incorrect because orchestration automates scheduling and placement of containers rather than requiring manual deployment to specific hosts, which is the opposite of its benefit. Option E is incorrect because bare metal performance is a characteristic of running directly on hardware, not a benefit provided by orchestration, which typically adds an abstraction layer.

Exam trap

KCNA often tests the distinction between orchestration benefits and container runtime or infrastructure features, so candidates might mistakenly select 'bare metal performance' as a benefit when it is actually a property of the underlying hardware, not orchestration.

Full explanation →

253

Multi-Selecthard

Which THREE of the following are benefits of using container orchestration? (Choose three.)

Select 3 answers

A.High availability through automated failover

B.Decomposition of applications into microservices

C.Simplified networking with flat network topology

D.Self-healing by restarting failed containers

E.Automatic scaling of applications based on demand

AnswersA, D, E

Automated failover satisfies the high-availability constraint: when a node or pod fails, the orchestrator reschedules workloads onto healthy nodes without manual intervention. Controllers continuously reconcile observed state against declared desired state, so replicas are restored automatically, keeping services reachable despite individual component failures.

Why this answer

Option A is correct because container orchestration platforms such as Kubernetes continuously monitor node and pod health and automatically reschedule or failover workloads to healthy nodes, providing high availability without manual intervention. Option D is correct because orchestrators implement self-healing by detecting failed or unhealthy containers (for example, via liveness probes in Kubernetes) and automatically restarting or replacing them to maintain the desired state. Option E is correct because orchestrators support automatic scaling of applications based on demand, such as Kubernetes Horizontal Pod Autoscaler adjusting replica counts according to CPU utilization or custom metrics.

Option B is not a benefit of orchestration itself; decomposing applications into microservices is an architectural design choice that can be deployed on orchestration but is not provided by it. Option C is also not a benefit of orchestration; simplified flat networking is a characteristic of some container network plugins (like flannel or Calico overlay networks), not an inherent benefit of the orchestration layer.

Exam trap

CNCF often tests the distinction between architectural patterns (like microservices) and operational benefits of orchestration, so candidates mistakenly select decomposition as a direct benefit when it is actually a design choice that orchestration supports.

Full explanation →

254

MCQeasy

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

A.To schedule pods on nodes

B.To store application configuration

C.To monitor container resource usage

D.To provide a single entry point for external clients to access multiple backend services

AnswerD

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

Why this answer

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

Full explanation →

255

MCQeasy

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

A.Use a shared database for all microservices to ensure data consistency.

B.Use JSON Web Tokens for authentication between microservices in the same cluster.

C.Design each microservice with its own data store and communicate via APIs.

D.Ensure all microservices have identical resource requests and limits.

AnswerC

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

Why this answer

Cloud-native architecture principles advocate for decentralized data management, where each microservice owns its private data store and exposes functionality via well-defined APIs. This ensures loose coupling, independent scalability, and resilience, as services can evolve without impacting others. The pattern aligns with the Database per Service pattern, a core tenet of microservices design.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

256

MCQhard

You create a Deployment with 'replicas: 3' and update the pod template without changing the selector. After the update, you notice that only the new Pods are running, but old Pods have been terminated. What is the default update strategy?

A.OnDelete

B.BlueGreen

C.RollingUpdate

D.Recreate

AnswerC

RollingUpdate is the Deployment default, incrementally replacing old Pods with new ones via a new ReplicaSet while honouring maxUnavailable and maxSurge. This matches the observed behaviour: new Pods running and old Pods terminated, without the full downtime of Recreate.

Why this answer

The default update strategy for a Deployment in Kubernetes is RollingUpdate. When you update the pod template (e.g., changing the container image), the Deployment controller creates new ReplicaSets with the updated template and gradually scales down the old ReplicaSet while scaling up the new one, ensuring zero downtime. Since only new Pods are running and old Pods have been terminated, this confirms the default behavior of a rolling update, which replaces Pods incrementally without manual intervention.

Exam trap

A common trap is assuming the default update strategy is Recreate because it seems simpler, but the actual default is RollingUpdate, which performs gradual, zero-downtime updates.

How to eliminate wrong answers

Option A is wrong because OnDelete is a DaemonSet update strategy, not a Deployment strategy; it requires manual deletion of Pods to trigger updates. Option B is wrong because BlueGreen is not a native Kubernetes Deployment strategy; it is a deployment pattern implemented manually or via tools like Istio, not a default or built-in strategy. Option D is wrong because Recreate is a Deployment strategy that terminates all old Pods before creating new ones, but it is not the default; the default is RollingUpdate, and Recreate would cause downtime, which is not described in the scenario.

Full explanation →

257

MCQmedium

Which Kubernetes object is used to store non-sensitive configuration data that can be consumed by pods?

A.Secret

B.Annotation

C.Volume

D.ConfigMap

AnswerD

ConfigMap stores non-sensitive configuration as key-value pairs, decoupling settings from pod images. It satisfies the stem's constraint of non-sensitive data, unlike Secret, which handles sensitive values such as credentials. Pods consume ConfigMaps via environment variables, command-line arguments, or mounted volumes, enabling configuration changes without rebuilding images.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-sensitive configuration data, such as environment variables, command-line arguments, or configuration files, that can be consumed by pods. Unlike Secrets, ConfigMaps store data as plain text with no encoding or encryption, and are designed for configuration that does not require confidentiality.

Exam trap

The CNCF exam often tests the distinction between ConfigMap and Secret by presenting a scenario with 'configuration data' and expecting candidates to recognize that Secret is only for sensitive data, while ConfigMap is the correct choice for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed for sensitive data (e.g., passwords, tokens, SSH keys) and stores values as base64-encoded strings, with optional encryption at rest, not for non-sensitive configuration. Option B is wrong because Annotations are metadata key-value pairs attached to objects for non-identifying information (e.g., build info, contact details) and cannot be directly consumed by pods as configuration data. Option C is wrong because Volume is an abstraction for storage (e.g., emptyDir, hostPath, PVC) that can mount data into pods, but it is not a Kubernetes object for storing configuration data itself; ConfigMaps or Secrets are mounted via Volumes.

Full explanation →

258

MCQeasy

A developer needs to run a one-off batch job that processes a dataset and then terminates. The job should run to completion and not restart after successful completion. Which Kubernetes resource is most appropriate for this task?

A.DaemonSet

B.StatefulSet

C.Deployment

D.Job

AnswerD

A Job creates one or more pods and ensures they successfully complete. It is ideal for batch processing, as it tracks successful completions and does not restart pods after success. The Job controller terminates the pod once the task finishes, matching the requirement for a one-off job.

Why this answer

A Job is the correct resource for batch workloads that run to completion. It ensures the specified number of successful pod completions and then stops, making it ideal for one-off tasks. Other controllers like Deployments or StatefulSets are intended for continuous operation and would not terminate after the task finishes.

Exam trap

The trap here is assuming that any workload controller can run a batch job, when only Job (or CronJob) is designed for run-to-completion tasks.

Full explanation →

259

MCQhard

A Deployment is configured with 'strategy.type: RollingUpdate' and 'strategy.rollingUpdate.maxUnavailable: 0'. What is the effect during a rolling update?

A.The update will fail because maxUnavailable must be at least 1

B.The update will not proceed until at least one new pod is ready

C.The update will proceed without any downtime

D.No pod will be terminated until a new pod is ready

AnswerD

Setting maxUnavailable to 0 forces the Deployment controller to keep every existing pod running until each replacement pod passes its readiness probe. Surge capacity is used instead, so availability never dips during the rollout — satisfying the zero-downtime constraint implied by the stem.

Why this answer

Setting `maxUnavailable: 0` means the Deployment controller will not terminate any existing pod until a new pod is fully ready. This ensures zero disruption to the application during the rolling update, as the controller waits for the new pod to pass its readiness probe before scaling down the old ReplicaSet.

Exam trap

The trap here is that candidates often assume `maxUnavailable: 0` is invalid or causes the update to fail, when in fact it is a valid configuration that enforces a 'zero-downtime' update by preventing pod termination until new pods are ready.

How to eliminate wrong answers

Option A is wrong because `maxUnavailable` can be set to 0; it is a valid integer value that instructs the controller to allow no unavailable pods during the update. Option B is wrong because the update will proceed—the controller will create new pods—but it will not terminate old pods until the new ones are ready, not that the update halts entirely. Option C is wrong because while the update aims to avoid downtime, it does not guarantee zero downtime in all cases; for example, if the new pod fails its readiness probe, the update can stall, and there is still a brief period where old pods are running and new pods are starting, but no termination occurs until readiness is confirmed.

Full explanation →

260

MCQhard

A team uses ArgoCD with a Git repository that contains Helm charts. They want ArgoCD to automatically sync when a new image tag is pushed to the container registry. Which approach should they use?

A.Use Flux Image Automation Controller

B.Configure a webhook from the registry to ArgoCD API server

C.Manually update the Helm values and commit

D.Use ArgoCD Image Updater

AnswerD

ArgoCD Image Updater watches the container registry and writes the new image tag back into the Git repository, letting ArgoCD's existing sync detect the change. This satisfies the stem's requirement for automatic synchronisation triggered by a registry push, without manual commits or CI pipeline edits.

Why this answer

ArgoCD Image Updater is a purpose-built companion tool that watches container registries for new image tags and automatically updates the Kubernetes manifests or Helm values in the Git repository that ArgoCD tracks. Once the commit lands in Git, ArgoCD's normal sync process deploys the change, preserving GitOps principles.

Exam trap

The trap is assuming a registry webhook to ArgoCD is sufficient — but ArgoCD syncs from Git, so without updating the Git manifest, a webhook alone changes nothing.

How to eliminate wrong answers

Option A is wrong because Flux Image Automation Controller is part of the Flux ecosystem, not ArgoCD — mixing toolchains is not the intended ArgoCD-native solution. Option B is wrong because a registry webhook to the ArgoCD API server would only trigger a sync of the current Git state; it does not update the image tag in Git, so nothing would actually change. Option C is wrong because manual updates defeat the purpose of automation and are not a scalable GitOps approach.

Full explanation →

261

MCQmedium

A team wants to visualize metrics from Prometheus in a dashboard. Which tool is commonly used for this purpose?

A.Grafana

B.Alertmanager

C.Jaeger UI

D.Kibana

AnswerA

Grafana queries Prometheus directly through its native data source, rendering the time-series metrics as dashboards without altering the stored data. This satisfies the stem's requirement to visualise Prometheus metrics, since Grafana is purpose-built for dashboarding while Prometheus itself only offers basic expression-browser graphs.

Why this answer

Grafana is the de facto standard visualization tool for Prometheus metrics, connecting to Prometheus as a data source and rendering dashboards, graphs, and alerts. It supports PromQL queries directly and is widely deployed alongside Prometheus in Kubernetes environments.

Exam trap

The trap is confusing the observability stack roles — candidates may pick Kibana (visualization) without noting it pairs with Elasticsearch, not Prometheus.

How to eliminate wrong answers

Option B is wrong because Alertmanager handles routing and deduplication of alerts fired by Prometheus — it does not visualize metrics. Option C is wrong because Jaeger UI is a distributed tracing interface, not a metrics dashboard. Option D is wrong because Kibana visualizes Elasticsearch data (logs and documents), not Prometheus time-series metrics.

Full explanation →

262

MCQmedium

What is the smallest deployable unit in Kubernetes that can be created and managed?

A.Deployment

B.Node

C.Container

D.Pod

AnswerD

A pod wraps one or more containers sharing a network namespace and storage volumes, making it the atomic scheduling unit the scheduler places onto nodes. Containers alone cannot be scheduled; controllers such as Deployments manage pods, not individual containers.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers, shared storage, and a unique network IP. While containers are the runtime units, Kubernetes does not manage containers directly; it manages Pods, which are the atomic deployable and schedulable entities.

Exam trap

A common mistake is to assume a Container is the smallest deployable unit because containers are the runtime entities, but Kubernetes manages Pods, which are the smallest deployable and schedulable objects.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods; it is not the smallest deployable unit. Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit — Pods are scheduled onto Nodes. Option C is wrong because a Container is the runtime process, but Kubernetes cannot create or manage a container directly without wrapping it in a Pod; the Pod is the smallest unit that Kubernetes can schedule and manage.

Full explanation →

263

MCQeasy

What is the primary purpose of a Namespace in Kubernetes?

A.To set resource quotas for the entire cluster

B.To define network policies for pods

C.To manage node affinity rules

D.To isolate resources and provide a scope for names

AnswerD

Namespaces partition a single cluster into virtual scopes, letting teams isolate resources and reuse identical names across namespaces. This provides the name scoping and resource separation the question asks for, without creating separate physical clusters.

Why this answer

Namespaces in Kubernetes provide a mechanism for isolating groups of resources within a single cluster. They create separate scopes for resource names, meaning that resource names (like Pods or Services) only need to be unique within a Namespace, not across the entire cluster. This allows multiple teams or projects to share a cluster without naming conflicts, and it also enables cluster administrators to apply policies (like ResourceQuotas) and network policies at the Namespace level.

Exam trap

The trap here is that candidates confuse Namespaces with other cluster-level constructs like ResourceQuotas or NetworkPolicies, assuming Namespaces directly enforce limits or rules, when in fact Namespaces only provide the scope for names and isolation, while other objects (like ResourceQuotas, NetworkPolicies, and RBAC) are applied to that scope.

How to eliminate wrong answers

Option A is wrong because setting resource quotas for the entire cluster is not the primary purpose of a Namespace; ResourceQuotas are a separate Kubernetes object that can be applied to a Namespace to limit aggregate resource consumption, but Namespaces themselves do not enforce quotas. Option B is wrong because defining network policies for pods is the job of NetworkPolicy objects, which can be scoped to a Namespace, but the Namespace itself does not define network policies. Option C is wrong because managing node affinity rules is a function of PodSpec fields like nodeSelector and nodeAffinity, which are independent of Namespaces; Namespaces do not control which nodes Pods are scheduled on.

Full explanation →

264

Multi-Selectmedium

A developer is troubleshooting a Pod that is stuck in the Pending state. They want to gather information to determine why the Pod has not been scheduled. Which two commands or outputs are most directly useful for this diagnosis? (Choose two.)

Select 2 answers

A.Run `kubectl top pod <pod-name>` to check the Pod's CPU and memory usage against requests.

B.Run `kubectl logs <pod-name>` to read the application logs for scheduling errors.

C.Run `kubectl describe pod <pod-name>` and inspect the Events section at the bottom.

D.Run `kubectl get events --field-selector involvedObject.name=<pod-name>` to filter events for that Pod.

E.Run `kubectl exec -it <pod-name> -- /bin/sh` to inspect the container's environment.

AnswersC, D

The Events section from `kubectl describe pod` shows scheduler messages such as `FailedScheduling` with reasons like insufficient CPU, node affinity mismatch, or untolerated taints. It also shows image pull and volume errors after scheduling. For a Pending Pod, these events are the fastest way to see why the scheduler rejected candidate nodes, making this a primary diagnostic step.

Why this answer

For a Pending Pod, the scheduler's reasoning is exposed through events. `kubectl describe pod` surfaces FailedScheduling events with specific reasons, and `kubectl get events` with a field selector provides a filtered event timeline. Logs, exec, and top all require a running container, which does not exist before scheduling, so they cannot diagnose a Pending state. The two event-based approaches are the correct diagnostic tools.

Exam trap

The trap here is reaching for logs or exec on a Pending Pod, when those commands require a running container and the real information is in scheduler events.

Full explanation →

265

MCQmedium

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

A.Saga pattern

B.Database-per-service pattern

C.Shared database pattern

D.CQRS pattern

AnswerB

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

Why this answer

The Database-per-service pattern is the correct answer because it ensures each microservice owns and manages its own database, enforcing loose coupling and data encapsulation. This aligns with the cloud-native principle of decentralized data management, where services communicate only via APIs and never access each other's databases directly. It prevents tight coupling at the data layer, which is critical for independent scaling, deployment, and resilience in a microservices architecture.

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

266

MCQhard

A team wants to implement cost monitoring for their Kubernetes clusters. Which approach is most effective?

A.Use cloud provider billing APIs combined with resource utilization data

B.Use kubectl top to get resource usage

C.Estimate costs based on node count

D.Monitor CPU and memory usage with Prometheus

AnswerA

Provider billing APIs expose actual spend per cluster and namespace, while utilisation data attributes that cost to workloads, revealing idle or over-provisioned resources. Correlating the two axes is what enables meaningful cost monitoring rather than raw invoice totals alone.

Why this answer

Cloud provider billing APIs provide actual cost data per resource (e.g., per node, per persistent volume, per network egress), and combining this with resource utilization data (e.g., CPU/memory requests and actual usage from metrics) enables accurate cost allocation per namespace, pod, or workload. This approach directly maps infrastructure spend to Kubernetes abstractions, which is essential for chargeback or showback in multi-tenant clusters.

Exam trap

The trap here is that candidates confuse resource monitoring (CPU/memory) with cost monitoring, assuming that tracking utilization alone (e.g., with Prometheus or kubectl top) is sufficient to understand spending, when in fact cost data requires explicit billing integration.

How to eliminate wrong answers

Option B is wrong because 'kubectl top' only shows current resource usage (CPU/memory) for nodes and pods, not cost data; it lacks any billing context or historical aggregation needed for cost monitoring. Option C is wrong because estimating costs based solely on node count ignores variable costs like storage, network egress, and managed services (e.g., load balancers), leading to inaccurate cost attribution. Option D is wrong because Prometheus monitors resource utilization metrics (CPU, memory, disk I/O) but does not inherently provide cost data; it would need to be combined with pricing information from cloud provider APIs to calculate costs.

Full explanation →

267

MCQhard

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

A.Rely on vertical scaling of a single large node

B.Store all state in a single-zone database

C.Deploy all replicas in a single zone with a load balancer

D.Use a multi-zone cluster with anti-affinity rules and health checks

AnswerD

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

Why this answer

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

Exam trap

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

Full explanation →

268

MCQhard

A team uses Flux with the Source Controller and Kustomize Controller. They update a YAML file in Git to change a Deployment's replica count. What describes the synchronization flow?

A.The Source Controller directly applies the manifest to the cluster

B.Flux uses HelmReleases to apply changes

C.The Kustomize Controller fetches the source and applies the rendered manifests

D.Flux requires a manual kubectl apply to sync

AnswerC

The Kustomize Controller reconciles the Kustomization custom resource, fetching the Git source through the Source Controller's artefact and applying the rendered manifests to the cluster. This satisfies the stem's requirement that a Git commit changing replica count propagates without manual intervention, since the Kustomize Controller owns the apply step rather than the Source Controller.

Why this answer

In Flux's GitOps model, the Source Controller is responsible for fetching artifacts from sources like Git repositories, and the Kustomize Controller watches those sources, renders the Kustomize overlays, and applies the resulting manifests to the cluster. When a YAML file changes in Git, the Source Controller detects the new revision, and the Kustomize Controller reconciles the cluster to match the rendered output. This separation of concerns is core to Flux's controller architecture.

Exam trap

KCNA often tests the separation of responsibilities between Flux controllers, and candidates incorrectly assume the Source Controller applies manifests or that HelmReleases are used for Kustomize-based deployments.

How to eliminate wrong answers

Option A is wrong because the Source Controller only fetches and stores source artifacts — it does not apply manifests to the cluster; that is the job of the Kustomize or Helm controllers. Option B is wrong because HelmReleases are used by the Helm Controller when the source is a Helm chart, not when using Kustomize overlays. Option D is wrong because Flux is a GitOps operator that continuously reconciles automatically; manual kubectl apply defeats the purpose of GitOps and is not how Flux syncs.

Full explanation →

269

MCQeasy

Based on the exhibit, why is the pod web-pod not running?

A.A network policy is blocking the image pull.

B.The container image is not available in the registry.

C.The node does not have enough memory.

D.The pod was not scheduled onto a node.

AnswerB

Kubernetes reports ImagePullBackOff or ErrImagePull when the kubelet cannot fetch the specified image, meaning the tag is absent or the registry credentials are wrong. That condition, not scheduling or resource pressure, explains why web-pod is not running.

Why this answer

The pod's status indicates an ImagePullBackOff error, which occurs when the kubelet fails to pull the specified container image from the registry. This typically means the image name or tag is incorrect, the registry is unreachable, or the image does not exist in the registry. The exhibit shows the pod is stuck in a waiting state with the reason 'ErrImagePull' or 'ImagePullBackOff', directly pointing to a missing or inaccessible image.

Exam trap

The KCNA exam often tests the distinction between pod scheduling failures (e.g., resource constraints, taints/tolerations) and container runtime failures (e.g., image pull errors), so candidates may confuse a 'Pending' pod with an 'ImagePullBackOff' pod, both of which are not running but have different root causes.

How to eliminate wrong answers

Option A is wrong because network policies in Kubernetes control traffic between pods, not image pull operations; image pulls are handled by the container runtime (e.g., containerd, CRI-O) and are subject to registry authentication and network connectivity, not NetworkPolicy objects. Option C is wrong because a memory shortage on the node would manifest as an OOMKilled or Pod eviction, not an ImagePullBackOff error; the exhibit shows no resource pressure events. Option D is wrong because the pod has been scheduled onto a node (as indicated by the pod status showing a node name), but the container fails to start due to the image pull issue; unscheduled pods would show a 'Pending' status with no node assigned.

Full explanation →

270

MCQmedium

Which tool is specifically designed for distributed tracing and is a Cloud Native Computing Foundation (CNCF) graduated project?

A.Grafana

B.Fluentd

C.Jaeger

D.Prometheus

AnswerC

Jaeger provides distributed tracing by propagating context across service boundaries, letting you visualise request flows and pinpoint latency in microservices. It satisfies the CNCF graduated constraint, unlike Prometheus (metrics) or Fluentd (logs), making it the tool specifically designed for tracing in cloud-native environments.

Why this answer

Jaeger is a CNCF graduated project focused on distributed tracing.

Full explanation →

271

MCQeasy

Which component runs on each worker node and ensures that containers are running as specified in the Pod spec?

A.kubelet

B.kube-proxy

C.kube-scheduler

D.kube-controller-manager

AnswerA

The kubelet is the node agent that watches the API server for PodSpecs bound to its node and drives the container runtime to start, stop and restart containers so actual state matches the spec. It satisfies the per-worker-node constraint, unlike control-plane components such as the scheduler or controller manager.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives PodSpec definitions (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers, and it reports the node and pod status back to the control plane.

Exam trap

A common trap is confusing the kubelet (a node-level agent that runs on each worker and directly manages containers) with control-plane components like the kube-scheduler or kube-controller-manager, which run on the master node and handle cluster-level decisions.

How to eliminate wrong answers

Option B (kube-proxy) is wrong because it is a network proxy that runs on each node, handling service-to-pod routing and load balancing (e.g., via iptables or IPVS), not container lifecycle management. Option C (kube-scheduler) is wrong because it runs on the control plane and is responsible for assigning pods to nodes based on resource availability and constraints, not for running containers on a node. Option D (kube-controller-manager) is wrong because it runs on the control plane and manages controllers (e.g., ReplicaSet, Node Controller) that maintain desired cluster state, but it does not directly interact with containers on worker nodes.

Full explanation →

272

MCQmedium

Which component of the OpenTelemetry architecture is responsible for receiving data from instrumented applications and processing it before export?

A.OpenTelemetry SDK

B.OpenTelemetry API

C.OpenTelemetry Collector

D.OpenTelemetry exporter

AnswerC

The OpenTelemetry Collector receives telemetry from instrumented applications via OTLP receivers, then processes it through configurable processors before exporting to backends. This satisfies the stem's requirement for a component that both receives and processes data, unlike SDKs, which only generate and emit telemetry from within the application process itself.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic component that receives telemetry (traces, metrics, logs) from instrumented applications via receivers, processes it (batching, filtering, sampling, attribute enrichment), and exports it to one or more backends. It decouples applications from backend-specific exporters.

Exam trap

The trap is confusing the SDK (in-app instrumentation) with the Collector (out-of-process receiver/processor/exporter) — the question specifically asks about receiving and processing data from applications.

How to eliminate wrong answers

Option A is wrong because the SDK is the in-process library that instruments application code and generates telemetry — it does not receive and process data from other applications. Option B is wrong because the API defines the interfaces and no-op implementations used by instrumentation libraries; it does not process or export data. Option D is wrong because an exporter is only the final stage of the Collector (or SDK) pipeline that sends data to a backend — it does not receive or process data on its own.

Full explanation →

273

MCQeasy

A Pod is in the 'Pending' state. What is the most likely cause?

A.The Pod is still being scheduled because no Node has enough resources

B.The container image is missing

C.The Service referencing the Pod does not exist

D.The application inside the container has crashed

AnswerA

A Pod remains in 'Pending' when the scheduler cannot find a Node that satisfies its resource requests, such as CPU or memory limits. The kube-scheduler evaluates each Node’s allocatable capacity against the Pod’s specified requests; if no Node has sufficient unallocated resources, the Pod is unschedulable and stays Pending. This directly satisfies the constraint of insufficient Node capacity.

Why this answer

A Pod in 'Pending' state means the Pod has been accepted by the API server but is not yet running. The most common reason is that the scheduler cannot find a Node with sufficient CPU, memory, or other resources to place the Pod. This triggers the scheduler to continuously attempt to bind the Pod to a suitable Node, leaving it in Pending until resources become available or the Pod is deleted.

Exam trap

A common pitfall is confusing Pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) with error states like CrashLoopBackOff or ImagePullBackOff. Candidates often wrongly attribute 'Pending' to application-level failures instead of scheduling issues.

How to eliminate wrong answers

Option B is wrong because a missing container image causes the Pod to enter 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending'. Option C is wrong because a missing Service does not affect Pod scheduling; Services are decoupled from Pod lifecycle and only affect network routing after the Pod is running. Option D is wrong because an application crash inside the container results in 'CrashLoopBackOff' or 'Error' state, not 'Pending'.

Full explanation →

274

MCQhard

A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?

A.The kubelet on the node where the pod is running

B.The Service's endpoint slices

C.kube-proxy on the nodes

D.CoreDNS pods in the kube-system namespace

AnswerD

CoreDNS provides cluster DNS resolution for Services, so its pods in kube-system are the first thing to verify. Since pod-to-pod IP communication already works, the CNI and kube-proxy are functioning; the failure is isolated to name resolution, which CoreDNS handles directly.

Why this answer

DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.

Exam trap

A common misconception is that DNS failures are caused by kube-proxy or network proxy issues, when in fact DNS resolution is a separate layer handled by CoreDNS, and candidates should first verify the DNS pods themselves.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for managing pod lifecycle and container runtime, not for DNS resolution or Service name resolution. Option B is wrong because endpoint slices define the actual pod IPs backing a Service, but DNS resolution depends on CoreDNS querying the API server, not on the endpoints themselves; if DNS fails, endpoint slices are irrelevant. Option C is wrong because kube-proxy handles network proxy rules for Service traffic (e.g., iptables or IPVS), but DNS name resolution is a separate function performed by CoreDNS; kube-proxy does not resolve DNS names.

Full explanation →

275

MCQeasy

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

A.To develop proprietary cloud native software

B.To define the 12-factor app methodology

C.To host and promote open source cloud native projects

D.To provide certification exams for Kubernetes administrators

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

276

MCQmedium

A container image built using a Dockerfile with multiple layers is stored in a registry. When a node pulls this image, which statement about layers is true?

A.Layers that are already cached on the node are reused and only new layers are downloaded

B.Layers are merged into a single layer before download

C.All layers must be downloaded each time the image is pulled

D.Only the topmost layer is downloaded; lower layers are streamed from the registry

AnswerA

Cached layers are content-addressed by digest, so the node verifies each layer locally and fetches only digests absent from its local store. This satisfies the stem's constraint: a multi-layer image pull avoids re-downloading unchanged layers, transferring just the new layers.

Why this answer

Container images are composed of read-only layers, each representing a set of filesystem changes. When a node pulls an image, the container runtime (e.g., containerd or CRI-O) checks its local layer cache against the manifest's layer digests (SHA256 hashes). Layers already present locally are reused, and only missing layers are downloaded from the registry, which optimizes bandwidth and storage.

Exam trap

The KCNA exam often tests the misconception that layers are merged or streamed, but the correct behavior is that each layer is a separate, immutable blob that is cached independently and reused across images.

How to eliminate wrong answers

Option B is wrong because layers are never merged into a single layer before download; they remain separate and are stored as individual blobs in the registry and on the node, enabling layer sharing across images. Option C is wrong because the container runtime uses the layer cache to avoid re-downloading unchanged layers; only layers not already cached are downloaded. Option D is wrong because all layers must be fully downloaded and stored locally before the image can be used; the runtime does not stream layers on demand from the registry.

Full explanation →

277

Multi-Selecteasy

Which TWO of the following tools are commonly used for distributed tracing in cloud-native environments? (Select two.)

Select 2 answers

A.Zipkin

B.Grafana

C.Jaeger

D.Fluentd

E.Prometheus

AnswersA, C

Zipkin satisfies the distributed tracing requirement by collecting and correlating span data across microservices, using trace and span IDs propagated through request headers to reconstruct end-to-end request flows. Its lightweight, vendor-neutral design suits cloud-native architectures, where it commonly pairs with instrumentation libraries to visualise latency across service boundaries.

Why this answer

Zipkin (A) is correct because it is a dedicated distributed tracing system that collects and visualizes latency data across microservice call chains using trace and span IDs propagated via headers such as B3. Jaeger (C) is also correct because it is a CNCF-graduated distributed tracing platform that instruments requests across services, supports OpenTracing/OpenTelemetry, and provides trace storage and a UI for span analysis. Grafana (B) is primarily a visualization and dashboarding layer that can query tracing backends but is not itself a tracing system.

Fluentd (D) is a log collection and forwarding agent, and Prometheus (E) is a metrics monitoring and time-series database, neither of which performs distributed request tracing.

Exam trap

The trap is selecting Grafana or Prometheus because they appear in observability stacks — but tracing requires a dedicated tracing backend, and Grafana is only a frontend that can query one.

Full explanation →

278

MCQmedium

You are writing a Pod manifest and need to ensure the container always pulls the newest image from the registry, even if an image with the same tag already exists on the node. Which imagePullPolicy should you set?

A.Latest

B.Never

C.Always

D.IfNotPresent

AnswerC

Setting imagePullPolicy to Always forces the kubelet to contact the container registry and pull the image every time a container is started, regardless of whether an image with that tag is already cached on the node. This guarantees you get the most recent image content behind a mutable tag such as latest, which is exactly the requirement in this scenario.

Why this answer

The imagePullPolicy field controls whether the kubelet consults the node's local image cache or the registry. Always is the only policy that unconditionally pulls on every container start, which is what guarantees fresh content when a mutable tag is reused. IfNotPresent and Never both allow a stale cached image to run, and Latest is not a recognized policy value.

Exam trap

The trap here is confusing the image tag latest with the imagePullPolicy value Always, since a tag named latest does not by itself force a registry pull.

Full explanation →

279

MCQmedium

You are reviewing the manifest for a Pod that must only run on nodes with the label `disktype=ssd`. The manifest includes the following snippet: ```yaml nodeSelector: disktype: ssd ``` After applying the manifest, the Pod remains in Pending state indefinitely. `kubectl get nodes --show-labels` shows no node has the `disktype=ssd` label. Which action will allow the Pod to be scheduled without modifying the Pod's nodeSelector?

A.Add an annotation `disktype=ssd` to a node with `kubectl annotate nodes <node-name> disktype=ssd`.

B.Edit the Pod's nodeSelector to an empty map so it matches any node, then reapply the manifest.

C.Create a taint on a node with `kubectl taint nodes <node-name> disktype=ssd:NoSchedule` so the scheduler treats it as matching.

D.Add the label `disktype=ssd` to at least one node using `kubectl label nodes <node-name> disktype=ssd`.

AnswerD

The scheduler filters nodes using the Pod's nodeSelector, and no node currently carries the `disktype=ssd` label, so the Pod stays Pending. Labeling a suitable node with that exact key and value makes it eligible, and the scheduler will bind the Pod there without editing the Pod spec. This is the intended way to satisfy a nodeSelector requirement.

Why this answer

A Pod with nodeSelector only lands on nodes whose labels match every specified key-value pair. Because no node currently has `disktype=ssd`, the scheduler cannot find a feasible node and the Pod stays Pending. Labeling an appropriate node with that exact pair makes it feasible, allowing scheduling without altering the Pod manifest.

The other actions either use the wrong metadata type or change the Pod spec.

Exam trap

The trap here is confusing taints, annotations, or empty selectors with labels, when nodeSelector strictly matches node labels.

Full explanation →

280

MCQhard

In PromQL, which function would you use to calculate the per-second rate of increase of a counter over a specified time window?

A.rate()

B.delta()

C.avg_over_time()

D.increase()

AnswerA

rate() computes the per-second average rate of increase of a counter over the given range window, automatically handling counter resets. It directly satisfies the stem's requirement to derive per-second increase from a monotonically increasing counter, unlike irate() or increase().

Why this answer

The rate() function calculates the per-second average rate of increase of a counter over a time range.

Full explanation →

281

MCQhard

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

A.Circuit Breaker pattern

B.Retry pattern

C.Bulkhead pattern

D.Timeout pattern

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

282

MCQeasy

What is the purpose of a readiness probe in a Kubernetes pod?

A.To determine if the pod should be terminated

B.To check if the pod is alive and restart it if not

C.To measure CPU usage of the container

D.To signal that the pod is ready to accept traffic

AnswerD

A readiness probe determines whether a container is prepared to serve requests, controlling whether the pod's IP is included in Service endpoints. Failing probes remove the pod from load balancing without restarting it, satisfying the requirement to signal traffic acceptance rather than container liveness or startup completion.

Why this answer

A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring that only healthy pods receive requests. This is distinct from liveness probes, which check if the container is alive and should be restarted.

Exam trap

The trap here is that candidates often confuse readiness probes with liveness probes, mistakenly thinking both are used for restarting unhealthy containers, when in fact readiness probes only control traffic routing and do not trigger restarts.

How to eliminate wrong answers

Option A is wrong because readiness probes do not determine pod termination; that is the role of the liveness probe or the pod's terminationGracePeriodSeconds. Option B is wrong because checking if the pod is alive and restarting it is the purpose of a liveness probe, not a readiness probe. Option C is wrong because measuring CPU usage is done via metrics servers or resource monitoring tools like Prometheus, not through probes.

Full explanation →

283

Multi-Selectmedium

Which TWO statements correctly describe the purpose of etcd in a Kubernetes cluster?

Select 2 answers

A.It stores the cluster state, including all Kubernetes objects.

B.It manages network rules for Pod-to-Pod communication.

C.It schedules Pods onto nodes based on resource availability.

D.It exposes the Kubernetes API for external access.

E.It is a distributed key-value store that provides high availability and consistency.

AnswersA, E

etcd is the cluster's sole source of truth, persisting the entire state of every Kubernetes object — Pods, Services, Deployments, ConfigMaps and more. The API server reads and writes all object data exclusively through etcd, making this storage role fundamental.

Why this answer

Option A is correct because etcd is the backing store for all Kubernetes cluster data: every API object (Pods, Services, ConfigMaps, Secrets, etc.) is serialized and persisted in etcd, making it the single source of truth for cluster state. Option E is correct because etcd is fundamentally a distributed key-value store built on the Raft consensus algorithm, which replicates data across members to deliver high availability and strong consistency (linearizable reads/writes). Option B is wrong because Pod-to-Pod network rules are implemented by the CNI plugin and kube-proxy (iptables/IPVS or eBPF), not etcd.

Option C is wrong because Pod scheduling is the job of kube-scheduler, which watches the API server and binds Pods to nodes. Option D is wrong because the Kubernetes API is exposed by kube-apiserver; etcd only serves as its storage backend and is not itself an API endpoint for clients.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the components that use that state (scheduler, controller manager, API server), so the trap here is confusing etcd's role as a passive data store with the active management functions of other control plane components.

Full explanation →

284

MCQhard

In OpenTelemetry, what is the purpose of the Collector component?

A.Instrument code automatically

B.Receive, process, and export telemetry data

C.Visualize traces and metrics

D.Aggregate logs from multiple sources

AnswerB

The Collector is a vendor-agnostic pipeline that receives telemetry via OTLP or other receivers, processes it through processors such as batching and filtering, then exports it to backends. This receive-process-export flow satisfies the stem's requirement for a central telemetry handling component.

Why this answer

The OpenTelemetry Collector is a vendor-agnostic agent or gateway that receives telemetry data (traces, metrics, logs) from instrumented applications, processes it (e.g., batching, filtering, sampling), and exports it to one or more backends (e.g., Jaeger, Prometheus, or any OTLP-compatible system). It decouples data generation from data export, enabling flexible pipeline management without modifying application code.

Exam trap

CNCF often tests the distinction between the Collector's role (data pipeline) and other components like SDKs (instrumentation) or backends (visualization/storage), so candidates mistakenly associate the Collector with auto-instrumentation or visualization.

How to eliminate wrong answers

Option A is wrong because automatic code instrumentation is the role of OpenTelemetry SDKs and auto-instrumentation agents (e.g., Java agent), not the Collector; the Collector does not instrument code. Option C is wrong because visualization of traces and metrics is the responsibility of backend tools like Jaeger UI, Grafana, or Prometheus, not the Collector, which only processes and forwards data. Option D is wrong because while the Collector can handle logs, its primary purpose is not limited to log aggregation; it is a unified pipeline for traces, metrics, and logs, and log aggregation alone is a narrower function often served by tools like Fluentd or Logstash.

Full explanation →

285

Drag & Dropmedium

Drag and drop the steps to create a Kubernetes Namespace and deploy an application into it 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 create namespace, then deploy resources specifying that namespace, and verify.

Full explanation →

286

MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod' and see the event '0/3 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 2 node(s) had insufficient memory.'. What is the most likely cause?

A.The pod does not have tolerations for the node's taints and memory is insufficient on other nodes

B.The kube-scheduler is not running

C.The container runtime is not installed on any node

D.The pod's resource requests exceed available resources on all nodes

AnswerA

The scheduler event shows two distinct blockers: one node rejected the pod due to an untolerated taint, and the other two lacked sufficient memory. No node therefore satisfies both taint tolerations and resource requests, leaving the pod unscheduled.

Why this answer

The event '0/3 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 2 node(s) had insufficient memory' directly indicates that the pod failed scheduling because it lacks required tolerations for a tainted node, and the remaining nodes do not have enough memory to satisfy the pod's resource requests. This matches option A, as the pod's tolerations are missing for the tainted node, and memory is insufficient on the other two nodes.

Exam trap

The CNCF exam often tests the distinction between scheduling failures (like taints and resource insufficiency) and runtime failures (like missing container runtime or scheduler), tricking candidates into picking a generic cause like 'kube-scheduler not running' when the detailed event clearly shows the scheduler is working.

How to eliminate wrong answers

Option B is wrong because if the kube-scheduler were not running, the pod would remain in Pending state but no scheduling events would appear at all; the specific event about taints and insufficient memory proves the scheduler is actively evaluating nodes. Option C is wrong because a missing container runtime would cause the pod to fail at the kubelet level with a different event (e.g., 'failed to create container'), not a scheduling event about taints and memory. Option D is wrong because while insufficient memory is part of the issue, the event explicitly mentions a taint that the pod didn't tolerate, which is a separate scheduling constraint not covered by resource requests alone.

Full explanation →

287

MCQmedium

A platform engineer applies a Pod manifest that includes the field `spec.nodeName: k8s-worker-07`. The scheduler is running normally. What is the most accurate description of what happens to this Pod?

A.The API server rejects the manifest because nodeName cannot be set by users; it is only written by kube-scheduler.

B.The Pod is placed on k8s-worker-07 without kube-scheduler involvement, and the kubelet there attempts to run it regardless of taints or resource fit.

C.The kube-scheduler evaluates node affinity and taints before binding the Pod to k8s-worker-07.

D.The Pod is bound directly to k8s-worker-07 by the kubelet on that node, skipping the scheduler's binding step.

AnswerB

Pre-setting spec.nodeName is a manual scheduling shortcut: kube-scheduler never sees the Pod as unscheduled, so no filtering predicates, taints, or resource-fit checks are applied. The kubelet on the named node observes the Pod and tries to start it, but if the node is tainted with NoExecute or lacks capacity, the kubelet may reject or evict it. This is why nodeName is discouraged for production scheduling.

Why this answer

Populating spec.nodeName directly is the classic manual-scheduling pattern: kube-scheduler only considers Pods with an empty nodeName, so a Pod that already names a node skips the entire scheduling framework, including taint and affinity checks. The kubelet on the named node then takes over, and any resource or taint mismatch surfaces as a kubelet-level failure rather than a Pending Pod event.

Exam trap

The trap here is assuming kube-scheduler always validates placement, when a pre-set nodeName makes the Pod invisible to the scheduler entirely.

Full explanation →

288

MCQmedium

A cluster administrator needs to run a node-level log collector that must read files from /var/log on every node in the cluster, including nodes added later. The collector does not need to run on control plane nodes. Which Kubernetes resource should be used?

A.DaemonSet

B.Job with parallelism set to the node count

C.StatefulSet with podAntiAffinity

D.Deployment with replicas equal to the number of nodes

AnswerA

A DaemonSet ensures that a copy of a Pod runs on every eligible node, including nodes added after the DaemonSet is created. The collector can mount hostPath /var/log and apply a nodeSelector or affinity to exclude control plane nodes, satisfying the requirement without manual scheduling.

Why this answer

A DaemonSet is the correct resource because it schedules exactly one Pod on each node that matches its node selector or affinity rules, and it automatically adds Pods to new nodes as they join the cluster. This makes it ideal for node-level agents such as log collectors, monitoring daemons, and network plugins that must run everywhere.

Exam trap

The trap here is assuming a Deployment with replica count matching node count provides per-node coverage, when only a DaemonSet guarantees one Pod per eligible node and handles new nodes automatically.

Full explanation →

289

MCQmedium

Which Kubernetes resource should be used to run a one-time task that performs a computation and then exits?

A.DaemonSet

B.StatefulSet

C.Job

D.Deployment

AnswerC

A Job creates one or more pods that run to completion, then stops restarting them once the task succeeds. This directly satisfies the stem's requirement for a one-time computation that exits, unlike a Deployment, which maintains a continuous desired replica count for long-running services.

Why this answer

A Kubernetes Job is designed specifically for finite, one-time tasks that run to completion and then exit. Unlike controllers that maintain a desired number of continuously running Pods, a Job creates one or more Pods and tracks their successful termination, making it the correct choice for a computation that should run once and stop.

Exam trap

The trap here is that candidates confuse a Job with a Deployment because both can run containers, but a Deployment is designed for long-running services, not for tasks that should terminate after completion.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, intended for long-running background services like log collectors or monitoring agents, not for one-time tasks. Option B is wrong because a StatefulSet manages stateful applications with stable, unique network identities and persistent storage, designed for workloads like databases that require ordered deployment and scaling, not ephemeral computations. Option D is wrong because a Deployment manages a ReplicaSet to maintain a desired number of continuously running Pods, supporting rolling updates and self-healing, which is unnecessary overhead for a task that should exit after completion.

Full explanation →

290

MCQmedium

Which component runs on every Kubernetes node and ensures that the containers in a pod are running?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.container runtime

AnswerC

The kubelet is the node agent that watches the API server for pod assignments and directly manages container lifecycles via the container runtime, restarting failed containers to maintain the desired state. This satisfies the stem's requirement for a per-node component guaranteeing that a pod's containers keep running.

Why this answer

The kubelet is the primary node agent that runs on every Kubernetes node. It receives PodSpec definitions from the API server and ensures that the containers described in those PodSpecs are running and healthy. It continuously monitors container status and takes corrective actions, such as restarting containers that have failed, making it the correct answer.

Exam trap

The trap here is that candidates often confuse the container runtime (which physically runs containers) with the kubelet (which orchestrates and monitors them), leading them to select 'container runtime' instead of 'kubelet'.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic to pods; it does not manage container lifecycle. Option B is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints; it does not run on worker nodes and does not ensure containers are running. Option D is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is the kubelet that interacts with the container runtime via the Container Runtime Interface (CRI) to enforce the desired state; the runtime alone does not perform health monitoring or reconciliation.

Full explanation →

291

MCQmedium

What is the purpose of a liveness probe in a Kubernetes pod?

A.To check if the pod is scheduled on a node

B.To check if the container has started successfully

C.To check if the application is ready to serve traffic

D.To check if the application is still running; if not, restart the container

AnswerD

A liveness probe periodically tests the container; on failure kubelet restarts it according to the pod's restartPolicy. This recovers hung or deadlocked processes that are still running but unresponsive, unlike a readiness probe, which only removes the pod from Service endpoints.

Why this answer

A liveness probe in Kubernetes is used to determine if a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it based on the pod's restart policy. This ensures that applications that have entered a deadlock or hung state are automatically recovered without manual intervention.

Exam trap

The trap here is that candidates often confuse liveness probes with readiness probes, mistakenly thinking liveness determines traffic readiness, but liveness is solely about container health and automatic restarts, not service connectivity.

How to eliminate wrong answers

Option A is wrong because checking if a pod is scheduled on a node is the role of the Kubernetes scheduler and is reflected in the pod's status, not a liveness probe. Option B is wrong because checking if a container has started successfully is the purpose of a startup probe, which runs before other probes to allow slow-starting applications time to initialize. Option C is wrong because checking if the application is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod receives traffic from Services, not whether it should be restarted.

Full explanation →

292

MCQeasy

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

A.Monolithic application design

B.Manual scaling of applications

C.Static infrastructure provisioning

D.Microservices packaged in containers

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

293

MCQeasy

Which of the following is the correct definition of a Service Level Indicator (SLI)?

A.A formal contract between a service provider and a customer

B.A target value or range for a metric, agreed upon with stakeholders

C.A quantitative measure of a specific aspect of the service's reliability

D.A tool for aggregating logs from multiple sources

AnswerC

An SLI is the quantitative measurement itself — for example request latency or error rate — expressed as a number, which is then compared against an SLO target. It measures a specific reliability aspect of the service rather than defining a threshold or agreement.

Why this answer

An SLI is a quantitative measure of a specific aspect of a service's reliability — for example, request latency, error rate, or availability — expressed as a ratio of good events to total events. It is the raw measurement that feeds into SLOs and error budgets, not a contract or a target.

Exam trap

KCNA often tests confusion between SLI, SLO, and SLA, tricking candidates into selecting the SLO definition (target value) when the question asks for the SLI (the measurement itself).

How to eliminate wrong answers

Option A is wrong because a formal contract between provider and customer is a Service Level Agreement (SLA), which is a legal/business document, not a measurement. Option B is wrong because a target value or range agreed with stakeholders is a Service Level Objective (SLO), which is built on top of SLIs. Option D is wrong because log aggregation is a logging/observability function (e.g., Fluentd, Loki), not an SLI definition.

Full explanation →

294

Multi-Selecthard

A developer is troubleshooting a Pod that is stuck in Pending state. The node has sufficient CPU and memory, and the scheduler logs show no errors. Which two factors could prevent the Pod from being scheduled? (Choose two.)

Select 2 answers

A.A taint on all nodes that the Pod does not tolerate

B.The Pod's container image has a latest tag

C.The Pod's ServiceAccount is missing

D.A nodeSelector that does not match any node's labels

E.The Pod has no resource requests defined

AnswersA, D

Taints repel Pods unless the Pod has a matching toleration. If every node is tainted and the Pod lacks the toleration, the scheduler will not place it, resulting in Pending. This is independent of resource availability. Taints and tolerations are a frequent cause of unschedulable Pods in multi-tenant clusters.

Why this answer

Node selectors and taints both restrict which nodes can run a Pod. A nodeSelector that matches no node or a taint that the Pod does not tolerate will leave the Pod unschedulable, resulting in Pending. Image tags, missing resource requests, and ServiceAccount issues affect other stages or have different symptoms, so they are not correct.

Exam trap

The trap here is assuming any Pod configuration error causes Pending, when Pending specifically indicates the scheduler cannot place the Pod.

Full explanation →

295

MCQeasy

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

A.ArgoCD

B.Helm

C.Terraform

D.Jenkins

AnswerA

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

Why this answer

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

Full explanation →

296

Drag & Dropmedium

Drag and drop the steps to troubleshoot a Pod stuck in CrashLoopBackOff into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Start with describe for events, then logs for errors, check resources, verify image/command, then fix and redeploy.

Full explanation →

297

Multi-Selectmedium

Which TWO of the following are deployment patterns that can be used to update applications with minimal downtime? (Choose two.)

Select 2 answers

A.DaemonSet deployment

B.Sidecar deployment

C.Recreate deployment

D.Blue-green deployment

E.Canary deployment

AnswersD, E

Blue-green deployment runs two identical environments, switching traffic from the old (blue) to the new (green) only after the new version is verified. This satisfies the stem's minimal-downtime constraint because the cutover is near-instantaneous and rollback is immediate.

Why this answer

Blue-green deployment (D) is correct because it runs two identical production environments and switches traffic from the old (blue) version to the new (green) version only after the new one is fully deployed and tested, so the cutover is near-instantaneous and downtime is minimal. Canary deployment (E) is correct because it releases the new version to a small subset of users or traffic first, then gradually shifts the remaining traffic once the canary proves healthy, allowing updates with minimal downtime and easy rollback. DaemonSet deployment (A) is not a deployment pattern for updating an application with minimal downtime; it is a Kubernetes workload that ensures one pod runs on every (or selected) node, typically for cluster-level agents.

Sidecar deployment (B) is an architectural pattern where a helper container runs alongside the main application container in the same pod, not a strategy for rolling out new application versions. Recreate deployment (C) stops all old instances before starting new ones, which inherently causes downtime, so it does not meet the minimal-downtime requirement.

Full explanation →

298

MCQmedium

A developer wants to deploy a stateless web application that should scale to 5 replicas. Each replica must be identical and should be automatically replaced if it fails. Which Kubernetes resource should be used?

A.StatefulSet

B.DaemonSet

C.Deployment

D.ReplicationController

AnswerC

Deployment manages stateless pods through ReplicaSet, maintaining exactly five identical replicas and automatically replacing failed pods to satisfy the self-healing and scaling constraints. Its rolling update strategy suits stateless workloads, unlike StatefulSet's stable identities or DaemonSet's per-node scheduling.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of identical, stateless pod replicas (5) are running. It provides declarative updates, self-healing (automatic replacement of failed pods), and scaling capabilities, which directly match the requirement for a stateless web application.

Exam trap

The trap here is that candidates often confuse StatefulSet with Deployment for stateless apps because both can manage multiple replicas, but StatefulSet is specifically for stateful workloads requiring ordered deployment and stable identities, not for identical, interchangeable replicas.

How to eliminate wrong answers

Option A is wrong because StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage, not for stateless web apps where replicas are identical and can be replaced arbitrarily. Option B is wrong because DaemonSet ensures that a copy of a pod runs on every (or selected) node in the cluster, which is used for cluster-level services like logging or monitoring, not for scaling a stateless web app to a specific replica count. Option D is wrong because ReplicationController is the older, deprecated predecessor of Deployment; it can maintain a desired number of pod replicas but lacks advanced features like rolling updates, declarative management, and is not the recommended resource for modern Kubernetes deployments.

Full explanation →

299

MCQmedium

A team wants to run a batch job that must complete successfully exactly once and then stop. The job processes a queue and should not be restarted after successful completion. Which Kubernetes resource is most appropriate for this requirement?

A.DaemonSet

B.Job

C.StatefulSet

D.Deployment

AnswerB

A Job creates one or more Pods and ensures that a specified number complete successfully. With a default completions and parallelism of 1, it runs a single Pod to completion and does not restart it after success. This matches the requirement for a one-time batch task that terminates when finished, unlike long-running workload controllers.

Why this answer

Job is the controller designed for run-to-completion workloads. It tracks successful Pod completions and stops creating new Pods once the required count is reached. Deployments, DaemonSets, and StatefulSets all maintain long-running Pods and would not naturally terminate after a single successful execution, making them inappropriate for this batch processing requirement.

Exam trap

The trap here is assuming any workload controller can run a one-off task, when only Job and CronJob are built around completion rather than continuous availability.

Full explanation →

300

Multi-Selectmedium

A team is designing a Kubernetes architecture for a new application. They need to understand which components are part of the control plane and which run on worker nodes. Which TWO of the following components run on every worker node in a standard Kubernetes cluster? (Choose two.)

Select 2 answers

A.kube-proxy

B.kube-controller-manager

C.kube-scheduler

D.kubelet

E.etcd

AnswersA, D

kube-proxy runs on every worker node and maintains network rules that allow communication to Pods from inside or outside the cluster. It implements Service abstraction by programming iptables or IPVS rules, enabling load balancing across Pod endpoints.

Why this answer

kubelet and kube-proxy are the two components that run on every worker node. kubelet manages Pods on the node, and kube-proxy handles Service networking. The scheduler, etcd, and controller manager are control plane components.

Exam trap

The trap here is mixing control plane components with node components, especially assuming kube-scheduler or kube-controller-manager run on workers because they manage workloads.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 226–300