Kubernetes and Cloud Native Associate KCNA KCNA Questions 751–825 | Page 11/13

751

MCQmedium

A pod is stuck in 'Pending' state. Which of the following is a likely cause?

A.The pod's command returned a non-zero exit code

B.The container image is invalid

C.Insufficient CPU or memory resources on any available node

D.The pod's liveness probe failed

AnswerC

The scheduler cannot bind the pod to any node because no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests. With no feasible node, the pod remains unscheduled in Pending rather than being placed and failing at runtime.

Why this answer

A pod remains in 'Pending' state when the scheduler cannot find a suitable node to run it. The most common reason is insufficient CPU or memory resources on any available node, as the scheduler checks resource requests against node allocatable resources before binding the pod. If no node meets the pod's resource requirements, the pod stays pending until resources become available.

Exam trap

The KCNA exam often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or command issues with the Pending state instead of recognizing that Pending is exclusively a scheduling-phase problem.

How to eliminate wrong answers

Option A is wrong because a non-zero exit code from the pod's command causes the container to crash and restart, resulting in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option B is wrong because an invalid container image (e.g., wrong tag or registry) leads to an 'ImagePullBackOff' or 'ErrImagePull' state, as the kubelet fails to pull the image, but the pod is first scheduled to a node before image pull occurs. Option D is wrong because a failed liveness probe causes the kubelet to restart the container, resulting in a 'CrashLoopBackOff' or 'Running' state with restarts, not 'Pending'; liveness probes only affect running containers.

Full explanation →

752

MCQmedium

A Deployment named 'web-app' is configured with replicas: 3. You update the container image. Which Kubernetes object directly manages the pods during the rolling update?

A.StatefulSet

B.DaemonSet

C.Job

D.ReplicaSet

AnswerD

A Deployment creates and owns a ReplicaSet, which in turn maintains the desired pod count and directly manages pod creation and deletion during a rolling update. The Deployment orchestrates revisions, but the ReplicaSet satisfies the replicas: 3 constraint by spawning replacement pods as old ones terminate.

Why this answer

When a Deployment is updated (e.g., container image change), it creates a new ReplicaSet to manage the new pods and scales down the old ReplicaSet. The ReplicaSet is the Kubernetes object that directly owns and manages the pods during the rolling update, ensuring the desired number of replicas are running at each step.

Exam trap

The trap here is that candidates often think the Deployment directly manages pods, but Kubernetes uses ReplicaSets as the intermediary to handle pod scaling and updates, making ReplicaSet the correct answer.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications requiring stable network identities and persistent storage, not for stateless rolling updates managed by a Deployment. Option B is wrong because a DaemonSet ensures a pod runs on every node, and it does not participate in rolling updates triggered by a Deployment. Option C is wrong because a Job is designed for batch processing tasks that run to completion, not for managing long-running pods during a rolling update.

Full explanation →

753

MCQeasy

Which kubectl command is used to see the logs of a container in a pod?

A.kubectl attach <pod-name>

B.kubectl logs <pod-name>

C.kubectl exec <pod-name> -- cat /var/log/app.log

D.kubectl describe pod <pod-name>

AnswerB

kubectl logs retrieves stdout and stderr captured by the kubelet for a container in the named pod, which is the standard mechanism for inspecting application output. Flags such as -c select a specific container in multi-container pods.

Why this answer

`kubectl logs <pod-name>` is the dedicated command to retrieve and display the logs from the default container in a specified pod. This command directly accesses the container's stdout and stderr streams, which are captured by the container runtime (e.g., containerd or CRI-O) and stored by the kubelet, making it the standard and simplest way to view application logs.

Exam trap

The trap here is that candidates may confuse `kubectl logs` with `kubectl exec` for log retrieval, mistakenly thinking that accessing a log file inside the container is the standard approach, when Kubernetes expects logs to be captured from stdout/stderr and accessed via `kubectl logs`.

How to eliminate wrong answers

Option A is wrong because `kubectl attach` attaches to a running container's stdin/stdout/stderr streams, allowing interactive input, but it does not retrieve historical logs; it shows live output and requires the container to be running. Option C is wrong because while `kubectl exec` can run a command inside a container (like `cat /var/log/app.log`), this assumes the application writes logs to a file rather than stdout/stderr, which violates the Kubernetes logging best practice of using stdout/stderr for log aggregation; it also requires the file to exist and be accessible. Option D is wrong because `kubectl describe pod` provides detailed metadata and status information about the pod (e.g., events, conditions, container states), but it does not show container logs.

Full explanation →

754

MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Namespaces can be nested

B.Namespaces are required for all resources

C.Namespaces provide network isolation by default

D.Namespaces are used to logically isolate resources like pods and services

AnswerD

Namespaces partition cluster resources, giving pods, services and other objects a logical scope so names need only be unique within each namespace. This satisfies the stem's requirement for logical isolation, though it is not network security: traffic between namespaces still flows unless NetworkPolicies restrict it.

Why this answer

Kubernetes Namespaces provide a mechanism to logically isolate resources such as Pods, Services, and Deployments within a single cluster. They enable multi-tenancy by partitioning cluster resources among multiple users or teams, each operating within their own virtual cluster. This logical isolation does not include network segmentation by default, but it allows for resource quota enforcement and access control via RBAC.

Exam trap

The trap here is that candidates often confuse logical isolation with network isolation, assuming Namespaces automatically restrict traffic between them, when in fact they only provide a scope for naming and resource management without any built-in network segmentation.

How to eliminate wrong answers

Option A is wrong because Kubernetes Namespaces cannot be nested; they are flat organizational units within a cluster, and resources belong to exactly one namespace. Option B is wrong because not all Kubernetes resources are namespaced; cluster-scoped resources like Nodes, PersistentVolumes, and ClusterRoles exist outside any namespace. Option C is wrong because Namespaces do not provide network isolation by default; network policies are required to enforce traffic rules between pods in different namespaces, and without them, pods in different namespaces can communicate freely.

Full explanation →

755

Multi-Selecthard

A platform team is designing a progressive delivery rollout for a new version of a service running on Kubernetes. They want to send a small percentage of live traffic to the new version, observe metrics, and automatically roll back if error rates rise. Which two components are required to implement this with a service mesh? (Choose two.)

Select 2 answers

A.A canary or weighted routing rule in the mesh that splits traffic between the stable and new versions.

B.A NodePort Service exposing the canary directly to external users for manual testing.

C.A separate Kubernetes cluster dedicated to canary workloads.

D.A HorizontalPodAutoscaler configured to scale the canary based on CPU.

E.Metrics collection and an analysis mechanism that evaluates error rates and triggers rollback.

AnswersA, E

Progressive delivery depends on controlling the percentage of requests reaching each version. A mesh routing rule, such as an Istio VirtualService with weighted destinations, directs a small share of traffic to the canary while the rest goes to the stable version. Without this split, all traffic hits one version and no gradual exposure occurs.

Why this answer

Progressive delivery with a service mesh requires two capabilities: a routing rule that splits traffic by percentage between stable and canary, and an analysis loop that reads metrics and decides whether to promote or roll back. Together they enable small, safe exposure and automatic recovery from regressions.

Exam trap

The trap here is focusing on extra infrastructure like separate clusters or autoscalers, when the essential pieces are traffic splitting and metrics-driven analysis.

Full explanation →

756

Multi-Selecteasy

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

Select 2 answers

A.Terraform

B.kubectl

C.Pulumi

D.Helm

E.Docker Compose

AnswersA, C

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

Why this answer

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

Exam trap

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

Full explanation →

757

Multi-Selectmedium

A platform engineer is troubleshooting a Pod that stays in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Select 2 answers

A.No node in the cluster has sufficient allocatable CPU or memory to satisfy the Pod's resource requests.

B.The Pod's liveness probe is failing repeatedly.

C.A nodeSelector or node affinity rule matches no nodes in the cluster.

D.The container's application process exits with a non-zero exit code.

E.The Pod's image tag does not exist in the registry.

AnswersA, C

Insufficient allocatable resources on all candidate nodes is a classic cause of Pending status. The scheduler cannot bind the Pod to any node because its resource requests cannot be satisfied, so the Pod remains unscheduled. Examining scheduler events and node allocatable capacity reveals this condition directly.

Why this answer

Pending means the Pod has been accepted by the API server but not yet scheduled to a node. The two legitimate causes here are scheduling constraints: insufficient allocatable CPU or memory across candidate nodes, and node affinity or nodeSelector rules that match no nodes. Image pull failures, probe failures, and application crashes occur after scheduling and therefore do not produce a Pending phase.

Exam trap

The trap here is conflating container runtime failures such as image pull errors and probe failures with scheduling failures, when only scheduling constraints leave a Pod in Pending.

Full explanation →

758

MCQeasy

Which of the following is used to logically isolate resources within a Kubernetes cluster?

A.Annotations

B.Selectors

C.Namespaces

D.Labels

AnswerC

Namespaces partition a single Kubernetes cluster into virtual scopes, letting objects such as pods and services be grouped and addressed independently. This satisfies the stem's requirement for logical isolation, since names, quotas and RBAC policies can be scoped per namespace without provisioning separate physical clusters.

Why this answer

Namespaces provide logical isolation for resources. Option C is correct.

Full explanation →

759

Multi-Selectmedium

Which THREE of the following are valid ways to pass configuration data to a container in a pod? (Select 3)

Select 3 answers

A.Modifying the container image after deployment

B.Using a PersistentVolumeClaim to store configuration

C.Setting environment variables directly in the pod spec

D.Using a ConfigMap mounted as a volume

E.Using a Secret as an environment variable

AnswersC, D, E

The env field in a container spec injects configuration as environment variables at container start, satisfying the requirement to pass configuration data directly. Values can be literal or reference ConfigMap and Secret keys, making this a valid in-spec mechanism.

Why this answer

Option C is correct because the pod spec allows you to define environment variables directly under the container's env field, which Kubernetes injects into the container process at startup. Option D is correct because a ConfigMap can be mounted as a volume, making its key-value pairs available as files inside the container's filesystem. Option E is correct because a Secret can be exposed as an environment variable using env or envFrom with valueFrom.secretKeyRef or secretRef, delivering sensitive configuration data to the container.

Option A is not a valid runtime configuration method because container images are immutable after deployment and cannot be modified in place. Option B is not a configuration-passing mechanism; a PersistentVolumeClaim provides persistent storage, not structured configuration data.

Exam trap

The trap here is that candidates might think PersistentVolumeClaims are valid for configuration data because they associate 'storage' with 'configuration files,' but PVCs are designed for persistent data, not for injecting small, mutable configuration values that are better handled by ConfigMaps or environment variables.

Full explanation →

