Kubernetes and Cloud Native Associate KCNA KCNA Questions 601–675 | Page 9/13

601

Multi-Selecthard

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

Select 3 answers

A.Automatic scaling of pods

B.Increased application performance

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

D.Improved observability through metrics and tracing

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

AnswersC, D, E

Service mesh enables advanced traffic routing.

Why this answer

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

Exam trap

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

Full explanation →

602

MCQhard

A Kubernetes administrator needs to ensure that a set of pods can only communicate with each other and with a specific external API, while blocking all other traffic. Which Kubernetes feature should be used to enforce this?

A.Ingress

B.PodSecurityPolicy

C.NetworkPolicy

D.Service mesh

AnswerC

NetworkPolicy is a Kubernetes resource that defines how groups of pods are allowed to communicate with each other and other network endpoints. By selecting pods with a label selector, you can define ingress and egress rules to allow traffic only from specific pods or to specific external IPs. This enforces the required isolation and allows communication with the external API.

Why this answer

NetworkPolicy is the native Kubernetes resource for specifying allowed ingress and egress traffic for pods. It uses label selectors to choose pods and defines rules based on IP blocks, namespaces, or pod selectors. This allows restricting communication to only the desired pods and external API.

Other options like Ingress or PodSecurityPolicy do not provide network segmentation.

Exam trap

The trap here is confusing Ingress with NetworkPolicy; Ingress is for external HTTP routing, while NetworkPolicy controls pod-level network access.

Full explanation →

603

Multi-Selecthard

Which THREE of the following are valid reasons to use a StatefulSet instead of a Deployment? (Select 3)

Select 3 answers

A.The application needs to be scaled up and down quickly without regard to order.

B.The application requires stable unique network identifiers that persist across rescheduling.

C.The application is stateless and can be replicated arbitrarily.

D.Each Pod instance requires its own persistent storage that persists across rescheduling.

E.The application must handle graceful shutdown and ordered termination.

AnswersB, D, E

StatefulSet pods receive stable, ordinal-based hostnames through a governing headless Service, so each replica keeps a predictable DNS identity such as web-0 or web-1 across rescheduling. Deployments assign random pod names and share one Service address, offering no per-pod identity. This satisfies the stem's requirement for persistent unique network identifiers.

Why this answer

Option B is correct because StatefulSets give each Pod a stable, unique network identity via a headless Service and predictable DNS names (pod-0, pod-1, etc.) that persist across rescheduling, which Deployments do not guarantee. Option D is correct because StatefulSets use volumeClaimTemplates to bind a dedicated PersistentVolumeClaim to each Pod, so each replica keeps its own persistent storage across rescheduling, unlike a Deployment where all replicas typically share or lack per-Pod PVCs. Option E is correct because StatefulSets provide ordered, graceful deployment and scaling (0..N-1) and reverse-order termination with graceful shutdown, which is essential for clustered stateful apps.

Option A is not a reason to use a StatefulSet because unordered, rapid scaling is exactly what Deployments handle well. Option C is not a reason because stateless, arbitrarily replicable workloads are the canonical use case for Deployments, not StatefulSets.

Exam trap

A common misconception is that StatefulSets are for any application needing scaling, but the trap is that StatefulSets are specifically for stateful workloads requiring stable identity and storage, not for stateless or unordered scaling scenarios.

Full explanation →

604

MCQhard

A pod is running but its container exits with code 137. The pod logs show 'Killed'. What is the most likely cause?

A.The container's CPU limit was exceeded

B.The container's liveness probe failed

C.The container was OOMKilled due to memory limit

D.The node ran out of disk space

AnswerC

Exit code 137 equals 128 plus signal 9 (SIGKILL), which the kernel sends when a container exceeds its cgroup memory limit. The OOM killer terminates the process, producing the 'Killed' log entry rather than an application-level crash.

Why this answer