760

MCQmedium

A user creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. What is the most likely cause?

A.The Deployment's YAML had a syntax error

B.There is insufficient node capacity to schedule the third pod

C.The container image name is misspelled

D.The ReplicaSet controller is not running

AnswerB

The ReplicaSet controller has created three pods, but the scheduler leaves one Pending because no node has sufficient allocatable CPU or memory. Replica count and scheduling are separate concerns, so insufficient node capacity is the most likely cause.

Why this answer

The most likely cause is insufficient node capacity, as the scheduler cannot place the third pod due to resource constraints (CPU, memory, or other limits). The Deployment controller creates a ReplicaSet, which instructs the scheduler to place pods; if nodes lack sufficient allocatable resources, pods remain in Pending state. This is a common scenario when cluster resources are exhausted.

Exam trap

KCNA often tests the distinction between pod creation failures (e.g., image errors, syntax errors) and scheduling failures (resource exhaustion), where candidates mistakenly attribute missing pods to configuration errors rather than cluster capacity.

How to eliminate wrong answers

Option A is wrong because a syntax error in the YAML would cause the API server to reject the manifest entirely, resulting in zero pods running, not two out of three. Option C is wrong because a misspelled container image name would cause the pod to fail with ImagePullBackOff or ErrImagePull, but the ReplicaSet would still attempt to create three pods, and they would show as running (though with errors) or in CrashLoopBackOff, not simply missing. Option D is wrong because the ReplicaSet controller is a core component of kube-controller-manager; if it were not running, no ReplicaSets would be reconciled, and zero pods would be created, not two.

Full explanation →

761

MCQmedium

You want to deploy a stateless web application that should maintain 5 running instances at all times. You need to support rolling updates and rollbacks. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Deployment

C.ReplicaSet

D.StatefulSet

AnswerB

A Deployment manages stateless Pods through a ReplicaSet, guaranteeing the five replicas the stem demands. Its rolling update strategy replaces Pods incrementally, and `kubectl rollout undo` reverts to a prior revision, satisfying both the rolling update and rollback requirements. StatefulSets suit stateful workloads, and bare Pods lack self-healing.

Why this answer

A Deployment is the correct choice because it is designed to manage stateless applications with a desired replica count (5 instances), supports rolling updates to update pods gradually without downtime, and enables rollbacks to a previous revision if an update fails. Deployments internally create ReplicaSets to manage pod scaling and versioning, making them ideal for stateless workloads requiring high availability and update flexibility.

Exam trap

The trap here is that candidates often pick ReplicaSet because it maintains replica counts, but they overlook that Deployments are the required resource for rolling updates and rollbacks, as ReplicaSets alone do not provide these higher-level lifecycle management features.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because DaemonSets ensure one pod runs on each node, not a fixed number of replicas across the cluster, and they do not support rolling updates or rollbacks in the same controlled manner as Deployments. Option C (ReplicaSet) is wrong because while it can maintain a desired replica count, it lacks built-in support for rolling updates and rollbacks; Deployments are the higher-level abstraction that manages ReplicaSets for these features. Option D (StatefulSet) is wrong because StatefulSets are designed for stateful applications requiring stable network identities and persistent storage, not for stateless web apps, and they have different update strategies that are not as straightforward for simple rolling updates.

Full explanation →

762

Multi-Selecthard

Which TWO statements about Namespaces are correct?

Select 2 answers

A.Resource names must be unique within a namespace

B.Namespaces provide network isolation by default

C.All Kubernetes resources are namespaced

D.Namespaces provide a way to divide cluster resources between multiple users

E.You can delete a namespace without affecting the resources inside it

AnswersA, D

Within a single namespace, object names must be unique for a given resource type, because the API server scopes identity by namespace plus name. This satisfies the stem's requirement for a correct Namespaces statement, unlike cross-namespace naming, which may legitimately repeat.

Why this answer

Option A is correct because within a single namespace, resource names (for a given resource type) must be unique — for example, you cannot have two Pods both named 'web' in the same namespace, though the same name can exist in different namespaces. Option D is correct because namespaces are intended to divide cluster resources among multiple users or teams, commonly combined with ResourceQuota and RBAC to scope access and limit consumption per namespace. Option B is not correct because namespaces do not provide network isolation by default; Pods across namespaces can communicate freely unless NetworkPolicies are applied.

Option C is not correct because not all resources are namespaced — cluster-scoped resources such as Nodes, PersistentVolumes, and ClusterRoles exist outside any namespace. Option E is not correct because deleting a namespace deletes all resources contained within it, so it does affect the resources inside.

Exam trap

The KCNA exam often tests the misconception that namespaces provide automatic network isolation, when in fact they only provide logical grouping and resource quota boundaries, not network segmentation.

Full explanation →

763

Multi-Selecthard

Which TWO of the following statements about Kubernetes Deployments are correct? (Select 2)

Select 2 answers

A.Deployments support rolling updates and rollbacks

B.Deployments ensure that a copy of a Pod runs on each node in the cluster

C.Deployments are used for batch processing jobs that run to completion

D.Deployments manage the lifecycle of ReplicaSets

E.Deployments provide stable network identities for Pods

AnswersA, D

Deployments use a rolling update strategy to replace Pods gradually, and retain revision history so kubectl rollout undo can revert to a previous ReplicaSet. This satisfies the stem's requirement for correct Deployment statements, distinguishing them from bare ReplicaSets, which lack rollback capability.

Why this answer

Option A is correct because a Deployment's pod template can be updated declaratively, and the Deployment controller performs a rolling update by creating a new ReplicaSet and gradually scaling it up while scaling the old one down, with `kubectl rollout undo` providing rollback to a previous revision. Option D is correct because a Deployment does not manage Pods directly; it creates and manages ReplicaSets, which in turn maintain the desired number of Pod replicas, and each template change produces a new ReplicaSet revision. Option B is wrong because running one Pod copy per node is the job of a DaemonSet, not a Deployment.

Option C is wrong because run-to-completion batch workloads are handled by Jobs (or CronJobs), whereas Deployments are intended for long-running stateless services. Option E is wrong because stable network identities and per-Pod DNS names are provided by a headless Service (typically with a StatefulSet), not by a Deployment.

Exam trap

The CNCF exam often tests the distinction between Deployments and other controllers like DaemonSets, StatefulSets, and Jobs, so the trap here is confusing the purpose of Deployments (stateless, scalable apps) with controllers that handle per-node scheduling, stateful identities, or batch workloads.

Full explanation →

764

Multi-Selectmedium

Which TWO are valid reasons to use a Namespace in Kubernetes?

Select 2 answers

A.To enforce network policies that restrict traffic between Pods in different Namespaces.

B.To reduce the number of API calls to the control plane.

C.To isolate resources and prevent naming collisions between different teams.

D.To improve application performance by reducing latency.

E.To store environment variables for containers.

AnswersA, C

NetworkPolicy objects are namespaced resources, so placing Pods in separate Namespaces lets you apply policies that restrict cross-Namespace traffic. This directly satisfies the stem's requirement to enforce network policies restricting traffic between Pods in different Namespaces.

Why this answer

Option A is correct because Namespaces provide a boundary for scoping resources, and NetworkPolicy objects are namespaced resources that select Pods within a namespace; policies can allow or deny ingress/egress traffic to Pods in other namespaces, so namespaces are a valid way to organize and enforce network segmentation between teams or environments. Option C is correct because Namespaces provide logical isolation of cluster resources (Pods, Services, ConfigMaps, etc.) and enforce unique names within each namespace, so two teams can each create a Service named 'web' in their own namespace without collision. Option B is not a reason to use Namespaces, since namespaces do not reduce control-plane API calls; if anything, managing more namespaces adds API objects.

Option D is not correct because namespaces are an organizational and isolation construct and do not reduce network latency or improve application performance. Option E is not correct because environment variables for containers are supplied via Pod specs, ConfigMaps, or Secrets, not by namespaces themselves.

Exam trap

CNCF often tests the misconception that Namespaces provide performance benefits or reduce API load, when in reality they are purely a logical isolation and naming boundary with no direct impact on network speed or control plane traffic.

Full explanation →

765

MCQmedium

Which command correctly creates a Deployment named 'web-app' with the image 'nginx:1.21' and 3 replicas?

A.kubectl apply deployment web-app --image=nginx:1.21 --replicas=3

B.kubectl run web-app --image=nginx:1.21 --replicas=3

C.kubectl create deployment web-app --image=nginx:1.21 --replicas=3

D.kubectl create deployement web-app --image=nginx:1.21 --replicas=3

AnswerC

`kubectl create deployment` generates the Deployment manifest imperatively, and the `--replicas=3` flag sets `.spec.replicas` directly, satisfying the stem's three-replica constraint. The `--image=nginx:1.21` flag populates the container spec with the exact pinned tag, so a single command yields the named 'web-app' Deployment.

Why this answer

`kubectl create deployment` is the imperative command specifically designed to create a Deployment resource in Kubernetes. The `--image` flag specifies the container image, and `--replicas=3` sets the desired number of pod replicas, which matches the requirement exactly.

Exam trap

CNCF often tests the distinction between `kubectl run` (which creates a Pod, not a Deployment) and `kubectl create deployment` (which creates a Deployment with replica management), leading candidates to mistakenly choose `kubectl run` when replicas are required.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a manifest file or stdin input; it does not accept `--image` or `--replicas` flags directly, and the syntax `apply deployment` is invalid. Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with certain flags), but it does not support the `--replicas` flag; it is used for ad-hoc pods, not multi-replica Deployments. Option D is wrong because `deployement` is a misspelling of `deployment`, which causes a command syntax error; Kubernetes CLI commands are case-sensitive and must match the exact resource name.

Full explanation →

766

MCQmedium

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

A.Helm

B.Prometheus

C.Envoy

D.Knative

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

767

MCQhard

A platform engineer is configuring an OpenTelemetry Collector pipeline. They want to ensure that sensitive data such as credit card numbers is not exported to the observability backend. Which component of the Collector should they use to modify or drop attributes before export?

A.A processor in the pipeline

B.An exporter in the pipeline

C.A receiver in the pipeline

D.A connector in the pipeline

AnswerA

Processors in the OpenTelemetry Collector operate on telemetry data between receivers and exporters. They can modify, filter, or drop attributes. For example, the attributes processor can delete or hash sensitive fields like credit card numbers. This makes processors the correct component to sanitize data before it leaves the cluster, ensuring compliance and privacy.

Why this answer

Processors are the components in an OpenTelemetry Collector pipeline that transform telemetry data. They can add, remove, or modify attributes, including dropping sensitive information. By placing a processor such as the attributes or filter processor before the exporter, the engineer can ensure that credit card numbers are removed or obfuscated before data is sent to the backend.

Receivers, exporters, and connectors do not serve this purpose.

Exam trap

The trap here is assuming that any component in the pipeline can modify data, when only processors are designed for that transformation step.

Full explanation →

768

Multi-Selectmedium

A DevOps team uses Helm to manage Kubernetes applications. They want to ensure that sensitive data (e.g., database passwords) is not stored in plaintext in the Helm chart or in the cluster's ConfigMaps/Secrets. Which TWO practices should they adopt? (Choose two.)

Select 2 answers

A.Use an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) to inject secrets at runtime

B.Store secrets in a separate Git repository with restricted access

C.Use a tool like sealed-secrets to encrypt the secrets before committing them to the chart

D.Store secrets as Kubernetes Secrets and reference them in the chart values

E.Use Helm's built-in encryption for values files

AnswersA, C

External secrets operators fetch secrets from external stores and create Kubernetes Secrets without exposing them in the chart.

Why this answer

Using an external secrets operator (e.g., AWS Secrets Manager, HashiCorp Vault) allows secrets to be injected directly into Pods at runtime without ever storing them in the Helm chart or as Kubernetes Secrets in plaintext. This approach leverages the Kubernetes CSI (Container Storage Interface) or a sidecar pattern to mount secrets from an external store, ensuring sensitive data never resides in the cluster's etcd or version control.

Exam trap

CNCF often tests the misconception that base64 encoding in Kubernetes Secrets is equivalent to encryption, leading candidates to incorrectly select Option D as secure, when in fact base64 is merely an encoding and provides no confidentiality.

Full explanation →

769

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane? (Choose two.)

Select 2 answers

A.kube-proxy

B.container runtime

C.kube-apiserver

D.kube-controller-manager

E.kubelet

AnswersC, D

The kube-apiserver runs on control-plane nodes and exposes the Kubernetes API, validating and persisting every object to etcd. It is a core control-plane component, satisfying the stem's requirement to identify two control-plane parts rather than worker-node agents like kubelet.

Why this answer

The Kubernetes control plane consists of components that make global cluster decisions and manage cluster state, and kube-apiserver (C) is the central control plane component that exposes the Kubernetes API and is the front end through which all other components communicate. kube-controller-manager (D) is also a control plane component; it runs the built-in controllers (such as node, replication, endpoints, and service account controllers) that continuously reconcile the desired state stored in etcd with the actual cluster state. By contrast, kube-proxy (A) is a node-level component that maintains network rules (iptables/IPVS) for Service load balancing, the container runtime (B) is node software like containerd or CRI-O that actually runs containers, and kubelet (E) is the node agent that registers the node and manages pods on it — all three run on worker nodes rather than as part of the control plane.

Exam trap

The trap here is that kube-proxy and kubelet sound like 'control' components but are actually node-level services, while the container runtime is often mistakenly thought of as part of the control plane due to its critical role.

Full explanation →

770

MCQeasy

Which of the following describes the Open Container Initiative (OCI) image specification?

A.A standard for container images and runtimes

B.A specification for container orchestration

C.A specification for container storage

D.A specification for container networking

AnswerA

The OCI image specification defines a vendor-neutral format for container images, covering the manifest, configuration, and filesystem layers. This satisfies the stem's requirement for a standardised image definition, distinct from runtime concerns, which the separate OCI runtime specification addresses. It enables portability across compliant registries and engines.

Why this answer

The Open Container Initiative (OCI) image specification defines a standard format for container images, ensuring that any OCI-compliant image can be run by any OCI-compliant runtime (e.g., runc, crun). This specification covers the image manifest, filesystem layers, and configuration, enabling interoperability across different container platforms like Docker, Podman, and containerd. Option A is correct because the OCI specifically standardizes both the image format and the runtime behavior, not higher-level orchestration or infrastructure concerns.

Exam trap

CNCF often tests the distinction between OCI (image/runtime) and CNI/CSI (networking/storage), so the trap here is that candidates confuse the OCI specification with other container ecosystem standards like CNI or CSI due to similar acronyms and overlapping container contexts.

How to eliminate wrong answers

Option B is wrong because container orchestration is the domain of tools like Kubernetes, Docker Swarm, and Nomad, which manage scheduling, scaling, and service discovery—not the OCI image specification. Option C is wrong because container storage is addressed by separate standards like the Container Storage Interface (CSI), which defines how storage systems are exposed to containerized workloads, not by the OCI image spec. Option D is wrong because container networking is governed by the Container Network Interface (CNI), which specifies how network plugins configure network interfaces for containers, whereas the OCI image spec focuses solely on image and runtime standards.

Full explanation →

771

MCQhard

A developer creates a Deployment with 3 replicas. After updating the pod template, they run 'kubectl rollout status deployment/my-deployment' and see that the rollout is stuck. Which command should they use to investigate the rollout history?

A.kubectl get events

B.kubectl describe deployment my-deployment

C.kubectl rollout history deployment/my-deployment

D.kubectl logs deployment/my-deployment

AnswerC

The rollout history subcommand queries the Deployment's recorded revisions, showing each revision number and change-cause annotation. This reveals whether a bad revision or stalled progression caused the stuck rollout, directly satisfying the need to investigate rollout history.

Why this answer

'kubectl rollout history' is the dedicated command to view the revision history of a Deployment, including the changes made to the pod template in each revision. When a rollout is stuck, this command helps identify which revision caused the issue and allows you to roll back to a previous stable revision. The other commands provide general debugging information but do not specifically show the rollout history.

Exam trap

CNCF often tests the distinction between commands that show current state (describe, get events) versus commands that show historical state (rollout history), trapping candidates who confuse 'investigating the rollout history' with general troubleshooting.

How to eliminate wrong answers

Option A is wrong because 'kubectl get events' shows cluster-wide events (e.g., pod scheduling failures, image pull errors) but does not display the revision history of a Deployment's rollouts. Option B is wrong because 'kubectl describe deployment' shows the current state and conditions of the Deployment (including rollout status) but does not list the historical revisions or changes to the pod template. Option D is wrong because 'kubectl logs' is used to fetch logs from a running container, not to inspect Deployment revision history; it cannot be used directly on a Deployment object and requires a pod name.

Full explanation →

772

MCQmedium

You need to create a ConfigMap from a file named 'app.properties'. Which kubectl command should you use?

A.kubectl create configmap my-config --from-literal=app.properties

B.kubectl create configmap my-config --file=app.properties

C.kubectl create configmap my-config --from-env-file=app.properties

D.kubectl create configmap my-config --from-file=app.properties

AnswerD

--from-file reads the given file's contents and stores them as a single ConfigMap key named after the file, so app.properties becomes one entry. This satisfies the stem's requirement to build a ConfigMap directly from that file without manual YAML.

Why this answer

`kubectl create configmap` with the `--from-file` flag creates a ConfigMap from a file, using the filename as the key and its content as the value. This is the standard way to import a properties file into a ConfigMap in Kubernetes.

Exam trap

The most common mistake is confusing --from-file with --from-env-file. --from-file creates a ConfigMap entry with the filename as the key and file content as value. --from-env-file parses the file line by line as key=value pairs.

How to eliminate wrong answers

Option A is wrong because `--from-literal` expects a key=value pair directly in the command, not a filename; it would treat 'app.properties' as a literal string key with no value. Option B is wrong because `--file` is not a valid flag for `kubectl create configmap`; the correct flag is `--from-file`. Option C is wrong because `--from-env-file` imports a file line-by-line as environment variables, but it expects each line to be in KEY=VALUE format and does not preserve the filename as a key; it is used for importing environment files, not for creating a ConfigMap with the file content as a single key-value pair.

Full explanation →

773

MCQmedium

Which component of the control plane is responsible for persisting the entire cluster state?

A.kube-scheduler

B.kube-controller-manager

C.etcd

D.kube-apiserver

AnswerC

etcd is the distributed key-value store holding all cluster objects and their state; the API server reads and writes every resource there. Only etcd persists cluster state durably, so losing it loses the cluster's configuration and workload definitions.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects (Pods, Services, ConfigMaps, etc.), their specifications, and their current status. It is the only component that persists data to disk, ensuring that the cluster can recover its full state after a restart or failure. The kube-apiserver reads from and writes to etcd, but etcd itself is the storage backend.

Exam trap

The KCNA exam often tests the misconception that kube-apiserver is the persistence layer because it is the central entry point, but the trap is that the API server is stateless and only acts as a gateway to etcd, which is the actual durable store.

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, but it does not persist any state; it only updates scheduling decisions via the API server. Option B is wrong because kube-controller-manager runs controller loops (e.g., ReplicaSet, Node, Deployment controllers) that reconcile desired state with actual state, but it relies on etcd for persistence and does not store data itself. Option D is wrong because kube-apiserver is the front-end for the control plane that validates and processes REST requests, but it delegates all persistent storage to etcd and does not maintain its own durable state.

Full explanation →

774

Multi-Selectmedium

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

Select 2 answers

A.Monolithic deployment

B.Stateful sessions

C.Config

D.Disposability

E.Manual provisioning

AnswersC, D

Config is a 12-factor principle.

Why this answer

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

Exam trap

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

Full explanation →

775

Multi-Selectmedium

Which TWO statements about Docker Compose and Kubernetes are correct?

Select 2 answers

A.Kubernetes is only used in production environments

B.Docker Compose and Kubernetes use the same YAML manifest format

C.Kubernetes provides built-in auto-scaling and self-healing capabilities

D.Docker Compose is designed for single-host container orchestration

E.Docker Compose supports multi-node clustering out-of-the-box

AnswersC, D

Kubernetes reconciles desired state through controllers: the ReplicaSet controller replaces failed pods, while the Horizontal Pod Autoscaler scales replicas based on CPU or custom metrics. This satisfies the stem's requirement for built-in auto-scaling and self-healing, capabilities Docker Compose lacks natively.

Why this answer

Option C is correct because Kubernetes natively provides controllers such as the Horizontal Pod Autoscaler (HPA) for auto-scaling and ReplicaSets/Deployments with liveness and readiness probes for self-healing, restarting or rescheduling failed pods automatically. Option D is correct because Docker Compose orchestrates containers on a single Docker host using a docker-compose.yml file and the docker compose CLI, without any native multi-node scheduling. Option A is wrong because Kubernetes is also widely used in development, testing, edge, and CI environments, not only production.

Option B is wrong because although both use YAML, their manifest schemas differ: Compose uses keys like services, image, and ports, while Kubernetes uses apiVersion, kind, metadata, and spec. Option E is wrong because Docker Compose has no built-in multi-node clustering; Docker Swarm or Kubernetes are needed for that.