Exit code 137 (128 + 9) indicates the container was terminated by SIGKILL. Combined with 'Killed' in logs, this is the definitive signature of an OOMKill event, where the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process because it exceeded its memory limit (specified in the pod's resource limits). Kubernetes enforces memory limits via cgroups, and when the container's memory usage surpasses the limit, the OOM killer sends SIGKILL, resulting in exit code 137.

Exam trap

CNCF often tests the distinction between CPU throttling (which does not kill) and OOMKill (which does), and the trap here is that candidates confuse 'Killed' in logs with a generic failure, not recognizing exit code 137 as the specific OOMKill signal.

How to eliminate wrong answers

Option A is wrong because exceeding CPU limits causes CPU throttling (container runs slower) but never triggers a kill or exit code 137; the container continues running. Option B is wrong because a liveness probe failure results in Kubernetes restarting the container with exit code 143 (SIGTERM) or 0, not 137, and the logs would show 'Liveness probe failed' not 'Killed'. Option D is wrong because node disk pressure leads to pod eviction (not container OOM kill) with a different exit code and a Kubernetes event like 'Evicted', not exit code 137 and 'Killed' in container logs.

Full explanation →

605

MCQhard

A cluster administrator runs `kubectl taint nodes node1 dedicated=gpu:NoSchedule` and then creates a Pod with toleration `dedicated=gpu:NoSchedule` but no node affinity. What is the resulting behavior?

A.The taint is removed from node1 automatically once a Pod with the matching toleration is scheduled there.

B.The Pod is guaranteed to run on node1 because the toleration matches the taint.

C.The Pod remains Pending because tolerations must be paired with node affinity to be valid.

D.The Pod can be scheduled on node1, but it may also be scheduled on any other node that passes the scheduler's filters.

AnswerD

Taints repel Pods that lack matching tolerations, and a toleration merely removes that repulsion for the tainted node. The scheduler then scores all feasible nodes, including node1 and any untainted nodes, so placement is not forced. This is why dedicated-node patterns usually combine a taint with node affinity or a node selector to attract the intended workload. Without affinity, the Pod may land elsewhere.

Why this answer

Taints repel and tolerations merely permit; a tolerating Pod is eligible for the tainted node but is not drawn to it. The scheduler still scores every feasible node, so without node affinity or a node selector the Pod can land anywhere that passes filters, which is why dedicated-node designs pair taints with attracting constraints.

Exam trap

The trap here is treating a toleration as if it pinned the Pod to the tainted node, when it only lifts the repulsion.

Full explanation →

606

Multi-Selectmedium

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

Select 2 answers

A.Manual approval for all production deployments

B.Use of a single programming language across all services

C.Store logs in a local file system

D.Strict separation of config from code

E.Maximize robustness through fast startup and graceful shutdown

AnswersD, E

Config should be stored in environment variables.

Why this answer

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

Exam trap

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

Full explanation →

607

MCQhard

A pod has both resource requests and limits defined. The container is using more CPU than the request but less than the limit. What will happen?

A.The container will be evicted from the node

B.The container will be throttled

C.The container will continue to run normally

D.The container will be terminated

AnswerC

Requests guarantee scheduling capacity, while limits cap consumption. CPU usage between request and limit stays within the container's allowed allocation, so the container keeps running; only exceeding the limit triggers throttling, and memory over limit triggers OOMKill.

Why this answer

When a container's CPU usage exceeds its request but stays below its limit, Kubernetes treats the container as running within its allowed range. The request guarantees baseline resources, while the limit caps usage; as long as usage is below the limit, no throttling or eviction occurs. The container continues to run normally because CPU limits are enforced via CFS quotas only when usage reaches the limit, and requests are used for scheduling and QoS classification.

Exam trap

A common misconception is that exceeding a CPU request triggers throttling or eviction, when in fact throttling only occurs at the limit and eviction is tied to node pressure and QoS class.

How to eliminate wrong answers

Option A is wrong because eviction occurs only when a node is under resource pressure (e.g., memory or disk) and the pod violates its QoS guarantees, not simply for exceeding a CPU request. Option B is wrong because CPU throttling is applied only when the container's usage reaches or exceeds its CPU limit, not when it is between request and limit. Option D is wrong because termination happens only if the container exceeds its memory limit (OOMKill) or violates a liveness probe, not for CPU usage below the limit.

Full explanation →

608

MCQeasy

A development team wants to package and deploy a multi-tier application to Kubernetes. They need to template Kubernetes manifests with environment-specific values and manage releases with versioning and rollback capabilities. Which tool is purpose-built for this?

A.Argo CD

B.kubectl

C.Kustomize

D.Helm

AnswerD

Helm is the package manager for Kubernetes, designed to template manifests using values files and manage releases with versioning, rollback, and atomic upgrades. It allows teams to define a chart with templates and override values per environment, exactly matching the requirement for environment-specific values and release management. Other tools may assist with deployment but do not provide Helm's integrated packaging and release lifecycle.

Why this answer

Helm is specifically designed to package Kubernetes applications as charts, template manifests with values files for different environments, and manage releases with versioning and rollback. It provides a release history and atomic upgrades, making it ideal for the described scenario. Other tools like Kustomize or Argo CD serve different purposes and do not offer the same integrated packaging and release lifecycle.

Exam trap

The trap here is confusing templating tools with release management; Helm uniquely combines both.

Full explanation →

609

MCQmedium

A cluster administrator needs to run a one-time database migration job that must complete successfully before a new application version is deployed. The job should retry up to 4 times if it fails and should be automatically cleaned up 1 hour after completion. Which Kubernetes resource should be used?

A.A bare Pod with restartPolicy: Never and activeDeadlineSeconds: 3600

B.A CronJob with schedule: '@once' and successfulJobsHistoryLimit: 1

C.A Deployment with replicas: 1 and a restartPolicy of OnFailure

D.A Job with backoffLimit: 4 and ttlSecondsAfterFinished: 3600

AnswerD

A Job is designed for run-to-completion workloads. Setting backoffLimit: 4 allows up to 4 retries after the initial failure, and ttlSecondsAfterFinished: 3600 tells the Job controller to delete the Job and its pods 1 hour after it finishes. This exactly matches the requirement for a one-time migration with retry and cleanup.

Why this answer

The Job resource is purpose-built for one-off tasks that run to completion. The backoffLimit field controls how many times the Job controller retries a failed pod before marking the Job as failed. The ttlSecondsAfterFinished field enables automatic cleanup of the Job and its pods after a specified period.

Together they satisfy the migration scenario's retry and cleanup requirements without manual intervention.

Exam trap

The trap here is confusing Job with CronJob or assuming a Deployment can handle run-to-completion tasks, when only a Job provides the backoffLimit and TTL cleanup features needed for one-time workloads.

Full explanation →

610

MCQhard

A Kubernetes cluster has a pod that is stuck in the 'Pending' state. The operations team runs 'kubectl describe pod' and sees the event: '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause of this issue?

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

B.The nodes have CPU resources but are tainted, preventing scheduling.

C.The pod's CPU limit is set too low, causing the scheduler to reject it.

D.The pod's CPU request exceeds the allocatable CPU on any node.

AnswerD

The scheduler reports insufficient CPU on all nodes, meaning no node has enough allocatable CPU to satisfy the pod's CPU request. This occurs when 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 reduced.

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 happens when the sum of CPU requests from existing pods on each node plus the new pod's request exceeds the node's capacity. The pod remains Pending until resources are freed or the request is lowered.

Other factors like taints or node selectors would produce different event messages.

Exam trap

The trap here is confusing CPU limits with requests; only requests affect scheduling, and the error message explicitly points to insufficient CPU resources.

Full explanation →

611

MCQeasy

Which command would you use to view the logs of a container named 'nginx' in a Pod named 'web-pod'?

A.kubectl logs web-pod -c nginx

B.kubectl logs web-pod nginx

C.kubectl describe pod web-pod

D.kubectl exec web-pod -- cat /var/log/nginx/access.log

AnswerA

The -c flag selects a specific container within a multi-container Pod, so kubectl logs web-pod -c nginx retrieves nginx's logs. This satisfies the stem's constraint of targeting the container named nginx rather than every container in web-pod.

Why this answer

The `kubectl logs` command retrieves container logs from a Pod, and when a Pod contains multiple containers, the `-c` flag is required to specify which container's logs to view. Here, `kubectl logs web-pod -c nginx` explicitly targets the 'nginx' container within the 'web-pod' Pod, which is the standard Kubernetes API approach for fetching container stdout/stderr streams.

Exam trap

The trap here is that candidates often assume `kubectl logs` can accept the container name as a positional argument without the `-c` flag, confusing it with `kubectl exec` syntax where the container name can be specified with `-c` but is optional if there's only one container.

How to eliminate wrong answers

Option B is wrong because `kubectl logs web-pod nginx` omits the required `-c` flag; in kubectl syntax, the container name must be preceded by `-c` or `--container`, otherwise the command will fail or misinterpret the argument. Option C is wrong because `kubectl describe pod web-pod` shows the Pod's metadata, status, and events, but does not display the live container logs; it only provides a snapshot of the Pod's configuration and recent events, not the actual log output. Option D is wrong because `kubectl exec web-pod -- cat /var/log/nginx/access.log` attempts to read a file from the container's filesystem, but container logs in Kubernetes are typically written to stdout/stderr and captured by the container runtime, not stored in a file at that path unless explicitly configured; this approach is non-standard and may fail if the file does not exist or the container does not have a shell.

Full explanation →

612

MCQeasy

A developer wants to ensure that a pod runs only on nodes with SSDs. Which mechanism should be used?

A.Apply a taint to nodes without SSDs and add tolerations to the pod

B.Use pod anti-affinity

C.Add a nodeSelector with disktype: ssd

D.Define a ResourceQuota

AnswerC

A nodeSelector matches pod scheduling to node labels, so labelling SSD nodes with disktype: ssd and declaring that selector in the pod spec confines the workload to those nodes. This directly satisfies the stem's requirement that the pod run only on SSD-backed nodes, using Kubernetes' built-in label-based scheduling constraint.

Why this answer

`nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node selection, thinking they can be used to force pods onto specific hardware, when in fact taints repel pods and tolerations allow exceptions, whereas `nodeSelector` or `nodeAffinity` are the correct tools for positive selection.

How to eliminate wrong answers

Option A is wrong because taints and tolerations are used to repel pods from nodes (or allow them to tolerate repulsion), not to positively select nodes with specific hardware; they control which pods can run on a node but do not guarantee a pod will only run on nodes with SSDs. Option B is wrong because pod anti-affinity is used to prevent pods from co-locating on the same node or topology, not to select nodes based on hardware attributes like SSDs. Option D is wrong because a ResourceQuota limits resource consumption within a namespace and cannot influence node selection based on hardware characteristics.

Full explanation →

613

MCQeasy

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

A.To develop proprietary cloud software

B.To define cloud-native standards only

C.To certify cloud providers

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

614

MCQmedium

Which of the following is true about Prometheus's pull-based model for collecting metrics?

A.Targets push metrics to Prometheus

B.Prometheus only collects metrics from Kubernetes API server

C.Prometheus scrapes metrics from HTTP endpoints

D.Prometheus stores metrics in a relational database

AnswerC

Prometheus actively initiates scrapes against configured HTTP endpoints, retrieving metrics at fixed intervals. This pull architecture satisfies the stem's requirement by having the server discover and fetch data itself, rather than passively receiving pushed measurements. Targets expose a `/metrics` path that Prometheus polls, giving it control over collection timing and target health.

Why this answer

Prometheus uses a pull-based model where it periodically scrapes metrics from HTTP endpoints exposed by targets, typically at /metrics. This means targets do not push data; instead, Prometheus initiates the HTTP GET requests on a schedule defined by scrape_interval. This design simplifies target discovery and allows Prometheus to control scrape frequency and timeout.

Exam trap

KCNA often tests the misconception that Prometheus receives pushed metrics; candidates confuse the pull model with push-based systems like StatsD or Graphite.

How to eliminate wrong answers

Option A is wrong because targets do not push metrics to Prometheus in the standard pull model; push is only used via the Pushgateway for short-lived jobs. Option B is wrong because Prometheus can scrape any HTTP endpoint, not just the Kubernetes API server; it commonly scrapes node exporters, kubelets, and application pods. Option D is wrong because Prometheus stores metrics in its own time-series database (TSDB), not a relational database.

Full explanation →

615

MCQhard

A Prometheus alert rule fires when the error rate exceeds 5% for 5 minutes. The alert is sent to Alertmanager. What must be configured in Alertmanager to ensure the alert is deduplicated, grouped, and routed to the correct team?

A.An inhibition rule

B.A recording rule

C.A silence rule

D.A route configuration

AnswerD

Routes in Alertmanager match incoming alerts by label and direct them to the appropriate receiver, while grouping and deduplication happen within that routing tree. Configuring a route therefore satisfies the requirement to deduplicate, group and deliver the alert to the correct team.

Why this answer

A route configuration in Alertmanager defines how alerts are grouped, deduplicated, and routed to specific receivers (e.g., email, Slack, PagerDuty) based on label matchers. The route tree determines which team receives which alerts, and grouping parameters control deduplication and batching. Without a route, Alertmanager cannot direct alerts to the correct team.

Exam trap

KCNA often tests the confusion between Alertmanager routing and Prometheus recording rules; candidates may pick recording rule thinking it handles alert delivery.

How to eliminate wrong answers

Option A is wrong because an inhibition rule suppresses alerts when a related alert is already firing; it does not handle routing or deduplication. Option B is wrong because a recording rule is a Prometheus feature that precomputes frequently used queries, not an Alertmanager configuration. Option C is wrong because a silence rule mutes alerts for a specified time window; it does not route or deduplicate them.

Full explanation →

616

MCQhard

You run 'kubectl get pods' and see a pod in 'Pending' state for over 5 minutes. You describe the pod and see '0/1 nodes are available: 1 Insufficient memory'. What is the most likely cause?

A.The container image is too large

B.The pod's memory request is larger than any node's allocatable memory

C.The pod has a liveness probe that is failing

D.The kubelet on the node is not running

AnswerB

The scheduler's event shows insufficient memory on all nodes, meaning the pod's memory request exceeds every node's allocatable capacity. That unmet resource request is precisely why the scheduler cannot bind the pod, leaving it Pending.

Why this answer

The '0/1 nodes are available: 1 Insufficient memory' message indicates that the Kubernetes scheduler could not place the pod because no node has enough allocatable memory to satisfy the pod's memory request. Option B is correct because the pod's memory request exceeds the available memory on any node, causing the pod to remain in Pending state indefinitely until sufficient resources become available.

Exam trap

CNCF often tests the distinction between resource requests (used for scheduling) and resource limits (used for throttling/eviction), so candidates mistakenly think a large image or probe failure causes Pending state, but the scheduler only cares about resource requests and node availability.

How to eliminate wrong answers

Option A is wrong because a large container image affects image pull time and disk space, not the scheduler's memory allocation decision; the scheduler only considers resource requests and limits, not image size. Option C is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not remain in Pending state; liveness probes only run after the pod is scheduled and running. Option D is wrong because if the kubelet were not running, the node would show as NotReady or be absent from 'kubectl get nodes', and the scheduler would report a different error like '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate' or 'node(s) were unschedulable'.

Full explanation →

617

Multi-Selectmedium

Which THREE of the following are core components of a Kubernetes worker node?

Select 3 answers

A.etcd

B.kube-apiserver

C.container runtime

D.kube-proxy

E.kubelet

AnswersC, D, E

The container runtime runs on every worker node, pulling images and executing containers on behalf of the kubelet. This satisfies the worker node component requirement, distinguishing it from control plane components such as the API server that never execute workloads.

Why this answer

The three core components of a Kubernetes worker node are the container runtime (C), kube-proxy (D), and kubelet (E). The container runtime (C) is required because it is the software (e.g., containerd, CRI-O) that actually pulls images and runs containers on the node. kubelet (E) is the primary node agent that registers the node with the control plane and manages Pods and their containers via the CRI. kube-proxy (D) implements the Service networking rules on the node, maintaining iptables/IPVS rules so that Service VIPs and load balancing work for Pods. Options A (etcd) and B (kube-apiserver) are not worker node components; they are control plane components, with etcd being the cluster's key-value datastore and kube-apiserver being the API front end.

Exam trap

The trap here is that candidates often confuse control plane components (etcd, kube-apiserver) with worker node components, especially when they see them listed together in a question about cluster architecture.

Full explanation →

618

MCQmedium

A platform team runs a StatefulSet named `db` with three replicas in the `prod` namespace. An operator must connect directly to the third Pod's network identity for a manual data repair. Which stable DNS name resolves to that specific Pod?

A.db-2.db.prod.svc.cluster.local

B.db.db.prod.svc.cluster.local

C.db-3.db.prod.svc.cluster.local

D.db.prod.pod.cluster.local

AnswerA

StatefulSet Pods receive stable ordinal hostnames derived from the Pod name and the governing Service. With a headless Service named `db`, the third Pod (ordinal 2) is reachable at db-2.db.prod.svc.cluster.local. This identity persists across rescheduling, which is exactly why StatefulSets suit databases and other workloads needing stable per-Pod addressing.

Why this answer

StatefulSet members are addressed by stable, ordinal-based hostnames backed by a headless Service. A three-replica set produces ordinals 0 through 2, so the third Pod is db-2 under the Service and namespace. That per-Pod DNS record survives rescheduling, giving operators a dependable target for direct maintenance work.

Exam trap

The trap here is assuming StatefulSet ordinals start at 1, which leads to picking the -3 name instead of the correct zero-based -2 record.

Full explanation →

619

MCQhard

A platform team runs a 12-node Kubernetes cluster where each node hosts roughly 30 pods. They deployed Prometheus with a ServiceMonitor that scrapes every pod's /metrics endpoint every 15 seconds, but now the Prometheus pod is frequently OOMKilled and scrape targets intermittently report 'context deadline exceeded'. Which change best addresses the root cause while preserving observability?

A.Increase the Prometheus container's memory limit and CPU request so it can hold all active time series in memory.

B.Shorten the scrape interval to 5 seconds so each scrape collects fewer samples and finishes before the deadline.

C.Enable the Prometheus remote write receiver and forward all samples to a long-term storage backend such as Thanos or Cortex.

D.Reduce scrape scope using relabeling and metricRelabelings to drop unused targets and high-cardinality metrics, and split scraping across multiple Prometheus shards.

AnswerD

The cluster-wide scrape of every pod creates excessive active time series and concurrent target load, which drives memory usage and scrape deadline errors. Dropping unneeded targets and metrics through relabeling lowers cardinality, while sharding distributes scrape work across multiple Prometheus instances so no single server is overwhelmed, preserving observability for the metrics that matter.

Why this answer

The symptoms point to scrape and cardinality overload: too many targets and time series for a single Prometheus instance. Trimming what is scraped through relabeling and metricRelabelings reduces active series, and sharding spreads the remaining scrape load across multiple servers. Together these address both the memory exhaustion and the scrape deadline errors without abandoning observability of essential metrics.

Exam trap

The trap here is assuming that more memory, a shorter scrape interval, or remote write storage solves Prometheus overload, when the actual driver is uncontrolled cardinality and target count.

Full explanation →

620

MCQeasy

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerC

kube-apiserver exposes the REST API that kubectl, controllers and schedulers all call; it is the only component that reads and writes etcd. Every administrative task therefore passes through it, making it the cluster's single 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 validates and processes RESTful API calls (using JSON/YAML over HTTP/HTTPS) before persisting state to etcd or delegating work to other controllers. Without the API server, no kubectl command, automation script, or internal component can interact with the cluster.

Exam trap

CNCF often tests the misconception that etcd is the primary entry point because it stores all cluster data, but the trap is that etcd is never accessed directly by users or external tools — all interactions must go through the kube-apiserver, which acts as the single gateway for security and consistency.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager is a control loop that watches the shared state via the API server and makes changes to move the current state toward the desired state; it does not accept external API requests directly. Option B is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API endpoint; all reads and writes to etcd go through the kube-apiserver. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it receives its instructions from the API server, not from external administrative requests.

Full explanation →

621

MCQeasy

Which Kubernetes component is responsible for storing the cluster state?

A.kube-scheduler

B.kube-apiserver

C.etcd

D.kube-controller-manager

AnswerC

etcd is the distributed key-value store holding all cluster state — objects, configuration and metadata — making it the single source of truth the API server reads and writes, satisfying the requirement to persist cluster state.

Why this answer

etcd is a distributed, consistent key-value store used by Kubernetes to store all cluster data, including configuration, state, and metadata. It is the single source of truth for the cluster; without etcd, the cluster cannot maintain or recover its state. The kube-apiserver is the only component that communicates directly with etcd, but it is etcd itself that physically stores the data.

Exam trap

CNCF often tests the misconception that kube-apiserver stores the cluster state because it is the central API gateway, but the trap is that kube-apiserver only mediates access while etcd is the actual persistent storage layer.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option B is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes API requests, but it does not store data; it reads from and writes to etcd. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not persist state itself.

Full explanation →

622

MCQmedium

You have a microservices application deployed as a set of Pods in a Kubernetes cluster. You need to ensure that Pods can discover each other using stable DNS names. Which Kubernetes resource should you create?

A.ConfigMap

B.Ingress

C.Service

D.Deployment

AnswerC

A Service assigns a stable virtual IP and DNS name to a set of Pods, load-balancing across them. Pod IPs change as Pods restart, so the Service abstraction is what provides the stable discovery name required.

Why this answer

A Service of type ClusterIP (the default) provides a stable virtual IP and DNS name (e.g., my-service.namespace.svc.cluster.local) that resolves to the Pods selected by its label selector. This allows Pods to discover each other using consistent DNS names, regardless of Pod IP changes due to scaling or restarts. The kube-dns or CoreDNS addon automatically creates DNS records for Services, enabling service discovery within the cluster.

Exam trap

CNCF often tests the misconception that a Deployment itself provides stable DNS names, but Deployments only manage Pod replicas; the Service resource is required to expose a stable network endpoint and DNS record.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store configuration data as key-value pairs, not to provide network endpoints or DNS names for Pod discovery. Option B is wrong because an Ingress manages external HTTP/HTTPS traffic routing to Services, not internal Pod-to-Pod DNS-based discovery. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, updates), but does not create a stable network identity or DNS name for Pods to discover each other.

Full explanation →

623

MCQeasy

Which kubectl command is used to view detailed information about a Kubernetes resource?

A.kubectl describe

B.kubectl get

C.kubectl exec

D.kubectl logs

AnswerA

kubectl describe fetches a resource's aggregated state and surfaces detailed information, including events, conditions and configuration, for a named object. This directly satisfies the stem's requirement for viewing detailed resource information, unlike kubectl get, which returns only summary or tabular output.

Why this answer

The `kubectl describe` command retrieves detailed, multi-section information about a specific Kubernetes resource, including events, status conditions, and configuration details. Unlike `kubectl get`, which shows a summary, `kubectl describe` provides a deep dive into the resource's current state, making it the correct choice for viewing detailed information.

Exam trap

The trap here is that candidates often confuse `kubectl get` (which shows a summary) with `kubectl describe` (which shows detailed information), especially when they see the word 'get' and assume it retrieves all details.

How to eliminate wrong answers

Option B is wrong because `kubectl get` outputs a concise, tabular summary of resources (e.g., name, status, age) and does not show detailed fields like events or container logs. Option C is wrong because `kubectl exec` is used to execute commands inside a running container, not to view resource details. Option D is wrong because `kubectl logs` retrieves log output from a specific pod or container, not the configuration or status of a Kubernetes resource.

Full explanation →

624

MCQmedium

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

A.Config server

B.Event broker

C.API gateway

D.Service mesh

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

625

MCQmedium

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

A.Bulkhead

B.Timeout

C.Retry

D.Circuit breaker

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

626

MCQhard

You create a Service of type NodePort with nodePort: 30080. The cluster's nodes have IP addresses 10.0.0.1 and 10.0.0.2. From outside the cluster, which address and port can you use to access the Service?

A.10.0.0.1:30080

B.10.0.0.1:80

C.ClusterIP:80

D.10.0.0.2:8080

AnswerA

NodePort exposes the Service on every node's IP at the allocated static port, so 10.0.0.1:30080 reaches it from outside the cluster. The kube-proxy on each node listens on that port and forwards traffic to the backing Pods, satisfying the external-access constraint without requiring a load balancer or Ingress.

Why this answer

A NodePort service exposes the same port (nodePort: 30080) on every node in the cluster. From outside the cluster, you can reach the service using the IP address of any node (e.g., 10.0.0.1) combined with the nodePort (30080). The kube-proxy on that node will forward traffic to the service's ClusterIP and then to the selected pods.

Exam trap

The KCNA often tests the distinction between ClusterIP (internal-only) and NodePort (external access via nodeIP:nodePort), trapping candidates who confuse the service port (e.g., 80) with the nodePort (e.g., 30080) or think ClusterIP is externally routable.

How to eliminate wrong answers

Option B is wrong because port 80 is the default ClusterIP port, not the nodePort; NodePort services require the nodePort (30080) to be accessed externally. Option C is wrong because ClusterIP is only reachable from within the cluster, not from outside; external traffic must use a node's IP and the nodePort. Option D is wrong because 10.0.0.2:8080 uses an incorrect port (8080 instead of 30080) and implies a different service or port mapping; the nodePort must match the configured value (30080).

Full explanation →

627

MCQhard

A pod named 'web-app' is not able to resolve the hostname 'db-service' from another namespace 'data'. The 'db-service' Service exists in the 'data' namespace. What is the most likely cause?

A.The pod is trying to resolve 'db-service' without the namespace suffix

B.The Service 'db-service' is not exposed on a port

C.The pod's DNS policy is set to 'None'

D.The pod's container image lacks DNS utilities

AnswerA

DNS resolution in Kubernetes is namespace-scoped: a bare name like `db-service` resolves only within the pod's own namespace. Cross-namespace lookups require the fully qualified form `db-service.data.svc.cluster.local`, so the missing namespace suffix is the constraint the stem describes.

Why this answer

By default, Kubernetes DNS resolves service names only within the same namespace. To resolve a service from another namespace, the pod must use the fully qualified domain name (FQDN) in the format '<service>.<namespace>.svc.cluster.local'. Without the namespace suffix, the DNS query for 'db-service' fails because it is not found in the pod's own namespace.

Exam trap

The trap here is that candidates assume Kubernetes DNS automatically resolves service names across all namespaces, similar to how a flat network would work, but in reality, DNS resolution is namespace-scoped unless the FQDN is used.

How to eliminate wrong answers

Option B is wrong because a Service can exist without being exposed on a port, but DNS resolution of the service name is independent of port exposure; DNS returns the cluster IP regardless of port configuration. Option C is wrong because a DNS policy of 'None' would mean the pod uses no DNS configuration at all, which would prevent resolution of any hostname, not just cross-namespace ones, and the question states only 'db-service' fails. Option D is wrong because DNS resolution is handled by the cluster's DNS service (e.g., CoreDNS) and the node's resolver, not by utilities inside the container image; the pod's container image lacking DNS utilities would not affect the underlying DNS query mechanism.

Full explanation →

628

MCQeasy

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

A.Automated CI/CD pipelines

B.Manual configuration management

C.Tight coupling of services

D.Preferring stateful applications over stateless

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

629

MCQhard

You need to ensure that a pod runs on a specific node that has an SSD. The node has the label 'disktype=ssd'. How should you configure the pod to target this node?

A.Set spec.affinity.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution.

B.Set spec.nodeSelector with disktype: ssd.

C.Set spec.tolerations with key=disktype, value=ssd.

D.Set spec.nodeName to the node's name.

AnswerB

Setting `spec.nodeSelector` with `disktype: ssd` makes the scheduler filter candidate nodes by their existing labels, so the pod lands only on nodes carrying that exact key-value pair. This directly satisfies the stem's requirement to target the SSD-labelled node, since nodeSelector is the native, simplest label-based placement constraint in Kubernetes.

Why this answer

`spec.nodeSelector` is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label. By setting `disktype: ssd` in the nodeSelector, the scheduler will only consider nodes with that exact label key-value pair, ensuring the Pod lands on an SSD-equipped node.

Exam trap

The trap here is that candidates often confuse `nodeSelector` with `nodeAffinity` or `tolerations`, thinking that tolerations can select nodes, when in fact tolerations only allow scheduling on tainted nodes and do not enforce placement on a specific label.

How to eliminate wrong answers

Option A is wrong because `spec.affinity.nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` is a more complex and flexible way to achieve node selection, but it is not the simplest or most direct method; the question asks for how to configure the pod, and nodeSelector is the standard minimal approach. Option C is wrong because `spec.tolerations` is used to allow a Pod to be scheduled on nodes with taints, not to select nodes based on labels; tolerations do not direct the scheduler to prefer or require a specific node label. Option D is wrong because `spec.nodeName` bypasses the scheduler entirely and directly assigns the Pod to a specific node by name, which is inflexible and does not use the label-based selection requested in the question.

Full explanation →

630

Multi-Selectmedium

Which two components are part of the Kubernetes worker node? (Choose two.)

Select 2 answers

A.kube-proxy

B.kube-scheduler

C.etcd

D.kubelet

E.kube-apiserver

AnswersA, D

Kube-proxy runs on every worker node, implementing the Service abstraction by maintaining iptables or IPVS rules that route traffic to the correct pods. This satisfies the stem's requirement for a worker node component, since it handles node-local network programming rather than cluster-wide control-plane functions.

Why this answer

kube-proxy (A) is correct because it runs on every worker node and maintains the node's network rules (iptables/IPVS) that implement Kubernetes Service load balancing and ClusterIP/NodePort routing. kubelet (D) is correct because it is the primary node agent that registers the node with the API server, watches PodSpecs, and drives the container runtime (via CRI) to start, stop, and monitor containers and their volumes. The other components belong to the control plane: kube-scheduler (B) assigns Pods to nodes, etcd (C) is the cluster's distributed key-value datastore, and kube-apiserver (E) exposes the REST API and is the front end of the control plane, so none of them are worker node components.

Exam trap

The trap in this question is that candidates often confuse control plane components (like kube-scheduler, kube-apiserver, etcd) with worker node components. Remember that kubelet and kube-proxy run on each worker node, while the scheduler, API server, and etcd run on the control plane.

Full explanation →

631

Multi-Selectmedium

Which TWO of the following are characteristics of a microservices architecture? (Select 2)

Select 2 answers

A.Independent deployment of services

B.Tight coupling between services

C.Loose coupling between services

D.Monolithic codebase

E.Shared database for all services

AnswersA, C

Independent deployment lets each service be released, scaled and restarted on its own release cadence, so a change to one service does not force redeployment of the whole application. This satisfies the stem's requirement for a defining microservices characteristic, distinguishing it from monolithic architectures where the entire application ships as one unit.

Why this answer

Option A (Independent deployment of services) is correct because microservices are built as separately deployable units, so a change to one service can be built, tested, and released without redeploying the entire application. Option C (Loose coupling between services) is correct because microservices interact through well-defined interfaces (typically REST, gRPC, or messaging) and minimize dependencies on each other's internal implementation, allowing them to evolve independently. Option B (Tight coupling between services) is incorrect because tight coupling is characteristic of monolithic designs, where components are highly interdependent.

Option D (Monolithic codebase) is incorrect because microservices decompose functionality into multiple small, independently managed codebases rather than one unified codebase. Option E (Shared database for all services) is incorrect because microservices generally favor database-per-service to avoid coupling through shared schemas and to preserve service autonomy.

Exam trap

CNCF often tests the misconception that microservices require a shared database for consistency, but the correct pattern is database-per-service to maintain loose coupling and independent scalability.

Full explanation →

632

MCQmedium

A developer wants to deploy a stateful application that requires stable network identities and persistent storage. Which Kubernetes resource is best suited for this workload?

A.Deployment

B.DaemonSet

C.StatefulSet

D.Job

AnswerC

StatefulSets give each pod a stable ordinal hostname and its own PersistentVolumeClaim via volumeClaimTemplates, so identity and storage survive rescheduling. Deployments provide neither, as pods are interchangeable with random names and typically share or lose storage.

Why this answer

StatefulSet is the correct choice because it is designed specifically for stateful applications that require stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that are retained across Pod rescheduling). Unlike Deployments, StatefulSets guarantee ordered deployment, scaling, and termination, which is essential for databases or message queues.

Exam trap

CNCF often tests the misconception that Deployment can handle stateful workloads because it supports PersistentVolumeClaims, but the trap is that Deployment does not guarantee stable network identities or ordered Pod management, which are critical for stateful applications like databases.

How to eliminate wrong answers

Option A is wrong because Deployment is intended for stateless applications and creates Pods with random, ephemeral identities and no guaranteed storage persistence; it does not provide stable network identities. Option B is wrong because DaemonSet ensures that a copy of a Pod runs on each node (or a subset of nodes) for node-level services like logging or monitoring, not for stateful workloads requiring stable identities and persistent storage. Option D is wrong because Job is designed for batch or one-time tasks that run to completion, not for long-running stateful applications that need persistent storage and stable network identities.

Full explanation →

633

Multi-Selectmedium

Which TWO statements are true about Kubernetes Deployments?

Select 2 answers

A.Deployments support rolling updates and rollbacks.

B.Deployments are the recommended controller for stateful applications.

C.A Deployment creates a ReplicaSet to ensure the desired number of pod replicas are running.

D.Deployments can expose applications externally via a built-in load balancer.

E.Deployments are used to run a pod on every node in the cluster.

AnswersA, C

Deployments manage ReplicaSets to perform rolling updates, replacing pods gradually while maintaining availability, and retain revision history so `kubectl rollout undo` can revert to a prior ReplicaSet. This satisfies the stem's requirement for both update and rollback capability, unlike bare pods or standalone ReplicaSets.

Why this answer

Option A is correct because a Deployment's pod template is versioned, and the Deployment controller performs rolling updates by incrementally replacing old ReplicaSet pods with new ones, while `kubectl rollout undo` reverts to a previous revision. Option C is correct because a Deployment does not manage pods directly; it creates and manages a ReplicaSet, which in turn maintains the desired number of pod replicas and scales them as the Deployment's spec changes. Option B is not correct because StatefulSets, not Deployments, are the recommended controller for stateful applications requiring stable network identities and persistent per-pod storage.

Option D is not correct because Deployments provide no built-in external load balancer; external exposure requires a Service of type LoadBalancer, NodePort, or an Ingress. Option E is not correct because running a pod on every node is the job of a DaemonSet, not a Deployment.

Exam trap

CNCF often tests the misconception that Deployments are suitable for stateful workloads or that they inherently expose applications externally, when in fact StatefulSets and Services are the correct components for those responsibilities.

Full explanation →

634

Multi-Selecteasy

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

Select 2 answers

A.A separate database for storing desired state

B.A monitoring dashboard for visualizations

C.A CI/CD pipeline that manually applies changes

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

E.A Git repository storing declarative configurations

AnswersD, E

The operator continuously watches Git and applies changes.

Why this answer

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

Exam trap

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

Full explanation →

635

MCQhard

A team runs a stateful application in a Kubernetes cluster. They need each Pod to have a stable network identity and its own persistent storage that survives Pod rescheduling. Which controller should they use?

A.A ReplicaSet

B.A DaemonSet

C.A Deployment

D.A StatefulSet

AnswerD

StatefulSets provide stable, unique network identities and persistent storage for each Pod. Pods are created with ordinal names and a headless Service gives them stable DNS names. PersistentVolumeClaims are retained across rescheduling. This exactly matches the requirement for stable identity and per-Pod storage, making it the correct choice.

Why this answer

StatefulSets are designed for stateful applications requiring stable network identifiers and persistent storage. They provide ordinal Pod names, stable DNS via a headless Service, and PersistentVolumeClaims that are retained. Deployments, DaemonSets, and ReplicaSets manage stateless or node-level workloads and do not offer these guarantees.

Exam trap

The trap here is assuming a Deployment with a PersistentVolumeClaim can provide stable per-Pod storage, when it cannot guarantee identity or one-to-one storage.

Full explanation →

636

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

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

AnswersB, C

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

Why this answer

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

Exam trap

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

Full explanation →

637

MCQeasy

What is the primary purpose of a Kubernetes Service?

A.To provide a stable network endpoint for a set of pods

B.To implement network routing rules on each node

C.To manage rolling updates of applications

D.To store configuration data as key-value pairs

AnswerA

A Kubernetes Service supplies a stable virtual IP and DNS name that front a dynamic set of pod replicas, load-balancing traffic across them. This satisfies the stem's requirement for a consistent endpoint, since pods are ephemeral and their IP addresses change on restart or rescheduling, breaking direct client connections.

Why this answer

A Kubernetes Service provides a stable, virtual IP and DNS name that remains constant even as the underlying pods are created, destroyed, or scaled. It acts as a load balancer across a set of pods selected by labels, abstracting away the ephemeral nature of pod IPs. This enables reliable communication between components within the cluster without requiring clients to track individual pod addresses.

Exam trap

The trap here is that candidates confuse the Service's role of providing a stable network endpoint with the underlying implementation details of kube-proxy or the lifecycle management of Deployments, leading them to select options that describe other Kubernetes primitives.

How to eliminate wrong answers

Option B is wrong because implementing network routing rules on each node is the job of the kube-proxy component (which uses iptables, IPVS, or userspace mode), not the Service resource itself; the Service is an API object that defines the desired state, while kube-proxy enforces the actual routing. Option C is wrong because managing rolling updates of applications is the responsibility of a Deployment (or StatefulSet), which uses a ReplicaSet to orchestrate pod version transitions; a Service only exposes pods and does not manage their lifecycle or update strategy. Option D is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap (or Secret for sensitive data), not a Service; Services are purely about network abstraction and discovery.

Full explanation →

638

MCQeasy

What is the primary benefit of containers over virtual machines?

A.Containers provide stronger isolation than VMs

B.Containers use more disk space than VMs

C.Containers require a hypervisor to run

D.Containers are more portable and lightweight because they share the host OS kernel

AnswerD

Containers share the host OS kernel, so each container packages only the application and its dependencies rather than a full guest OS. This shared-kernel architecture makes them smaller and faster to start, and lets the same image run unchanged across environments, unlike hypervisor-based virtual machines.

Why this answer

Containers are more portable and lightweight than virtual machines because they share the host OS kernel, eliminating the need for a separate guest OS per instance. This shared kernel approach reduces resource overhead (CPU, memory, and disk) and enables faster startup times, as containers only package the application and its dependencies without duplicating the operating system.

Exam trap

The trap here is that candidates often confuse isolation strength with portability, assuming containers are more secure because they are lightweight, but for the CNCF KCNA exam, it's important to understand that VMs provide stronger isolation due to separate kernels and hypervisor-level boundaries, whereas containers are more portable and lightweight.

How to eliminate wrong answers

Option A is wrong because containers provide weaker isolation than VMs; VMs use a hypervisor to run separate guest OS kernels, offering stronger security boundaries, whereas containers rely on kernel namespaces and cgroups, which share the host kernel. Option B is wrong because containers use less disk space than VMs, as they do not include a full guest OS image and leverage layered filesystems (e.g., overlay2) to share common layers. Option C is wrong because containers do not require a hypervisor; they run directly on the host OS using container runtime engines like containerd or Docker, whereas VMs require a hypervisor (Type 1 or Type 2) to virtualize hardware.

Full explanation →

639

MCQmedium

A team runs a stateless web application in Kubernetes. They have a Deployment named 'web-app' with 5 replicas. They want to ensure that a Service named 'web-svc' distributes traffic evenly to all healthy pods. Which type of Service should they use?

A.ClusterIP

B.Headless Service

C.ExternalName Service

D.NodePort

AnswerA

ClusterIP provides a stable virtual IP that load-balances across all pods matching the Service's selector, so traffic spreads evenly across the five healthy replicas. It satisfies the internal distribution requirement without exposing the Service externally, which suits a stateless web application accessed by other cluster workloads.

Why this answer

A ClusterIP Service is the correct choice because it provides a stable virtual IP address and round-robin load balancing across healthy pods in the Deployment. By default, kube-proxy uses iptables or IPVS rules to distribute traffic evenly to all ready pod endpoints, ensuring stateless web application requests are balanced without requiring external exposure.

Exam trap

The trap here is that candidates may think NodePort or Headless Service are needed for load balancing, but the question specifically asks for internal traffic distribution to pods, and ClusterIP is the default and correct Service type for that purpose, while Headless Service actually removes load balancing entirely.

How to eliminate wrong answers

Option B (Headless Service) is wrong because it does not provide a single virtual IP or load balancing; instead, it returns the IP addresses of all healthy pods via DNS, requiring the client to implement its own load balancing logic. Option C (ExternalName Service) is wrong because it maps the Service to an external DNS name (e.g., an external domain) and does not route traffic to any Kubernetes pods at all. Option D (NodePort) is wrong because it exposes the Service on a static port on each node's IP, which is used for external access and does not change the internal load balancing behavior (it still uses ClusterIP under the hood), but the question asks for the type that distributes traffic evenly to pods, and ClusterIP is the fundamental type for that purpose.

Full explanation →

640

MCQeasy

Which Kubernetes component is the primary entry point for all administrative tasks and exposes the REST API?

A.kube-apiserver

B.kube-controller-manager

C.etcd

D.kube-scheduler

AnswerA

kube-apiserver exposes the Kubernetes REST API and is the sole component that reads and writes cluster state in etcd, making it the entry point for administrative tasks. Every kubectl command and internal controller request passes through it, satisfying the stem's requirement for the primary administrative gateway.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole component that exposes the Kubernetes REST API. All administrative tasks—whether performed via kubectl, the Kubernetes dashboard, or direct API calls—must go through the API server, which validates and processes requests before storing state in etcd. Without the API server, no other component (scheduler, controller-manager, etc.) can interact with the cluster state.

Exam trap

Inexperienced candidates often think that etcd is the primary entry point because it stores all cluster data, but the trap here is that etcd is a backend datastore with no REST API exposed to users—only the kube-apiserver serves as the administrative gateway.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller processes (e.g., Node Controller, Replication Controller) but does not expose the REST API; it watches the API server for desired state changes and makes adjustments via the API server. Option C (etcd) is wrong because it is a distributed key-value store that holds cluster state, but it is not an entry point for administrative tasks—it is accessed only internally by the API server, never directly by users or kubectl. Option D (kube-scheduler) is wrong because it is responsible for assigning pods to nodes based on resource requirements and policies, and it communicates with the API server to update scheduling decisions, not to serve as an administrative entry point.

Full explanation →

641

MCQmedium

A developer needs to run a one-off batch job that processes a dataset and then exits. The job must run to completion exactly once per execution and should be retried automatically if the container fails. Which Kubernetes workload resource is designed for this requirement?

A.A DaemonSet

B.A StatefulSet

C.A Job

D.A Deployment

AnswerC

A Job creates one or more Pods and ensures they run to successful completion, tracking completions and retrying failed Pods according to backoffLimit. It is purpose-built for finite, run-to-completion workloads like batch processing. This matches the requirement for a one-off task that exits when done and is retried on failure.

Why this answer

A Job is the workload controller for finite tasks: it creates Pods, waits for successful completion, and retries failures up to backoffLimit. Deployments, DaemonSets, and StatefulSets are all designed for continuous operation and will keep Pods running or recreate them, so none provide the run-once-then-finish behavior the developer needs.

Exam trap

The trap here is choosing a Deployment for batch work, when Deployments restart exited Pods and never complete.

Full explanation →

642

Multi-Selectmedium

Which TWO of the following are valid container runtimes that implement the CRI? (Choose two.)

Select 2 answers

A.Kata Containers

B.CRI-O

C.Docker

D.containerd

E.rkt

AnswersB, D

CRI-O is purpose-built to implement the Kubernetes Container Runtime Interface, exposing only the gRPC CRI API rather than a broader runtime surface. This satisfies the stem's requirement for a valid CRI-implementing runtime, letting kubelet manage containers without Docker or containerd shims.

Why this answer

CRI-O (option B) is a lightweight container runtime purpose-built by Red Hat specifically to implement the Kubernetes Container Runtime Interface (CRI), so it directly satisfies the requirement. containerd (option D) also natively implements the CRI plugin, which is why Kubernetes can use it as a container runtime without any additional shim. Kata Containers (option A) is a runtime that provides VM-isolated containers but is typically plugged in via a CRI implementation such as containerd's CRI plugin or CRI-O, not as a standalone CRI runtime itself. Docker (option C) predates the CRI and does not implement it natively; it required the deprecated dockershim adapter to work with Kubernetes. rkt (option E) was an alternative container runtime that never implemented the CRI and has since been discontinued.

Exam trap

CNCF often tests the misconception that Docker is a CRI-compliant runtime because it was historically the default container runtime in Kubernetes, but candidates must remember that Docker uses its own API and was only supported via the now-removed dockershim, making containerd and CRI-O the only correct CRI implementations among the options.

Full explanation →

643

MCQeasy

Which component is responsible for managing the lifecycle of containers on a Kubernetes node?

A.kube-scheduler

B.kube-controller-manager

C.kube-apiserver

D.kubelet

AnswerD

The kubelet is the node agent that registers the node with the control plane and manages each pod's lifecycle, ensuring containers described in PodSpecs are running and healthy. It satisfies the stem's requirement for the component managing container lifecycle on a node, unlike the scheduler or controller manager.

Why this answer

The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., Docker, containerd) to manage the container lifecycle—starting, stopping, and monitoring containers based on PodSpecs received from the API server.

Exam trap

CNCF often tests the distinction between control-plane components (scheduler, controller-manager, API server) and node-level agents (kubelet), so the trap here is assuming that container lifecycle management is a control-plane function rather than a node-level responsibility.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for managing container lifecycles on a node. Option B is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet, Deployment controllers) that regulate cluster state, but it does not directly interact with containers on individual nodes. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the Kubernetes API, but it does not manage container lifecycles on nodes; it only provides the interface for kubelet to retrieve Pod specifications.

Full explanation →

644

MCQhard

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

A.Event broker (message queue or event bus)

B.Shared database

C.Circuit breaker pattern

D.Synchronous REST API calls

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

645

Multi-Selectmedium

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

Select 2 answers

A.Flux

B.Jenkins

C.Helm

D.Terraform

E.ArgoCD

AnswersA, E

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

Why this answer

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

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

Exam trap

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

Full explanation →

646

MCQeasy

A developer wants to run a single instance of a Pod on every node in a Kubernetes cluster to collect node-level metrics. Which Kubernetes resource is most appropriate for this task?

A.DaemonSet

B.ReplicaSet

C.StatefulSet

D.Deployment

AnswerA

DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes via node selectors). It is the ideal resource for cluster-wide daemons such as log collectors, monitoring agents, or storage daemons. When nodes are added to the cluster, the DaemonSet automatically schedules a Pod on the new node, and when nodes are removed, the Pods are garbage collected.

Why this answer

DaemonSet is specifically designed to run a Pod on each node in the cluster, making it perfect for node-level agents like metric collectors. It automatically handles node additions and removals, ensuring that the daemon is always present where needed. Deployment, StatefulSet, and ReplicaSet do not provide this per-node guarantee.

Exam trap

The trap here is confusing DaemonSet with Deployment, but DaemonSet is the only resource that guarantees one Pod per node automatically.

Full explanation →

647

Multi-Selecthard

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

Select 2 answers

A.Eliminates need for application monitoring

B.Advanced traffic management capabilities

C.Simplified persistent storage management

D.Automatic mTLS encryption between services

E.Reduced network latency

AnswersB, D

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

Why this answer

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

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

Exam trap

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

Full explanation →

648

Multi-Selectmedium

Which THREE of the following are characteristics of a microservices architecture? (Select 3)

Select 3 answers

A.Services share the same database schema

B.Loose coupling between services

C.Independent deployment of services

D.All services are packaged in a single monolithic deployment

E.Decomposition of application into small, independent services

AnswersB, C, E

Services communicate via APIs, reducing dependencies.

Why this answer

Microservices architecture emphasizes loose coupling, where each service communicates via well-defined APIs (e.g., REST, gRPC) and does not share internal implementation details. This allows services to evolve independently without affecting others, which is a core principle of the architecture.

Exam trap

CNCF often tests the misconception that microservices share a database or are deployed as a single unit, confusing them with monolithic or service-oriented architectures (SOA) that may share schemas.

Full explanation →

649

Drag & Dropmedium

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

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Full explanation →

650

MCQhard

You have a Deployment defined with replicas: 5. You run 'kubectl scale deployment myapp --replicas=3'. Which component is responsible for ensuring the actual number of Pods matches the desired 3?

A.etcd

B.Deployment controller in kube-controller-manager

C.kubelet

D.kube-scheduler

AnswerB

The Deployment controller, running inside kube-controller-manager, watches the Deployment's desired replica count and reconciles it by creating or deleting ReplicaSets and Pods. After the scale command sets replicas to 3, this controller drives actual Pods to match that declared state.

Why this answer

The Deployment controller, which runs as part of the kube-controller-manager, is responsible for reconciling the desired state of a Deployment. When you run 'kubectl scale deployment myapp --replicas=3', the Deployment controller detects the change in the Deployment's replica count and creates or deletes Pods via the ReplicaSet controller to match the desired 3 replicas.

Exam trap

CNCF often tests the misconception that kubelet or kube-scheduler handles scaling, when in fact kubelet only manages local Pod lifecycle and the scheduler only places Pods on nodes, while the Deployment controller in the kube-controller-manager is the component that reconciles replica counts.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds cluster state, but it does not perform reconciliation or enforce desired replica counts; it only stores the data that controllers read and write. Option C is wrong because kubelet is an agent that runs on each node and manages Pods on that node, but it does not scale Deployments or manage replica counts across the cluster. Option D is wrong because kube-scheduler is responsible for assigning Pods to nodes based on resource availability and constraints, not for ensuring the number of Pods matches a desired replica count.

Full explanation →

651

Multi-Selecthard

A platform team must ensure that a critical StatefulSet named ledger in the finance namespace always has at least two Pods available during voluntary disruptions such as node drains, and that Pods are spread across different nodes. Which two resources or settings should they configure? (Choose two.)

Select 2 answers

A.A ResourceQuota in the finance namespace limiting CPU and memory requests.

B.A PodDisruptionBudget in the finance namespace with minAvailable: 2 and a selector matching the ledger Pods.

C.A NetworkPolicy in the finance namespace that allows ingress only from the ledger Pods.

D.A topologySpreadConstraint on the StatefulSet Pod template with topologyKey kubernetes.io/hostname and whenUnsatisfiable: DoNotSchedule.

E.A PriorityClass assigned to the ledger Pods with a high value.

AnswersB, D

A PodDisruptionBudget constrains voluntary disruptions by requiring that at least the specified number of Pods remain available. With minAvailable: 2 and a selector for the ledger Pods, node drains and other voluntary evictions will be blocked or delayed until two Pods are healthy. This directly satisfies the availability requirement during voluntary disruptions.

Why this answer

A PodDisruptionBudget with minAvailable: 2 protects the StatefulSet during voluntary disruptions by blocking evictions that would drop below two available Pods. A topologySpreadConstraint keyed on kubernetes.io/hostname with DoNotSchedule enforces placement on separate nodes, which supports both resilience and the availability target. NetworkPolicy, ResourceQuota, and PriorityClass address traffic control, resource limits, and scheduling priority rather than the required availability and spread guarantees.

Exam trap

The trap here is treating PriorityClass or ResourceQuota as availability guarantees, when only a PodDisruptionBudget constrains voluntary evictions and a topologySpreadConstraint enforces node spreading.

Full explanation →

652

MCQmedium

A team manages a multi-service application with Helm. Each service has its own ConfigMap, Deployment, and Service. The manifests for all services are almost identical except for the image tag and service name. They want to create a single reusable Helm chart that deploys all services from one values file, avoiding duplicate YAML. Which Helm feature should they use to loop over a list of services in the chart templates?

A.Use Helm's `--set` flag during installation to override the service name and image tag for each service.

B.Create a separate subchart for each service and include them with the `dependencies` field in Chart.yaml.

C.Define each service as a separate named template in `_helpers.tpl` and call them from a single deployment manifest.

D.Use the `range` action in the template to iterate over a list defined in values.yaml, rendering one set of resources per service.

AnswerD

The `range` action in Helm templates iterates over a collection, such as a list of service definitions in values.yaml, and renders the enclosed template block for each item. This eliminates duplicate YAML by generating ConfigMap, Deployment, and Service resources dynamically. The values file supplies per-service data like name and image tag, and the chart templates reference those values with `.` inside the loop, producing one set of manifests per service entry.

Why this answer

The `range` action in Helm templates allows iteration over a list from values.yaml, rendering a block of resources for each item. This is the standard way to avoid duplicating YAML for near-identical services. By defining a list of services in values.yaml and using `range` in the templates, the chart generates all ConfigMaps, Deployments, and Services dynamically.

This keeps the chart DRY and maintainable as services are added.

Exam trap

The trap here is confusing Helm's templating loop with chart dependencies or named templates, which are for different reuse patterns and do not generate multiple resources from a single list.

Full explanation →

653

MCQhard

You have a YAML manifest for a Deployment with 'apiVersion: extensions/v1beta1'. When you run 'kubectl apply -f manifest.yaml', you get an error. What is the most likely cause?

A.The apiVersion is deprecated and not supported

B.The namespace does not exist

C.The YAML syntax is invalid

D.The 'kind' field is misspelled

AnswerA

The `extensions/v1beta1` API group was removed in Kubernetes 1.16, so the API server no longer serves Deployment objects under that version, causing `kubectl apply` to fail. Migrating the manifest to `apps/v1` satisfies the requirement that the resource's apiVersion must exist in the cluster's enabled API groups.

Why this answer

`extensions/v1beta1` was deprecated starting in Kubernetes 1.16 and removed entirely in Kubernetes 1.22. Running `kubectl apply` against a manifest with this apiVersion will result in an error because the API group and version are no longer recognized by the API server. The correct apiVersion for Deployments is `apps/v1`, which is the stable and currently supported version.

Exam trap

The Kubernetes certification exams often test the misconception that any API version ending in 'beta' is still supported, but the trap here is that `extensions/v1beta1` was removed entirely, not just deprecated, so candidates who think 'beta means it still works' will incorrectly choose a syntax or namespace error.

How to eliminate wrong answers

Option B is wrong because a missing namespace would produce a specific error message like 'namespace not found', not a generic API version error, and the namespace can be created or specified with `--namespace`. Option C is wrong because invalid YAML syntax would cause a parse error before the API server is even contacted, typically with a message like 'error converting YAML to JSON: yaml: line X: did not find expected key'. Option D is wrong because a misspelled `kind` field would result in an error like 'unable to recognize "manifest.yaml": no matches for kind "Deployment" in version "extensions/v1beta1"', but the error in this scenario is specifically about the apiVersion, not the kind.

Full explanation →

654

MCQeasy

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

A.Configuration management script

B.Virtual machine snapshot

C.Source code repository

D.Container image

AnswerD

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

Why this answer

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

Exam trap

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

Full explanation →

655

Multi-Selecthard

Which TWO of the following are true about Pod resource limits? (Select TWO)

Select 2 answers

A.A container can use more memory than its limit if the node has free memory

B.CPU limits are enforced using CFS quotas

C.Memory limits are soft and can be exceeded temporarily

D.Limits must be greater than or equal to requests

E.Setting CPU limits guarantees that a container will always get that much CPU

AnswersB, D

CPU limits are enforced through CFS quota periods: the kernel throttles a container once it exhausts its allotted CPU time within each 100ms period. This differs from memory limits, which trigger OOM kills rather than throttling, making the statement accurate.

Why this answer

Option B is correct because Kubernetes enforces CPU limits via the Linux Completely Fair Scheduler (CFS) quota mechanism, specifically the cpu.cfs_quota_us and cpu.cfs_period_us cgroup settings, which throttle a container's CPU usage once it hits its limit. Option D is correct because Kubernetes validates that a container's limit must be greater than or equal to its request for each resource; otherwise the Pod is rejected, since a limit below the request would be logically inconsistent. Option A is wrong because memory limits are hard limits — the kernel OOM killer terminates the container if it exceeds its memory limit, regardless of free node memory.

Option C is wrong because memory limits are not soft; only requests act as soft guarantees, while limits are hard caps enforced by the kernel. Option E is wrong because CPU limits cap maximum usage but do not guarantee CPU allocation; only CPU requests influence scheduling and provide a minimum share under contention.

Exam trap

In Kubernetes, the trap here is that candidates often confuse memory limits (hard, enforced by OOM kill) with CPU limits (hard, enforced by throttling), or mistakenly think limits are soft guarantees of allocation rather than caps on consumption.

Full explanation →

656

MCQmedium

A team wants to deploy a batch job that runs once to process a large dataset. The job should run to completion and then terminate. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

A Job creates pods that run until successful completion, then stops — exactly matching the run-once-then-terminate constraint. A Deployment would restart pods indefinitely to maintain a desired replica count, which is wrong for batch processing.

Why this answer

A Job resource is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish their work, making it the correct choice for a one-time data processing job.

Exam trap

CNCF often tests the distinction between long-running workloads (Deployments, DaemonSets) and finite tasks (Jobs), so the trap here is confusing a one-time batch job with a CronJob due to the word 'batch' or assuming a Deployment can handle termination.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures a Pod runs on every node (or a subset) for continuous daemon-like services, not for a one-time batch job. Option B is wrong because a CronJob is used for scheduled, recurring tasks, not a single run. Option C is wrong because a Deployment manages long-running, stateless applications with desired replicas and rolling updates, not a terminating batch job.

Full explanation →

657

MCQeasy

What is the primary purpose of continuous integration (CI) in a cloud-native application delivery pipeline?

A.To automatically build and test code changes upon commit

B.To manage infrastructure provisioning

C.To manage container images and registries

D.To automatically deploy code changes to production

AnswerA

Automatically building and testing each commit delivers the rapid, early feedback that CI exists to provide, catching integration defects before they reach later stages. This directly satisfies the stem's focus on the primary purpose of continuous integration within a cloud-native delivery pipeline, distinguishing it from continuous delivery or deployment concerns.

Why this answer

CI automates building and testing code changes upon commit to catch integration issues early. Option A correctly describes this. Option B refers to infrastructure provisioning, which is typically managed by Infrastructure as Code (IaC) tools.

Option C refers to managing container images and registries, which is part of container management. Option D describes continuous deployment (CD), which automatically deploys code to production after passing CI.

Full explanation →

658

Multi-Selectmedium

Which TWO of the following are benefits of using Helm for managing Kubernetes applications?

Select 2 answers

A.Automatic scaling of pods based on CPU usage

B.Native integration with service mesh for traffic splitting

C.Templating engine for parameterizing Kubernetes manifests

D.Ability to perform rollbacks to previous releases

E.Built-in support for canary deployments

AnswersC, D

Helm's templating engine parameterises Kubernetes manifests, letting one chart render environment-specific YAML from values files rather than duplicating manifests per cluster. This directly satisfies the scenario's need to manage applications across differing environments, since Go templates inject variables at install time and reduce configuration drift between deployments.

Why this answer

Helm's templating engine (option C) lets you parameterize Kubernetes manifests with values files and Go templates, so the same chart can render environment-specific YAML instead of maintaining duplicated static manifests. Helm also tracks each install/upgrade as a numbered revision, so `helm rollback <release> <revision>` can restore a previous release (option D), which is a core release-management benefit. The other options describe capabilities Helm does not provide natively: automatic CPU-based pod scaling is the Horizontal Pod Autoscaler (option A), service-mesh traffic splitting is handled by tools like Istio or Linkerd (option B), and canary deployments require additional controllers or progressive-delivery tools such as Argo Rollouts or Flagger (option E).

Exam trap

KCNA often tests the misconception that Helm includes deployment strategies like canary or autoscaling, when in fact Helm is strictly a packaging and templating tool.

Full explanation →

659

MCQmedium

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

A.Kubernetes

B.Terraform

C.Docker

D.Prometheus

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Full explanation →

660

MCQmedium

What is the concept of 'immutable infrastructure' as applied to Kubernetes?

A.Configuration is stored in environment variables only

B.Containers are rebuilt from the same base image every time

C.Infrastructure components are never replaced; they are updated in place

D.Pods are replaced with new versions rather than being modified

AnswerD

Immutable infrastructure means running instances are never patched or reconfigured in place; instead, Pods are destroyed and recreated from an updated image or manifest. This satisfies the scenario's requirement by eliminating configuration drift, since every replacement Pod starts from an identical, version-controlled definition rather than accumulating manual changes.

Why this answer

Immutable infrastructure in Kubernetes means that instead of modifying running Pods or their containers (e.g., patching a binary or updating a config file in place), you replace the entire Pod with a new version. This is enforced by Kubernetes' declarative model: when you update a Deployment's Pod template, the controller creates new Pods with the new image and terminates the old ones. This ensures consistency, repeatability, and eliminates configuration drift, as every change results in a fresh, identical instance from the same image.

Exam trap

CNCF often tests the distinction between 'immutable' (replace) and 'mutable' (update in place), and the trap here is that candidates confuse the concept with build-time practices (like using the same base image) or configuration injection methods, rather than the core runtime behavior of replacing Pods.

How to eliminate wrong answers

Option A is wrong because storing configuration only in environment variables is a specific pattern (e.g., 12-factor app), but it does not define immutability; immutable infrastructure requires replacing the entire unit, not just how config is injected. Option B is wrong because rebuilding containers from the same base image every time describes a build practice (e.g., using Dockerfile layers), but immutability is about the runtime behavior of replacing Pods, not the image build process. Option C is wrong because it describes mutable infrastructure (e.g., SSHing into a server to apply updates), which is the exact opposite of immutability; immutable infrastructure mandates that components are never updated in place—they are destroyed and recreated.

Full explanation →

661

Multi-Selecthard

Which THREE of the following are true about the Open Container Initiative (OCI)? (Choose 3)

Select 3 answers

A.Docker is an OCI runtime specification

B.OCI is governed by the Cloud Native Computing Foundation (CNCF)

C.OCI defines both an image spec and a runtime spec

D.containerd is an OCI-compliant container runtime

E.Docker images are OCI-compliant

AnswersC, D, E

The OCI publishes two separate specifications: the Image Specification, covering image layout and manifests, and the Runtime Specification, covering container execution. This satisfies the requirement for a true statement, and is the axis distinguishing OCI from earlier vendor-specific formats.

Why this answer

Option C is correct because the Open Container Initiative publishes two core specifications: the OCI Image Format Specification (defining image manifests, configs, and layers) and the OCI Runtime Specification (defining how to run an unpacked filesystem bundle, e.g., via runc). Option D is correct because containerd is a widely used OCI-compliant container runtime that implements the OCI runtime spec through runc and can pull/run OCI images. Option E is correct because Docker images follow the OCI Image Format Specification (Docker helped create the OCI and its image format is compatible with OCI images).

Option A is incorrect because Docker is a container platform/engine, not an OCI runtime specification; the OCI runtime spec is implemented by runtimes like runc. Option B is incorrect because the OCI is an independent Linux Foundation project, not governed by the CNCF (though CNCF projects like containerd are OCI-compliant).

Exam trap

KCNA often tests the misconception that Docker owns or defines the OCI standards, when in reality OCI is a separate Linux Foundation project and Docker is merely one implementation that consumes those specs.

Full explanation →

662

MCQmedium

A company wants to run a batch job that processes data and then terminates. Which Kubernetes resource should they use?

A.CronJob

B.Job

C.Deployment

D.DaemonSet

AnswerB

A Job runs pods to completion and stops retrying once the specified successful completions are reached, which suits a finite batch workload that must terminate. Unlike a Deployment, which maintains a continuous desired replica count, a Job is designed for run-to-completion tasks.

Why this answer

A Job is the correct Kubernetes resource for a batch job that processes data and then terminates. Unlike controllers that maintain a desired state (like Deployments), a Job creates one or more Pods and ensures they run to successful completion. Once the specified number of Pods terminate successfully, the Job is considered complete and does not restart the Pods, making it ideal for one-off or finite processing tasks.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, DaemonSet) versus controllers that run to completion (Job, CronJob), and the trap here is that candidates may confuse a CronJob with a Job, forgetting that CronJob adds a scheduling layer for periodic execution, not for a single run.

How to eliminate wrong answers

Option A is wrong because a CronJob is designed for scheduling recurring tasks on a time-based schedule (e.g., every hour), not for a single batch job that runs once and terminates. Option C is wrong because a Deployment is meant to run a set of Pods continuously, ensuring a specified number of replicas are always running; it will restart Pods if they exit, which is the opposite of a terminating batch job. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) node in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-off batch processing.

Full explanation →

663

MCQhard

When using Kustomize, how do you apply a common label to all resources in the base?

A.By editing each YAML file individually

B.By setting 'commonLabels' in the kustomization.yaml

C.By using the 'patches' field to add labels

D.By using a Helm chart instead of Kustomize

AnswerB

Setting `commonLabels` in `kustomization.yaml` makes Kustomize inject the specified labels into every resource's metadata during the build, satisfying the requirement to label all base resources uniformly. Kustomize applies this transformation automatically across the entire base, so no per-resource edits are needed.

Why this answer

Kustomize's `commonLabels` field in kustomization.yaml applies the specified labels to every resource rendered from the base, including selectors on Deployments and Services, without editing individual manifests. This is the idiomatic way to enforce consistent labeling across a set of resources.

Exam trap

The trap here is confusing Kustomize's `patches` field with label application; candidates often assume any modification requires a patch, when `commonLabels` is the dedicated mechanism.

How to eliminate wrong answers

Option A is wrong because manually editing each YAML file defeats Kustomize's purpose and is error-prone; Kustomize exists precisely to avoid this. Option C is wrong because the `patches` field is used for strategic merge or JSON 6902 patches to modify specific fields, not for uniformly applying labels to all resources. Option D is wrong because switching to Helm is a different tooling choice and does not answer how to apply labels in Kustomize.

Full explanation →

664

MCQmedium

A developer is investigating a performance issue in a microservices application. They want to trace a single request as it flows through multiple services, including a database call. Which OpenTelemetry concept allows them to correlate all these operations under a single logical unit?

A.Trace

B.Span

C.Metric

D.Log record

AnswerA

A trace represents the entire journey of a request through a distributed system, composed of multiple spans that share a common trace ID. It allows developers to see the full path and timing of a request across services. This is exactly what is needed to correlate operations from different services and a database call under a single logical unit.

Why this answer

In OpenTelemetry, a trace is the overarching structure that ties together all spans associated with a single request. Each span represents a unit of work, and spans within the same trace share a trace ID, enabling correlation across service boundaries. This allows developers to visualize the entire request flow, including database calls, and identify bottlenecks or failures.

Metrics and logs serve different purposes and do not provide this end-to-end request context.

Exam trap

The trap here is confusing a span with a trace; a span is a single operation, while a trace is the complete end-to-end journey of a request.

Full explanation →

665

MCQeasy

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

A.Immutable infrastructure

B.Manual configuration of each service instance

C.Using a monolithic deployment for all services

D.Loose coupling and isolation between services

AnswerD

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

Why this answer

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

Exam trap

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

Full explanation →

666

MCQmedium

You need to expose a set of pods running a web application to internal cluster traffic on a stable IP address. Which resource should you create?

A.Service of type NodePort

B.Ingress

C.NetworkPolicy

D.Service of type ClusterIP

AnswerD

ClusterIP assigns the Service a stable virtual IP reachable only from inside the cluster, and kube-proxy load-balances connections across the selected pods. This satisfies the requirement to expose the web application to internal cluster traffic on a stable address.

Why this answer

A Service of type ClusterIP exposes the set of pods on a stable, internal IP address that is only reachable within the cluster. This is the default Service type and is specifically designed for internal cluster traffic, providing a stable virtual IP (VIP) that load-balances requests to the underlying pods.

Exam trap

CNCF often tests the distinction between internal and external exposure, and the trap here is that candidates may confuse a Service of type ClusterIP with NodePort, thinking NodePort is needed for any stable IP, when ClusterIP is the correct choice for internal-only traffic.

How to eliminate wrong answers

Option A is wrong because a Service of type NodePort exposes the service on a static port on each node's IP address, making it accessible from outside the cluster, not just internally. Option B is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to services, typically requiring a Service of type NodePort or LoadBalancer to route traffic, and does not itself provide a stable internal IP. Option C is wrong because a NetworkPolicy is a security resource that controls ingress and egress traffic to/from pods based on labels and ports, but it does not expose pods or provide a stable IP address.

Full explanation →

667

MCQmedium

A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

A.The container is exceeding its memory limit and being OOM-killed.

B.The liveness probe is failing and restarting the container.

C.The init container is failing and blocking the main container.

D.The pod is hitting a resource quota limit at the namespace level.

AnswerA

Exit code 137 equals 128 plus signal 9 (SIGKILL), which the kernel sends when a container exceeds its memory limit. The kubelet then reports the OOMKilled reason. Persistent restarts with this code therefore indicate the pod's memory limit is too low for its workload, not an application crash.

Why this answer

Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.

Exam trap

The KCNA exam often tests the distinction between exit codes and probe failures; the trap here is that candidates confuse exit code 137 with a liveness probe failure, but exit code 137 specifically points to a SIGKILL, not a probe timeout or command failure.

How to eliminate wrong answers

Option B is wrong because a failing liveness probe causes a container restart with exit code 137 only if the probe failure leads to a SIGKILL (which is not typical; liveness probe failures result in exit code 0 or 1 depending on the probe command, not 137). Option C is wrong because init container failures block the main container from starting, but they do not cause the main container to exit with code 137; the main container would never run. Option D is wrong because a namespace-level resource quota limit prevents pod creation or scheduling, not causing a running container to exit with code 137; quota enforcement happens at admission time, not during runtime.

Full explanation →

668

MCQeasy

What is the purpose of the 'kubectl scale' command?

A.To update the container image of a Deployment

B.To delete a resource

C.To view the logs of a pod

D.To change the number of replicas in a Deployment

AnswerD

kubectl scale adjusts the replica count declared in a Deployment, StatefulSet or ReplicaSet, letting operators increase or decrease running Pod instances to match load. Changing replicas in a Deployment is precisely the mechanism the command provides for horizontal capacity adjustment.

Why this answer

The 'kubectl scale' command is used to change the number of replicas in a Deployment, StatefulSet, ReplicaSet, or ReplicationController. This allows you to horizontally scale the application by increasing or decreasing the desired replica count, which the controller then reconciles by creating or terminating pods.

Exam trap

Candidates often confuse 'kubectl scale' (changing replica count) with 'kubectl set image' or 'kubectl rollout' (updating pod template).

How to eliminate wrong answers

Option A is wrong because updating the container image of a Deployment is done with 'kubectl set image' or 'kubectl edit', not 'kubectl scale'. Option B is wrong because deleting a resource is performed with 'kubectl delete', not 'kubectl scale'. Option C is wrong because viewing the logs of a pod is done with 'kubectl logs', not 'kubectl scale'.

Full explanation →

669

MCQeasy

Which component of the Kubernetes control plane is responsible for storing the cluster state?

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-controller-manager

AnswerB

etcd is the consistent, distributed key-value store that persists all cluster state, including object definitions and configuration. Every control plane component reads and writes through it, making it the single source of truth for the cluster's desired and observed state.

Why this answer

etcd is the distributed key-value store that serves as Kubernetes' primary data store, persisting all cluster state including configuration, secrets, and resource specifications. The kube-apiserver is the only component that interacts directly with etcd, ensuring consistency and providing a RESTful interface for all other components and users.

Exam trap

A common trap is to think that kube-apiserver stores the cluster state because it acts as the central API gateway. However, the API server is stateless and delegates all persistence to etcd.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes API requests, but it does not store state—it reads from and writes to etcd. Option C is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option D is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that watch the shared state via the API server and make changes to bring the current state to the desired state, but it does not persist state itself.

Full explanation →

670

Multi-Selecthard

A Kubernetes administrator is troubleshooting a Pod that is stuck in the Pending state. The Pod has a resource request of cpu: 2 and memory: 4Gi. Which two commands are most appropriate to identify why the Pod cannot be scheduled? (Choose two.)

Select 2 answers

A.kubectl logs <pod-name> --previous

B.kubectl rollout restart deployment <deployment-name>

C.kubectl exec -it <pod-name> -- /bin/sh

D.kubectl describe pod <pod-name>

E.kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu,MEM:.status.allocatable.memory

AnswersD, E

The describe output includes the Events section at the bottom, which shows scheduler messages such as '0/5 nodes are available: 5 Insufficient cpu' or taint/toleration failures. This is the fastest way to see the scheduler's reasoning for a Pending Pod. It directly addresses the scenario by revealing why the Pod cannot be placed.

Why this answer

The describe command surfaces scheduler events that explain why the Pod is Pending, and querying node allocatable resources shows whether any node has enough CPU and memory. Together they confirm resource shortfalls or constraint mismatches. Logs and exec require a running container, and a rollout restart does not diagnose scheduling failures.

Exam trap

The trap here is reaching for kubectl logs or kubectl exec on a Pending Pod, even though those commands require a running container.

Full explanation →

671

MCQeasy

A platform team is deploying a logging stack in Kubernetes. They want to collect logs from all pods and nodes, store them centrally, and provide a query interface. Which combination of tools is commonly used to achieve this?

A.Prometheus for collection, Grafana for storage, Loki for visualization

B.OpenTelemetry Collector for collection, Jaeger for storage, Kibana for visualization

C.Jaeger for collection, Prometheus for storage, Grafana for visualization

D.Fluent Bit for collection, Elasticsearch for storage, Kibana for visualization

AnswerD

Fluent Bit is a lightweight log processor and forwarder commonly used as a DaemonSet in Kubernetes to collect logs from nodes and pods. Elasticsearch provides scalable storage and search capabilities, while Kibana offers visualization and querying. This combination, often called the EFK stack, is a standard solution for centralized logging in cloud native environments, directly addressing the requirements.

Why this answer

The EFK stack—Elasticsearch, Fluent Bit (or Fluentd), and Kibana—is a widely adopted solution for Kubernetes logging. Fluent Bit runs as a DaemonSet to collect logs from each node, Elasticsearch indexes and stores them, and Kibana provides a UI for searching and visualizing. This architecture meets the needs of collecting, storing, and querying logs centrally, making it the correct choice among the options.

Exam trap

The trap here is mixing components from different observability pillars; for example, using Prometheus (metrics) for logs or Jaeger (tracing) for storage.

Full explanation →

672

MCQmedium

Which DORA metric measures how quickly code changes are deployed to production?

A.Lead time for changes

B.Mean time to recovery (MTTR)

C.Change failure rate

D.Deployment frequency

AnswerA

Lead time for changes measures the elapsed time from code committed to code successfully running in production, directly quantifying deployment speed. Deployment frequency counts how often releases occur, while MTTR and change failure rate address stability rather than velocity.

Why this answer

Lead time for changes measures the time from code commit to code successfully running in production, directly reflecting deployment speed. It is one of the four DORA metrics and specifically captures how quickly changes flow through the pipeline.

Exam trap

The trap is conflating deployment frequency (how often) with lead time for changes (how fast), causing candidates to pick the wrong DORA metric.

How to eliminate wrong answers

Option B is wrong because MTTR measures how long it takes to restore service after an incident, not deployment speed. Option C is wrong because change failure rate measures the percentage of deployments causing failures, not speed. Option D is wrong because deployment frequency measures how often deployments occur, not how quickly a single change moves from commit to production.

Full explanation →

673

MCQmedium

A Pod is stuck in Pending state. Which of the following is the MOST likely cause?

A.The Pod's container is crashing

B.The container image has a typo

C.No node has enough resources to run the Pod

D.The Pod's liveness probe is failing

AnswerC

Pending means the scheduler cannot bind the Pod to any node. Insufficient allocatable CPU or memory across all nodes is the most common trigger, since the scheduler filters out nodes whose free resources cannot satisfy the Pod's requests.

Why this answer

A Pod stuck in Pending state means the scheduler cannot place it on a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the Pod unscheduled. This is indicated by the Pod's status remaining Pending and typically confirmed via `kubectl describe pod` showing events like '0/1 nodes are available: 1 Insufficient cpu'.

Exam trap

This question tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff, probe failures), so the trap is confusing post-scheduling container issues with pre-scheduling resource constraints.

How to eliminate wrong answers

Option A is wrong because a container crashing (e.g., CrashLoopBackOff) occurs after the Pod is scheduled and running, not while it is still in Pending state. Option B is wrong because a container image typo (e.g., ImagePullBackOff) prevents the container from starting but does not block scheduling; the Pod would be scheduled first, then fail to pull the image. Option D is wrong because a failing liveness probe causes the container to be restarted or the Pod to be marked as Unhealthy, but this happens only after the Pod is running, not during the Pending phase.

Full explanation →

674

MCQeasy

What is the primary purpose of the Container Runtime Interface (CRI) in Kubernetes?

A.To store container images in a registry

B.To define the format of container images

C.To manage container network interfaces

D.To provide a standard interface between the kubelet and container runtimes

AnswerD

CRI decouples the kubelet from specific container runtimes, letting containerd, CRI-O or others plug in without kubelet code changes. This abstraction satisfies the stem's requirement for a standard interface, enabling runtime swaps independently of Kubernetes releases.

Why this answer

The Container Runtime Interface (CRI) is a plugin protocol that enables the kubelet to use any OCI-compliant container runtime (e.g., containerd, CRI-O) without needing to recompile Kubernetes. It defines gRPC APIs for runtime and image service operations, abstracting the runtime implementation from the kubelet's pod lifecycle management.

Exam trap

CNCF often tests the distinction between CRI (runtime abstraction) and CNI (network abstraction), so the trap here is confusing container runtime management with container networking, leading candidates to pick Option C.

How to eliminate wrong answers

Option A is wrong because storing container images in a registry is the function of a container registry (e.g., Docker Hub, Amazon ECR), not the CRI; the CRI's image service pulls images from registries but does not store them. Option B is wrong because defining the format of container images is the responsibility of the OCI Image Specification, not the CRI; the CRI consumes images in that format but does not define it. Option C is wrong because managing container network interfaces is the role of the Container Network Interface (CNI), not the CRI; the CRI focuses on runtime and image operations, while CNI handles network attachment.

Full explanation →

675

MCQhard

An administrator runs `kubectl taint nodes node1 dedicated=gpu:NoSchedule` and then creates a Pod with the toleration `key: dedicated, operator: Equal, value: gpu, effect: NoSchedule`. The Pod is scheduled onto node1, but the administrator expected the taint to repel all Pods without a matching toleration. Which statement explains why the Pod was still placed on node1?

A.The taint effect `NoSchedule` only applies to Pods created in the kube-system namespace, so user Pods are unaffected.

B.The toleration matches the taint, so the scheduler is allowed to place the Pod on node1; taints repel only Pods that do not tolerate them.

C.Taints are only enforced during eviction, not during initial scheduling, so any Pod can land on a tainted node.

D.The toleration must use `operator: Exists` to match a taint with a value; `operator: Equal` never matches when a value is present.

AnswerB

A taint with effect `NoSchedule` prevents scheduling of Pods that do not have a matching toleration. The Pod in the scenario has an Equal toleration for key `dedicated`, value `gpu`, and effect `NoSchedule`, which matches the taint exactly. Therefore the scheduler treats the node as eligible and places the Pod there. The administrator's expectation was incorrect because the Pod is not repelled.

Why this answer

Taints and tolerations work as a pair: a taint repels Pods that lack a matching toleration, but a Pod that tolerates the taint is allowed onto the node. Because the Pod's toleration matched the taint's key, value, and effect, the scheduler correctly placed it on node1. The administrator's mental model omitted the effect of the toleration, which is the intended escape hatch.

Exam trap

The trap here is treating a taint as an absolute prohibition, when a matching toleration explicitly permits scheduling onto the tainted node.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 601–675