Exam trap

A common misconception is that Docker Compose and Kubernetes use the same YAML format, but they are distinct schemas with different top-level keys and resource definitions. Candidates may confuse 'docker-compose.yml' with Kubernetes manifests.

Full explanation →

776

MCQeasy

What is the primary purpose of Kubernetes?

A.To orchestrate containers across a cluster of machines

B.To provide a graphical user interface for managing containers

C.To replace Docker as a container runtime

D.To provide a virtual machine management platform

AnswerA

Kubernetes schedules, runs and reconciles containerised workloads across a pool of machines, handling placement, scaling, networking and self-healing. This satisfies the stem's requirement that containers be orchestrated across a cluster rather than run on a single host.

Why this answer

Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of machines. Its primary purpose is to abstract the underlying infrastructure and provide declarative management of container workloads, ensuring desired state convergence through controllers like the ReplicaSet and Deployment.

Exam trap

A common misconception is that Kubernetes is a container runtime or a GUI tool, but its primary purpose is container orchestration across a cluster of machines.

How to eliminate wrong answers

Option B is wrong because Kubernetes does not provide a graphical user interface as its primary purpose; while dashboards like the Kubernetes Dashboard exist, they are optional add-ons, not the core function. Option C is wrong because Kubernetes is not a container runtime replacement; it uses container runtimes like containerd or CRI-O via the Container Runtime Interface (CRI) and does not replace Docker or any specific runtime. Option D is wrong because Kubernetes manages containers, not virtual machines; although it can run on VMs, it does not provide a VM management platform like VMware vSphere or OpenStack.

Full explanation →

777

MCQhard

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

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

B.It executes business logic in response to events

C.It provides a user interface to view events

D.It converts events into HTTP requests

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

778

MCQhard

An administrator notices that a pod in a Deployment is stuck in CrashLoopBackOff. The pod logs show 'Error: failed to start container: exec: "app": executable file not found in $PATH'. What is the most likely cause?

A.The image registry credentials are missing

B.The liveness probe is misconfigured and killing the container

C.The container is running as a non-root user without proper permissions

D.The container image does not contain the binary specified in the pod's command field

AnswerD

The error shows the container runtime cannot locate the "app" executable in $PATH, meaning the image lacks that binary. The command field references a file absent from the image, so the container exits immediately and Kubernetes retries, producing CrashLoopBackOff.

Why this answer

The error 'exec: "app": executable file not found in $PATH' indicates that the container image does not contain the binary or script specified in the pod's command field (e.g., `command: ["app"]`). This typically happens when the image is built without the expected executable, the command path is incorrect, or the image tag points to a different version. The container fails to start because the runtime cannot locate the entrypoint.

Exam trap

CNCF often tests the distinction between image pull errors (ImagePullBackOff) and container execution errors (CrashLoopBackOff), so candidates may confuse missing credentials with a missing executable in the image.

How to eliminate wrong answers

Option A is wrong because missing registry credentials would cause an ImagePullBackOff, not a CrashLoopBackOff with an exec error in logs. Option B is wrong because a misconfigured liveness probe would cause the container to be restarted after it starts, but the exec error occurs before the container can run, so the probe never executes. Option C is wrong because running as a non-root user without permissions would produce a 'permission denied' error, not an 'executable file not found' error.

Full explanation →

779

Multi-Selectmedium

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

Select 2 answers

A.Improved observability of service-to-service communication

B.Direct management of virtual machines

C.Automated container image building

D.Replacing the need for a container runtime

E.Traffic management capabilities such as canary deployments

AnswersA, E

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

Why this answer

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

Full explanation →

780

MCQhard

An administrator is configuring a NetworkPolicy to allow ingress traffic to Pods with label `role=db` only from Pods with label `role=api` on TCP port 6379. The NetworkPolicy is applied in the same namespace as the Pods. Which NetworkPolicy YAML correctly implements this requirement?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379 egress: - to: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - namespaceSelector: {} ports: - protocol: TCP port: 6379

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: db ports: - protocol: TCP port: 6379

AnswerA

This policy selects Pods with role=db and allows ingress from Pods with role=api on TCP port 6379. It correctly uses podSelector in the ingress rule to match the source Pods and specifies the port. Since it is in the same namespace, no namespaceSelector is needed. This precisely implements the requirement, allowing only the intended traffic.

Why this answer

The correct NetworkPolicy selects the target Pods (role=db) and defines an ingress rule that allows traffic from Pods labeled role=api on TCP port 6379. It uses a podSelector within the from clause to match the source Pods. Since both sets of Pods are in the same namespace, no namespaceSelector is required.

The other options either allow too much traffic, reverse the roles, or add unnecessary egress restrictions that could disrupt other traffic.

Exam trap

The trap here is using an empty namespaceSelector, which allows all Pods in all namespaces, instead of a podSelector to restrict to specific Pods.

Full explanation →

781

MCQmedium

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

A.Terraform

B.Kuberntes manifests

C.AWS CloudFormation

D.Azure Resource Manager Templates

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

782

Multi-Selecthard

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

Select 2 answers

A.Verify that the kube-proxy is running on the node

B.Check that the container runtime is working

C.Check the kube-apiserver status

D.Check if the Service has any endpoints using 'kubectl get endpoints'

E.Restart all nodes in the cluster

AnswersA, D

kube-proxy programs the iptables or IPVS rules that implement ClusterIP Service load balancing on each node. If it is not running, traffic to the Service's virtual IP is never forwarded to backend Pods, so verifying it directly addresses the connectivity failure.

Why this answer

Option A is correct because ClusterIP Services rely on kube-proxy running on each node to program iptables/IPVS rules that translate the virtual ClusterIP into the backing Pod IPs, so if kube-proxy is down, traffic to the Service will fail. Option D is correct because a ClusterIP Service with no endpoints (empty Endpoints object) means the selector doesn't match any ready Pods, which is the most common cause of an unreachable Service; 'kubectl get endpoints <service>' quickly reveals this. Option B is not the right focus because a broken container runtime would affect Pod scheduling/status broadly, not specifically Service routing, and would typically show up as Pod failures rather than a Service-only issue.

Option C is not appropriate because if the kube-apiserver were down, kubectl commands and cluster-wide operations would fail, not just one web application's Service. Option E is not appropriate because restarting all nodes is a disruptive, non-diagnostic action that does not isolate the root cause and is not a troubleshooting step.

Exam trap

The trap here is that candidates often assume a Service is always reachable if the pods are running, forgetting that kube-proxy must be healthy and that the Service must have endpoints for traffic to be forwarded.

Full explanation →

783

MCQmedium

You have a Namespace 'team-a' and you want to see all Pods in that namespace, including those that are not ready. Which command should you use?

A.kubectl get pods -n team-a

B.kubectl get pods -n team-a -l app=myapp

C.kubectl get pods --namespace=team-a --field-selector=status.phase!=Running

D.kubectl get pods --all-namespaces

AnswerA

kubectl get pods -n team-a scopes the listing to that namespace and returns all pods regardless of readiness, since readiness only affects the READY column. Without -n, the command defaults to the current namespace, which may not be team-a.

Why this answer

`kubectl get pods -n team-a` retrieves all Pods in the specified namespace, regardless of their readiness or status. By default, `kubectl get pods` shows all Pods, including those that are not ready, and the `-n` flag targets the namespace. No additional filters are needed to include non-ready Pods.

Exam trap

A common misconception is that `kubectl get pods` only shows ready Pods, or that you need a special flag to see non-ready Pods, when in fact the default output includes all Pods regardless of readiness.

How to eliminate wrong answers

Option B is wrong because the `-l app=myapp` label selector filters Pods to only those with the label `app=myapp`, which may exclude Pods that are not ready if they lack that label, and it does not show all Pods in the namespace. Option C is wrong because `--field-selector=status.phase!=Running` explicitly excludes Pods in the Running phase, so it would only show Pods that are not ready (e.g., Pending, Succeeded, Failed), not all Pods including those that are ready. Option D is wrong because `--all-namespaces` shows Pods across all namespaces, not just the `team-a` namespace, and it does not filter by readiness.

Full explanation →

784

MCQmedium

A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?

A.Headless Service

B.Service with sessionAffinity: ClientIP

C.Ingress with default settings

D.Deployment with hostNetwork: true

AnswerB

Setting sessionAffinity: ClientIP on the Service makes kube-proxy route repeated requests from the same client IP to the same backend pod, satisfying the sticky session requirement across multiple replicas without an Ingress or external load balancer.

Why this answer

Setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

Exam trap

CNCF often tests the misconception that Ingress or Headless Services can handle session affinity by default, but only a Service with `sessionAffinity: ClientIP` provides this at the Kubernetes networking layer without additional configuration.

How to eliminate wrong answers

Option A is wrong because a Headless Service does not provide load balancing or session affinity; it returns the IPs of all Pods directly, requiring the client to handle routing. Option C is wrong because an Ingress with default settings does not maintain session affinity; it typically passes traffic to a Service without any stickiness, and Ingress controllers like NGINX require additional annotations (e.g., `nginx.ingress.kubernetes.io/affinity`) to enable sticky sessions. Option D is wrong because `hostNetwork: true` binds the Pod directly to the node's network stack, bypassing Kubernetes service networking entirely, and does not provide any session affinity mechanism.

Full explanation →

785

MCQhard

You create a Deployment with replicas: 3. You then scale the Deployment to 5 replicas. What is the order of operations that the Deployment controller follows?

A.It creates a new ReplicaSet with 5 replicas and deletes the old one

B.It directly creates 2 new pods without using a ReplicaSet

C.It updates the existing ReplicaSet's replica count to 5, and the ReplicaSet creates the new pods

D.It creates 2 new pods immediately without modifying the existing ReplicaSet

AnswerC

Scaling a Deployment adjusts the existing ReplicaSet's replica count rather than creating a new one; the ReplicaSet controller then creates the two additional pods to reach five, since no pod template change triggers a rollout.

Why this answer

When you scale a Deployment, the Deployment controller updates the replica count on the existing ReplicaSet that matches the pod template. The ReplicaSet controller then observes the desired count and creates the additional pods to reach the new target. This ensures that the Deployment's rollout history and rollback capabilities remain intact.

Exam trap

The trap here is that candidates often confuse scaling with a rolling update, assuming a new ReplicaSet is created, when in fact scaling only modifies the existing ReplicaSet's replica count without changing the pod template.

How to eliminate wrong answers

Option A is wrong because the Deployment does not create a new ReplicaSet when scaling; it reuses the existing one, and deleting the old ReplicaSet would lose the rollout history. Option B is wrong because the Deployment controller never creates pods directly; it always delegates pod creation to a ReplicaSet to maintain declarative state and ownership. Option D is wrong because the Deployment controller modifies the ReplicaSet's replica count, and the ReplicaSet creates the pods; it does not create pods independently of the ReplicaSet.

Full explanation →

786

MCQeasy

Which Kubernetes control plane component acts as the entry point for all administrative tasks and provides the REST API?

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerD

The kube-apiserver exposes the Kubernetes REST API and serves as the sole entry point for administrative tasks, validating and processing every request before persisting state to etcd. It satisfies the stem's requirement directly: all administrative operations, including kubectl commands, route through this component rather than any other control plane service.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. All administrative tasks, such as creating pods, scaling deployments, and querying cluster state, are performed by sending HTTP requests to this component. It validates and processes these requests before storing the resulting state in etcd.

Exam trap

CNCF often tests the misconception that etcd is the entry point because it stores cluster data, but the trap is that etcd is a backend datastore with no direct REST API for administrative tasks—the kube-apiserver is the sole gateway for all client interactions.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and scheduling policies, not for handling administrative API requests. Option B is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API entry point; it is accessed internally by the API server. Option C is wrong because kube-controller-manager runs controller processes (e.g., ReplicaSet controller, Node controller) that watch the API server for desired state changes, but it does not serve as the REST API endpoint.

Full explanation →

787

MCQeasy

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

A.Prometheus

B.Jaeger

C.Fluentd

D.etcd

AnswerD

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

Why this answer

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

Exam trap

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

Full explanation →

788

MCQmedium

You need to provide configuration data as environment variables to a pod, but the data is not sensitive. Which object should you use?

A.ConfigMap

B.Secret

C.ServiceAccount

D.PersistentVolume

AnswerA

ConfigMap stores non-sensitive configuration as key–value pairs, which Kubernetes can project into a pod as environment variables via `envFrom` or `valueFrom.configMapKeyRef`. This satisfies the stem's constraint that the data is not sensitive, unlike Secret, which is intended for credentials and base64-encodes values.

Why this answer

A ConfigMap is the correct Kubernetes object for providing non-sensitive configuration data as environment variables to a pod. ConfigMaps are designed to decouple configuration artifacts from image content to keep containers portable, and they support injection via environment variables, command-line arguments, or volume mounts. Unlike Secrets, ConfigMaps store data in plaintext (base64-encoded only for transport) and are intended for data that does not require encryption at rest or in transit.

Exam trap

The trap here is that candidates often confuse ConfigMap with Secret, assuming that any data passed as environment variables must be sensitive, or they overlook that ServiceAccounts are for identity, not configuration data.

How to eliminate wrong answers

Option B (Secret) is wrong because Secrets are specifically designed for sensitive data such as passwords, tokens, or keys, and they support additional features like encryption at rest and integration with external key management systems; using a Secret for non-sensitive data is unnecessary and violates the principle of least privilege. Option C (ServiceAccount) is wrong because a ServiceAccount is an identity object used to control pod-level authentication and authorization to the Kubernetes API, not a mechanism for storing or injecting configuration data. Option D (PersistentVolume) is wrong because a PersistentVolume is a storage abstraction for persistent data that survives pod restarts, not a means to provide ephemeral configuration data as environment variables.

Full explanation →

789

MCQhard

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

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

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

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

D.Move the payment service to a serverless platform

AnswerC

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

Why this answer

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

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

Exam trap

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

Full explanation →

790

MCQmedium

You have a Deployment that must run exactly one replica on each node in the cluster for logging purposes. Which Kubernetes resource should you use?

A.Job

B.Deployment

C.StatefulSet

D.DaemonSet

AnswerD

A DaemonSet guarantees one pod replica on every node, matching the stem's exactly-one-per-node logging requirement. Unlike a Deployment, whose replica count is cluster-wide and scheduler-placed, the DaemonSet controller bypasses scheduling decisions and tracks node membership, automatically adding pods to newly joined nodes.

Why this answer

A DaemonSet ensures that exactly one replica of a Pod runs on every node in the cluster, including when nodes are added or removed. This makes it the ideal resource for cluster-wide logging, monitoring, or other node-level agents that must be present on each node.

Exam trap

A common misconception is that a Deployment with a high replica count can achieve per-node coverage, but Deployments do not enforce node-level placement and can leave some nodes empty or run multiple Pods on the same node.

How to eliminate wrong answers

Option A is wrong because a Job is designed to run a finite task to completion, not to maintain a persistent Pod on every node. Option B is wrong because a Deployment manages a desired number of replicas across the cluster, but it does not guarantee one Pod per node; it uses a scheduler to distribute replicas arbitrarily. Option C is wrong because a StatefulSet is intended for stateful applications requiring stable network identities and ordered deployment, not for ensuring one Pod per node.

Full explanation →

791

MCQeasy

A developer wants to run a single instance of a stateless web application in a Kubernetes cluster. The application does not need to maintain state or have a stable network identity. Which workload resource is the most appropriate to use?

A.Deployment

B.StatefulSet

C.DaemonSet

D.Job

AnswerA

A Deployment is ideal for stateless applications as it manages ReplicaSets and provides declarative updates, scaling, and self-healing. It allows you to define the desired state, and the Deployment controller ensures the actual state matches, handling pod creation and replacement automatically. This is the standard choice for stateless web applications.

Why this answer

A Deployment is the standard Kubernetes resource for managing stateless applications. It provides declarative updates, scaling, and self-healing by managing ReplicaSets. For a stateless web application that does not require stable identities or persistent storage, a Deployment offers the right balance of simplicity and functionality, ensuring the application remains available and can be updated seamlessly.

Exam trap

The trap here is confusing stateless and stateful workloads; Deployments are for stateless, while StatefulSets are for stateful applications requiring stable identities.

Full explanation →

792

MCQeasy

What is the purpose of a Service in Kubernetes?

A.To provide persistent storage volumes

B.To manage rolling updates of pods

C.To expose a set of pods as a network service with a stable endpoint

D.To store configuration data as key-value pairs

AnswerC

A Service provides a stable virtual IP and DNS name that load-balances traffic across a dynamically changing set of pods selected by labels. This decouples clients from individual pod IPs, which change as pods are created or replaced.

Why this answer

A Service in Kubernetes provides a stable network endpoint (IP address and DNS name) to access a set of Pods, which are ephemeral and can be created or destroyed dynamically. It decouples the client from the Pods' IPs by using label selectors to route traffic, enabling reliable communication within the cluster or externally. This is defined in the Kubernetes API as a Service resource, with types like ClusterIP, NodePort, and LoadBalancer.

Exam trap

The trap here is that candidates confuse the Service's role of exposing Pods with the Deployment's role of managing Pod lifecycles, leading them to pick Option B, but a Service does not handle updates or scaling—it only provides a stable network endpoint.

How to eliminate wrong answers

Option A is wrong because persistent storage volumes are provided by PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources, not by a Service. Option B is wrong because managing rolling updates of Pods is the responsibility of a Deployment controller, which handles update strategies like RollingUpdate or Recreate. Option D is wrong because storing configuration data as key-value pairs is the role of ConfigMaps and Secrets, not a Service.

Full explanation →

793

MCQeasy

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

A.Loose coupling

B.Immutable infrastructure

C.Statelessness

D.Service discovery

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

794

MCQmedium

You have a Kubernetes cluster with multiple nodes. You need to ensure that a pod runs on a node that has an SSD. How should you achieve this?

A.Manually edit kube-scheduler configuration

B.Use a DaemonSet to run the pod on all nodes

C.Use a nodeSelector with the label 'disktype: ssd'

D.Use a toleration for the node

AnswerC

nodeSelector constrains scheduling by matching pod requirements against node labels. Labelling SSD nodes with disktype=ssd and setting that selector in the pod spec forces the scheduler to place the pod only on nodes carrying that label.

Why this answer

NodeSelector is the simplest and most direct way to constrain a Pod to run only on nodes that have a specific label, such as 'disktype=ssd'. When you add a nodeSelector field to the Pod spec, the kube-scheduler filters nodes that do not have the matching label, ensuring the Pod lands on a node with an SSD.

Exam trap

The trap here is confusing tolerations (which allow scheduling onto tainted nodes) with node selection mechanisms like nodeSelector or nodeAffinity, leading candidates to pick D when they need a label-based constraint.

How to eliminate wrong answers

Option A is wrong because manually editing the kube-scheduler configuration is unnecessary and overly complex; node scheduling constraints are handled via Pod spec fields like nodeSelector, nodeAffinity, or taints/tolerations, not by modifying the scheduler itself. Option B is wrong because a DaemonSet runs a copy of the Pod on every node (or a subset defined by nodeSelector), but the question asks to ensure the Pod runs on a node with an SSD, not on all nodes. Option D is wrong because tolerations are used to allow Pods to schedule onto nodes with matching taints, not to select nodes based on labels like 'disktype=ssd'; tolerations alone do not guarantee placement on a specific node type.

Full explanation →

795

MCQmedium

A cluster administrator needs to schedule a pod that requires 4 CPU cores and 16Gi of memory on a node with sufficient resources. The pod also must tolerate a taint on a dedicated node. Which combination of pod spec fields must be set to ensure the pod lands on the correct node?

A.resources.limits and nodeSelector

B.tolerations and resources.limits

C.affinity and resources.limits

D.resources.requests and tolerations

AnswerD

resources.requests tells the scheduler the minimum CPU and memory needed, so it only considers nodes with enough allocatable capacity. tolerations allow the pod to be scheduled onto a node with a matching taint, overriding the default eviction behaviour. Together they ensure the pod is placed on a node that both fits the resource requirements and is permitted by the taint.

Why this answer

The scheduler uses resource requests to filter nodes that have enough allocatable CPU and memory. Tolerations are required to permit scheduling onto a node with a taint. Limits and nodeSelector do not satisfy the dual requirement of resource fit and taint tolerance.

Therefore, the pod must specify both requests and tolerations.

Exam trap

The trap here is confusing resource limits with requests; limits do not influence scheduling decisions, only requests do.

Full explanation →

796

Multi-Selecthard

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

Select 3 answers

A.Event processing can trigger multiple downstream actions

B.Requires a central database for state

C.Synchronous communication between components

D.Components communicate by emitting and reacting to events

E.Loose coupling between event producers and consumers

AnswersA, D, E

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

Why this answer

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

Full explanation →

797

MCQmedium

A cluster administrator needs to run a node-level log-shipping agent on every node, including nodes added later, and wants the agent to tolerate the control-plane taint. Which workload API object is the most appropriate choice?

A.A StatefulSet with podAntiAffinity requiring one Pod per node.

B.A ReplicaSet with replicas equal to the current node count.

C.A Deployment with a nodeSelector for each existing node name.

D.A DaemonSet with a toleration for the control-plane taint.

AnswerD

A DaemonSet ensures that a copy of a Pod runs on every eligible node and automatically schedules new Pods onto nodes that join the cluster. Adding a toleration for the control-plane taint lets the agent also run on control-plane nodes. This directly matches the requirement for continuous node-level coverage across existing and future nodes.

Why this answer

A DaemonSet is designed for node-level agents such as log shippers, monitoring exporters, and CNI plugins. It places one Pod on each node that matches scheduling constraints and automatically covers nodes that join later. Combining it with a toleration for the control-plane taint allows the agent to run on control-plane nodes as well, satisfying the administrator's full-coverage requirement.

Exam trap

The trap here is treating a Deployment or ReplicaSet as a one-Pod-per-node mechanism, when only a DaemonSet automatically maintains node-level coverage including newly added nodes.

Full explanation →

798

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

Full explanation →

799

MCQhard

A team wants to implement GitOps for their Kubernetes workloads using Argo CD. They have multiple environments (dev, staging, prod) in separate clusters. What is the best practice for structuring the Git repository?

A.A single branch with all environment manifests in the same folder

B.Separate repositories per environment

C.Store all manifests in a single file with environment labels

D.A monorepo with a directory per environment and overlays for differences

AnswerD

A monorepo with a directory per environment, using overlays (for example Kustomize) to express per-environment differences, keeps shared manifests DRY while allowing dev, staging and prod to diverge safely. This satisfies the constraint of managing multiple separate clusters from one auditable source of truth, with Argo CD Applications targeting each overlay.

Why this answer

A monorepo with a directory per environment and overlays (e.g., using Kustomize or Helm) allows you to manage environment-specific differences declaratively while keeping a single source of truth. Argo CD can sync each environment's directory to its respective cluster, and overlays minimize duplication by applying only the necessary patches (e.g., replica counts, ingress hosts) on top of a common base. This approach aligns with GitOps best practices for multi-environment deployments.

Exam trap

The trap here is that candidates often choose Option B (separate repos) thinking it provides the best isolation, but the KCNA exam emphasizes that a monorepo with overlays is the recommended pattern for GitOps because it reduces duplication and simplifies cross-environment consistency.

How to eliminate wrong answers

Option A is wrong because storing all environment manifests in the same folder on a single branch makes it impossible to isolate environment-specific changes, leading to accidental cross-environment deployments and no clear promotion path. Option B is wrong because separate repositories per environment introduce fragmentation, making it harder to maintain consistency across environments and requiring duplicate base configurations, which violates the DRY principle. Option C is wrong because storing all manifests in a single file with environment labels (e.g., using YAML anchors or labels) is not supported by Argo CD's native sync mechanism—Argo CD syncs entire manifests, not filtered by labels, and this approach would cause all environments to be deployed simultaneously, breaking environment isolation.

Full explanation →

800

MCQhard

Which Kubernetes resource can be used to assign a pod to a specific node?

A.Node affinity rules in the pod spec

B.A NetworkPolicy

C.A Service account

D.A ConfigMap

AnswerA

Node affinity in the pod spec constrains scheduling to nodes matching label expressions, such as requiredDuringSchedulingIgnoredDuringExecution with a hostname selector. This assigns the pod to a specific node, unlike taints, which repel pods rather than attract them.

Why this answer

Node affinity rules in the pod spec are a set of constraints that define which nodes a pod can be scheduled on, based on node labels. This is a native Kubernetes scheduling feature that allows you to attract pods to specific nodes using required or preferred matching rules, such as `requiredDuringSchedulingIgnoredDuringExecution`. This directly answers the question of assigning a pod to a specific node.

Exam trap

A common trap is thinking that a NetworkPolicy or a ConfigMap can influence pod placement, when in fact only scheduling constructs like node affinity, nodeSelector, or taints/tolerations control node assignment.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy is a Kubernetes resource that controls ingress and egress traffic between pods and network endpoints, not pod placement or node assignment. Option C is wrong because a Service account provides an identity for pods to authenticate with the Kubernetes API server, and it has no role in scheduling or node selection. Option D is wrong because a ConfigMap is used to inject configuration data (key-value pairs) into pods as environment variables, command-line arguments, or files; it does not influence the scheduler's node assignment.

Full explanation →

801

Multi-Selectmedium

Which TWO of the following correctly describe the difference between Docker Compose and Kubernetes? (Choose 2)

Select 2 answers

A.Docker Compose can manage containers across multiple hosts

B.Docker Compose is suitable for production-grade deployments

C.Kubernetes provides built-in auto-scaling and self-healing

D.Kubernetes supports rolling updates and rollbacks

E.Both Docker Compose and Kubernetes use the same YAML format

AnswersC, D

Kubernetes offers features like HorizontalPodAutoscaler and ReplicaSet controllers for auto-scaling and self-healing.

Why this answer

Docker Compose is designed for single-host container orchestration with a simple YAML file, while Kubernetes is a multi-host container orchestration platform with advanced features like auto-scaling and self-healing.

Full explanation →

802

MCQmedium

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

803

Multi-Selecthard

Which THREE of the following are true about the Container Runtime Interface (CRI)? (Choose 3)

Select 3 answers

A.Docker natively implements the CRI

B.CRI is part of the Open Container Initiative (OCI)

C.CRI allows kubelet to communicate with different container runtimes

D.containerd implements the CRI

E.CRI-O is a lightweight runtime designed for Kubernetes

AnswersC, D, E

CRI is the abstraction layer between kubelet and container runtimes, defining gRPC services (RuntimeService, ImageService) so kubelet can drive containerd, CRI-O or others without runtime-specific code. This directly satisfies the stem's requirement that CRI enables kubelet to communicate with different container runtimes.

Why this answer

Option C is correct because the Container Runtime Interface is precisely the gRPC API that kubelet uses to talk to a container runtime, decoupling Kubernetes from any single runtime implementation. Option D is correct because containerd ships a built-in CRI plugin (enabled by default) that lets kubelet use containerd directly as a CRI-compliant runtime. Option E is correct because CRI-O is a lightweight OCI-compliant container runtime built specifically to serve as a Kubernetes CRI implementation.

Option A is not correct because Docker does not natively implement CRI; the historical dockershim adapter was needed to bridge kubelet to Docker, and it has since been removed. Option B is not correct because CRI is a Kubernetes project specification, not part of the Open Container Initiative, which instead defines the OCI runtime and image specifications.

Exam trap

KCNA often tests the misconception that Docker is a CRI runtime or that CRI is an OCI standard — candidates must distinguish Kubernetes' CRI from OCI's image/runtime specs.

Full explanation →

804

MCQhard

An administrator wants to ensure that a pod only runs on nodes that have a specific GPU. Which mechanism should be used to achieve this?

A.Node affinity with requiredDuringSchedulingIgnoredDuringExecution

B.Tolerations and taints

C.Pod anti-affinity

D.ResourceQuota

AnswerA

Node affinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard scheduling rule, so the pod is placed only on nodes whose labels match the specified GPU. This satisfies the constraint that the pod must run exclusively on GPU-equipped nodes.

Why this answer

Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` is the correct mechanism because it allows you to specify hard constraints that a pod must be scheduled on a node with a specific label (e.g., `gpu-type: nvidia-tesla`). This ensures the pod is only placed on nodes that have the required GPU hardware, as the scheduler will enforce the rule during scheduling and ignore it after the pod is running.

Exam trap

Kubernetes often tests the distinction between node affinity (attracting pods to nodes) and taints/tolerations (repelling pods from nodes), leading candidates to mistakenly choose tolerations when the requirement is to ensure a pod runs only on nodes with a specific resource.

How to eliminate wrong answers

Option B is wrong because tolerations and taints are used to repel pods from nodes (unless they tolerate the taint), not to attract pods to nodes with specific hardware; they control which pods can be scheduled on a node, not which nodes a pod must run on. Option C is wrong because pod anti-affinity is used to prevent pods from being co-located on the same node or topology (e.g., for high availability), not to enforce placement on nodes with specific resources like GPUs. Option D is wrong because a ResourceQuota limits the total resources (e.g., CPU, memory) consumed by all pods in a namespace, but it cannot constrain a pod to run only on nodes with a specific GPU.

Full explanation →

805

Multi-Selectmedium

Which two statements correctly describe etcd in a Kubernetes cluster?

Select 2 answers

A.It is a key-value store that holds cluster configuration and state

B.It runs on every worker node

C.It manages network rules for Services

D.It implements the Kubernetes API

E.It is a critical component that must be backed up regularly

AnswersA, E

etcd is the consistent, distributed key-value store backing the cluster, persisting all API objects including configuration, Secrets and state. Every read and write through the API server depends on it, making it the authoritative source of cluster data.

Why this answer

Option A is correct because etcd is the distributed, consistent key-value store that persists all Kubernetes cluster data, including configuration, object definitions, and cluster state, making it the single source of truth for the control plane. Option E is correct because etcd is a critical component: losing its data can render the cluster unrecoverable, so regular backups (e.g., via etcdctl snapshot save) are essential for disaster recovery. Option B is wrong because etcd typically runs only on control plane nodes (or as an external cluster), not on every worker node.

Option C is wrong because network rules for Services are handled by kube-proxy (and CNI plugins), not etcd. Option D is wrong because the Kubernetes API is implemented by the kube-apiserver, which reads from and writes to etcd rather than etcd implementing the API itself.

Exam trap

A common misconception is that etcd runs on all nodes or that it directly handles networking, when in fact it is a control-plane-only store that does not participate in data-plane operations.

Full explanation →

806

MCQmedium

Which Kubernetes resource is best suited for running a batch processing job that must complete successfully exactly once?

A.DaemonSet

B.Deployment

C.CronJob

D.Job

AnswerD

A Job creates one or more pods and tracks successful completions, restarting pods only until the required count succeeds. This directly satisfies the stem's "complete successfully exactly once" constraint, unlike a Deployment or ReplicaSet, which maintain continuous availability rather than terminating after completion.

Why this answer

A Kubernetes Job is designed specifically for batch processing tasks that need to run to completion exactly once. It creates one or more Pods and ensures that a specified number of them successfully terminate, making it ideal for workloads like data processing or backups that must finish without retries or restarts.

Exam trap

CNCF often tests the distinction between one-time batch processing (Job) and recurring scheduled tasks (CronJob), so candidates mistakenly choose CronJob when the question specifies 'exactly once' rather than 'on a schedule'.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, which is used for continuous background services like logging or monitoring, not for one-time batch jobs. Option B is wrong because a Deployment manages a set of Pods to maintain a desired number of replicas running indefinitely, with rolling updates and self-healing, which is unsuitable for a job that must complete and not restart. Option C is wrong because a CronJob is used for scheduling recurring tasks on a time-based schedule, not for a one-time batch job that must run exactly once.

Full explanation →

807

Multi-Selectmedium

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

Select 2 answers

A.Aggregating logs into a centralized system

B.Collecting metrics from all services and infrastructure

C.Storing all data in a single monolithic database

D.Disabling health checks to reduce overhead

E.Using only manual inspection of individual pod logs

AnswersA, B

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

Why this answer

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

Exam trap

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

Full explanation →

808

MCQhard

You have a web application that needs to read configuration from a file and also access a database password. Which combination of resources should you use to manage these configurations securely?

A.Use ConfigMap for configuration file and Secret for database password

B.Use ConfigMap for both

C.Use PersistentVolume for configuration and environment variables for the password

D.Use Secret for both

AnswerA

ConfigMaps hold non-sensitive configuration data such as files, while Secrets store sensitive values like database passwords with base64 encoding and tighter access controls. Splitting them keeps credentials out of plain configuration and satisfies the secure-management requirement.

Why this answer

ConfigMap is designed for storing non-confidential configuration data like configuration files, while Secret is specifically for sensitive data such as database passwords. Secrets are base64-encoded and can be encrypted at rest using etcd encryption or KMS, providing a security boundary that ConfigMaps lack. This combination follows Kubernetes best practices for separating configuration from secrets.

Exam trap

The CNCF often tests the misconception that Secrets are inherently secure because they are base64-encoded, leading candidates to think Secrets are safe for all data, when in fact base64 is not encryption and Secrets require additional encryption-at-rest configuration for true security.

How to eliminate wrong answers

Option B is wrong because using ConfigMap for both stores the database password in plaintext (or base64 without encryption), exposing sensitive data to anyone with access to the ConfigMap API. Option C is wrong because PersistentVolume is for persistent storage of large data, not for managing configuration or secrets, and environment variables for the password would expose it in plaintext in the pod spec and process list. Option D is wrong because Secrets are not intended for non-sensitive configuration files; using Secrets for everything adds unnecessary complexity and defeats the purpose of having separate resource types for different security levels.

Full explanation →

809

MCQmedium

You have a Deployment defined with replicas: 3. You run 'kubectl scale deployment my-deployment --replicas=5'. What happens?

A.The Deployment is updated to have 5 replicas, but existing pods are recreated to match.

B.The command fails because you cannot scale a Deployment directly.

C.The Deployment rolls out a new version with 5 replicas.

D.The Deployment is updated to have 5 replicas, and the ReplicaSet creates 2 additional pods.

AnswerD

Scaling updates the Deployment's desired replica count to 5, and the Deployment controller propagates this to its ReplicaSet, which creates 2 additional pods to reach the target. This satisfies the stem's constraint that the change flows through the Deployment–ReplicaSet ownership hierarchy rather than acting on pods directly.

Why this answer

`kubectl scale` directly updates the `.spec.replicas` field of the Deployment, which in turn instructs the existing ReplicaSet to adjust its pod count. The ReplicaSet controller then creates 2 additional Pods to reach the desired 5 replicas, without recreating existing Pods or triggering a rollout.

Exam trap

The trap here is that candidates confuse scaling with rolling updates, assuming that any change to a Deployment triggers a rollout, when in fact only changes to the Pod template (e.g., image, command) cause a new ReplicaSet to be created.

How to eliminate wrong answers

Option A is wrong because scaling does not recreate existing Pods; the ReplicaSet simply adds or removes Pods to match the new replica count, leaving healthy Pods untouched. Option B is wrong because `kubectl scale` is a valid command for Deployments, ReplicaSets, and StatefulSets, and it does not fail when used correctly. Option C is wrong because scaling does not trigger a rollout (which would require a change to the Pod template, such as a new container image); it only changes the replica count, leaving the current ReplicaSet in place.

Full explanation →

810

MCQeasy

Which of the following is the smallest deployable unit in Kubernetes?

A.Service

B.Container

C.Pod

D.Node

AnswerC

A pod groups one or more containers that share a network namespace and volumes, and is the atomic unit the scheduler places on a node. Deployments, ReplicaSets and Services operate on pods rather than being scheduled themselves.

Why this answer

Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto nodes; instead, Kubernetes always schedules and manages Pods as atomic units, making the Pod the fundamental building block of deployment.

Exam trap

The trap here is that candidates often think a Container is the smallest unit because Docker popularized containers as atomic units, but Kubernetes abstracts one level higher — the Pod — to manage shared resources and scheduling, making the Pod the smallest deployable object.

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them, not a deployable unit — Pods are deployed, and Services provide stable networking to those Pods. Option B is wrong because a Container is the runtime instance of an image, but Kubernetes never deploys a container directly; it always wraps containers inside a Pod to manage shared resources and scheduling. Option D is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit — Pods are deployed onto Nodes, but the Node itself is infrastructure, not a unit of deployment.

Full explanation →

811

Multi-Selectmedium

Which TWO of the following are true about the Open Container Initiative (OCI)?

Select 2 answers

A.OCI requires the use of containerd

B.OCI defines the Dockerfile format

C.OCI is a Linux Foundation project

D.OCI specifies the image format and runtime specification

E.OCI defines the Container Runtime Interface (CRI)

AnswersC, D

OCI is hosted under the Linux Foundation.

Why this answer

The Open Container Initiative (OCI) is a Linux Foundation project that was established to create open industry standards around container formats and runtimes. It operates under the Linux Foundation's governance to ensure vendor-neutral specifications.

Exam trap

The trap here is that candidates often confuse OCI with Kubernetes-specific components like CRI or assume OCI mandates a particular runtime like containerd, when in fact OCI is a vendor-neutral standard that does not enforce any specific implementation.

Full explanation →

812

MCQmedium

Which API version is correct for a Deployment in modern Kubernetes (v1.29+)?

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta2

AnswerC

Deployments moved from the deprecated extensions/v1beta1 to the stable apps/v1 group, which remains the required API version through Kubernetes v1.29 and beyond. Specifying apps/v1 satisfies the stem's modern-cluster constraint, ensuring the manifest is accepted rather than rejected as an unknown or removed resource type.

Why this answer

In modern Kubernetes (v1.29+), the `apps/v1` API version is the stable and recommended version for the Deployment resource. The `apps/v1` API has been the default since Kubernetes 1.9, and all older beta versions (e.g., `apps/v1beta2`, `extensions/v1beta1`) have been removed as of Kubernetes 1.16. Using `apps/v1` ensures compatibility with current cluster features and avoids deprecation warnings.

Exam trap

The exam often tests the misconception that `v1` is the default API version for all resources, but candidates must remember that Deployments specifically require the `apps/v1` group, not the core `v1` group.

How to eliminate wrong answers

Option A is wrong because `extensions/v1beta1` was deprecated in Kubernetes 1.8 and removed entirely in Kubernetes 1.16; it is no longer available in v1.29+. Option B is wrong because `v1` is the core API version used for resources like Pods, Services, and ConfigMaps, but Deployments are not part of the core API group—they belong to the `apps` group. Option D is wrong because `apps/v1beta2` was a beta version of the Deployment API that was deprecated in Kubernetes 1.9 and removed in Kubernetes 1.16; it is not valid in modern clusters.

Full explanation →

813

MCQmedium

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

A.API Gateway

B.Load balancer

C.Service registry

D.Sidecar proxy

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

814

Multi-Selectmedium

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

Select 2 answers

A.Perform manual deployment to avoid automation errors

B.Maximize robustness through stateful sessions

C.Ensure fast startup and graceful shutdown (disposability)

D.Build monolithic applications for simplicity

E.Store configuration in environment variables

AnswersC, E

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

Why this answer

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

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

Exam trap

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

Full explanation →

815

MCQmedium

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taints that the pod didn't tolerate, 3 nodes had insufficient memory'. What is the most likely issue?

A.The node with the taint has a toleration mismatch.

B.The pod's image pull is failing.

C.The pod's resource requests exceed available memory on three nodes.

D.The pod was evicted due to resource pressure.

AnswerC

The scheduler reports insufficient memory on three nodes, meaning each lacks the capacity to satisfy the pod's declared resource requests. Requests, not actual usage, drive scheduling decisions, so the pod remains Pending until a node with adequate allocatable memory becomes available.

Why this answer

The scheduler event explicitly states '3 nodes had insufficient memory', which directly indicates that the pod's resource requests (specifically memory) exceed the available allocatable memory on those three nodes. The fourth node is unavailable due to taints, leaving zero schedulable nodes, hence the 'Pending' state.

Exam trap

The KCNA exam often tests the distinction between taint/toleration and resource constraints — candidates mistakenly think the taint is the primary issue, but the event clearly shows only one node is tainted while three have insufficient memory, making resource exhaustion the dominant cause.

How to eliminate wrong answers

Option A is wrong because the event says '1 node had taints that the pod didn't tolerate', which is a taint/toleration mismatch, not a toleration mismatch on the node — the pod lacks the required toleration, not the node. Option B is wrong because image pull failures would appear as 'ErrImagePull' or 'ImagePullBackOff' events in 'kubectl describe pod', not as node availability issues. Option D is wrong because eviction due to resource pressure would result in a 'Terminating' or 'Evicted' status, not 'Pending', and the event would reference eviction, not node availability.

Full explanation →

816

MCQeasy

What is the primary purpose of the `kubectl apply` command?

A.To create or update resources from a manifest

B.To view resource details

C.To delete resources

D.To execute commands inside a container

AnswerA

kubectl apply performs a declarative create-or-update by comparing the manifest against live state and patching differences. This satisfies the requirement to reconcile resources from a file, unlike imperative create, which fails if the resource already exists.

Why this answer

The `kubectl apply` command uses a declarative approach to manage Kubernetes resources. It sends a PATCH request to the API server, which compares the desired state in the provided manifest (YAML/JSON) with the current state of the resource in the cluster. If the resource does not exist, it creates it; if it does exist, it updates only the fields specified in the manifest, preserving any fields not mentioned.

Exam trap

CNCF often tests the confusion between imperative commands (like `kubectl create` or `kubectl run`) and declarative commands (`kubectl apply`), leading candidates to mistakenly think `apply` only creates resources or only updates them, rather than understanding it handles both idempotently.

How to eliminate wrong answers

Option B is wrong because viewing resource details is the purpose of `kubectl get` (to list resources) or `kubectl describe` (to show detailed state), not `kubectl apply`. Option C is wrong because deleting resources is done with `kubectl delete`, which sends a DELETE request to the API server, whereas `apply` never removes resources. Option D is wrong because executing commands inside a container is the function of `kubectl exec`, which uses the container runtime's exec API (e.g., via CRI or Docker), not the Kubernetes API for resource management.

Full explanation →

817

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

818

Multi-Selecteasy

Which THREE statements about Kubernetes Namespaces are correct?

Select 3 answers

A.Namespaces provide a way to divide cluster resources between multiple users or teams.

B.All Kubernetes resources must be created within a namespace.

C.Namespaces provide network isolation by default.

D.Deleting a namespace will delete all resources in it.

E.Resource quotas can be applied to a namespace to limit total resource consumption.

AnswersA, D, E

Namespaces create logical partitions within a single cluster, letting teams share underlying nodes while scoping names, RBAC and quotas per partition. This satisfies the stem's requirement for dividing cluster resources between multiple users or teams without provisioning separate clusters.

Why this answer

Option A is correct because Kubernetes Namespaces are designed as a logical partitioning mechanism that lets a single physical cluster be shared among multiple users, teams, or projects, scoping names and resource usage per group. Option D is correct because deleting a Namespace triggers cascading deletion of all namespaced objects contained in it (e.g., Pods, Services, ConfigMaps), so the namespace and its contents are removed together. Option E is correct because ResourceQuota objects are applied at the namespace scope to cap aggregate consumption of resources such as CPU, memory, and object counts within that namespace.

Option B is incorrect because many resources are cluster-scoped and cannot live in a namespace, such as Nodes, PersistentVolumes, ClusterRoles, and StorageClasses. Option C is incorrect because namespaces do not enforce network isolation by default; without a NetworkPolicy, pods in different namespaces can communicate freely, so isolation must be explicitly configured.

Exam trap

CNCF often tests the misconception that Namespaces provide automatic network isolation, but in reality, network policies must be explicitly defined to restrict traffic between namespaces.

Full explanation →

819

MCQhard

You are asked to schedule a pod on a node that has SSD storage. Which mechanism should you use to achieve this?

A.Use a resource request for SSD storage capacity

B.Set an annotation on the pod specifying the disk type

C.Add a nodeSelector with a label matching the node, e.g., disktype: ssd

D.Add a toleration for a taint on SSD nodes

AnswerC

nodeSelector pins the Pod to nodes bearing matching labels, so labelling SSD nodes disktype: ssd and referencing it in the Pod spec satisfies the SSD constraint. This differs from affinity, which expresses richer preference and topology rules.

Why this answer

NodeSelector is the built-in Kubernetes mechanism for constraining a pod to nodes with specific labels. By labeling a node with disktype=ssd and adding that same label selector to the pod spec, the scheduler will only place the pod on nodes that have that label, ensuring it lands on SSD-equipped nodes.

Exam trap

The trap here is that candidates confuse tolerations (which only allow scheduling on tainted nodes) with node selectors (which actively target nodes), leading them to pick D instead of C.

How to eliminate wrong answers

Option A is wrong because resource requests specify minimum CPU/memory capacity, not storage type or node attributes; they cannot select nodes based on disk type. Option B is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node selection; they have no effect on pod placement. Option D is wrong because tolerations allow pods to be scheduled on tainted nodes but do not actively select nodes; they only permit scheduling on nodes that would otherwise repel the pod, without guaranteeing the node has SSD storage.

Full explanation →

820

MCQmedium

A developer creates a Pod with two containers. The first container writes logs every 30 seconds to a shared volume. The second container reads those logs. After deployment, the second container fails to start because it cannot find the log file. The Pod spec uses an emptyDir volume mounted at /var/logs in both containers. What is the most likely cause?

A.emptyDir volumes are not shared between containers in the same Pod; each container gets its own isolated volume.

B.The Pod's restartPolicy is set to Never, so the second container will not restart after failing.

C.The second container starts before the first container writes any logs, and it exits because the file does not exist.

D.The second container lacks the necessary permissions to read files written by the first container.

AnswerC

Containers in a Pod start concurrently, not sequentially. The reader container may start before the writer has created the log file, causing a failure if it expects the file to exist immediately. Using an init container or a retry loop would resolve this race condition.

Why this answer

Containers within a Pod start simultaneously without guaranteed ordering. When one container depends on a file created by another, the reader may start first and fail. This race condition is best solved by using an init container that waits for the file, or by making the reader container resilient to the file's absence.

Exam trap

The trap here is assuming that containers in a Pod start sequentially, with the first container completing its initial work before the second starts.

Full explanation →

821

MCQeasy

Which of the following is an example of immutable infrastructure?

A.SSH into a server to apply patches

B.Manually installing packages on a running container

C.Using configuration management tools to update software on running servers

D.Rebuilding a server from a pre-baked image and replacing the old one

AnswerD

Immutable infrastructure means servers are never patched in place. Instead, a new server is built from a pre-baked image and swapped in for the old one, which is then destroyed. This replacement model is the defining characteristic.

Why this answer

Immutable infrastructure means that once a server or container is deployed, it is never modified in place. Instead, any change requires building a new image and redeploying. Option D describes exactly this: rebuilding from a pre-baked image and replacing the old server, which is the core pattern of immutability in container orchestration (e.g., Kubernetes rolling updates or Recreate deployments).

Exam trap

CNCF often tests the misconception that configuration management tools (like Ansible or Puppet) are inherently immutable, but they are actually used for mutable infrastructure because they apply changes to running systems rather than replacing them entirely.

How to eliminate wrong answers

Option A is wrong because SSHing into a server to apply patches is a classic mutable infrastructure pattern — it modifies a running system in place, which breaks the immutability principle. Option B is wrong because manually installing packages on a running container directly alters its filesystem and state, making it mutable and unreproducible from the original image. Option C is wrong because using configuration management tools (like Ansible or Chef) to update software on running servers still mutates the live environment, which is the opposite of the immutable approach where changes are made only at the image build stage.

Full explanation →

822

MCQeasy

A platform engineer wants to restrict a Pod so that it runs only on nodes that have the label disktype=ssd. The engineer adds a nodeSelector field to the Pod specification. Which statement best describes the effect of nodeSelector in this scenario?

A.The Pod is scheduled only onto nodes that have at least one label, regardless of the label value.

B.The Pod is scheduled onto any node, but nodes without the label are given lower priority.

C.The Pod is scheduled only onto nodes whose labels match all specified key-value pairs.

D.The Pod can run on any node, but the kubelet on unlabeled nodes refuses to start the container.

AnswerC

nodeSelector is a hard scheduling constraint expressed as a map of labels. The scheduler filters nodes and only considers those that contain every label key-value pair listed in nodeSelector. If no node matches, the Pod remains Pending. In this scenario, only nodes labeled disktype=ssd are eligible, which is exactly the intended behavior.

Why this answer

nodeSelector is a hard constraint that filters the node set to those containing all specified labels. The scheduler binds the Pod only to a matching node; otherwise the Pod remains Pending. This makes it suitable for simple placement requirements such as selecting SSD-backed nodes.

The other descriptions confuse nodeSelector with soft preferences, kubelet behavior, or label existence checks, all of which are inaccurate.

Exam trap

The trap here is confusing nodeSelector's hard filter with node affinity's soft preference, leading to the belief that non-matching nodes are still usable with lower priority.

Full explanation →

823

MCQmedium

A Kubernetes cluster runs a critical application in a pod. The operations team wants to receive an alert if the application's main process stops responding to HTTP requests on port 8080 at path /healthz. They need Kubernetes to automatically restart the pod if the health check fails. Which type of probe should they configure?

A.startupProbe

B.httpProbe

C.livenessProbe

D.readinessProbe

AnswerC

A liveness probe checks if the container is still running and responsive. If the liveness probe fails, the kubelet kills the container and restarts it according to the pod's restart policy. This is exactly what the team needs: automatic restart upon health check failure to recover from unresponsive states.

Why this answer

A liveness probe is used to determine if a container is alive and healthy. When it fails, the kubelet restarts the container, which helps recover from deadlocks or unresponsive states. Configuring an HTTP liveness probe on port 8080 at /healthz will cause Kubernetes to periodically send HTTP GET requests; if the response is not successful, the container is restarted, meeting the alert and restart requirement.

Exam trap

The trap here is confusing liveness and readiness probes; liveness restarts the container on failure, while readiness only controls traffic routing without restarting.

Full explanation →

824

Multi-Selecteasy

Which TWO of the following are responsibilities of the kube-controller-manager? (Select 2)

Select 2 answers

A.Ensuring the desired number of pod replicas are running

B.Implementing service networking rules

C.Storing the cluster state

D.Detecting node failures and reacting

E.Scheduling pods onto nodes

AnswersA, D

The ReplicaSet controller, embedded within the kube-controller-manager, continuously reconciles the observed pod count against the declared replica count, creating or deleting pods to match. This control loop directly maintains the desired number of pod replicas, satisfying the stem's requirement.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicaSet controller (and Deployment controller), which continuously reconciles the actual number of pod replicas with the desired count specified in the ReplicaSet/Deployment spec. Option D is correct because the node lifecycle controller within the kube-controller-manager monitors node heartbeats and marks nodes as NotReady or evicts their pods when failures are detected. Option B is wrong because service networking rules are implemented by kube-proxy (via iptables/IPVS) on each node, not by the kube-controller-manager.

Option C is wrong because cluster state is stored in etcd, the distributed key-value store. Option E is wrong because pod placement is the job of the kube-scheduler, which binds pods to nodes.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager with the kube-scheduler or kube-proxy, because all three are control plane components that manage different aspects of cluster operations, but only the controller-manager handles state regulation and failure detection.

Full explanation →

825

MCQmedium

A pod is in the 'Pending' state. Which of the following is a likely cause?

A.The liveness probe is failing

B.The container image is not found in the registry

C.No node has sufficient resources to run the pod

D.The container exited with OOMKilled

AnswerC

The scheduler cannot bind the pod to any node because each candidate lacks allocatable CPU or memory to satisfy the pod's resource requests. Unschedulable pods remain Pending with a FailedScheduling event, so insufficient node capacity is the direct cause here.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.

Exam trap

CNCF often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff), tempting candidates to confuse post-scheduling errors with pre-scheduling conditions.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted (CrashLoopBackOff) or marked as Unhealthy, but does not prevent the pod from being scheduled; the pod must first be Running for probes to execute. Option B is wrong because an image not found in the registry results in an ImagePullBackOff or ErrImagePull error, which occurs after the pod is scheduled to a node, not while it is still in Pending. Option D is wrong because OOMKilled (exit code 137) is a container termination reason that occurs after the pod is Running, not during the scheduling phase; it would be visible in the pod status as CrashLoopBackOff or Terminated.

Full explanation →

Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 751–825