CCNA Kubernetes Fundamentals Questions — Page 3 of 6

151

MCQmedium

You run 'kubectl get pods' and see a Pod in the 'Pending' state. Which of the following is a likely cause?

A.No node meets the requested CPU or memory resources

B.The application crashed due to a bug

C.The container image is missing

D.The Pod has been deleted

AnswerA

The scheduler leaves a pod Pending when no node satisfies its resource requests, since it cannot bind the pod anywhere. Insufficient allocatable CPU or memory across all nodes is the classic trigger for this state.

Why this answer

A Pod enters the 'Pending' state when it cannot be scheduled onto a node. The most common reason is that no node in the cluster has sufficient available CPU or memory resources to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates nodes against Pod resource requirements, and if none match, the Pod remains unscheduled in Pending.

Exam trap

The trap here is confusing 'Pending' (scheduling failure) with 'CrashLoopBackOff' (runtime failure) or 'ImagePullBackOff' (image pull failure), leading candidates to pick a wrong answer about application or image issues.

How to eliminate wrong answers

Option B is wrong because an application crash due to a bug would cause the Pod to enter a CrashLoopBackOff or Error state, not Pending. Option C is wrong because a missing container image would result in an ImagePullBackOff or ErrImagePull state, not Pending. Option D is wrong because a deleted Pod would not appear in the output of 'kubectl get pods' at all; it would be removed from the API server.

Practice this question →

152

Multi-Selectmedium

Which TWO of the following are benefits of using a Deployment over managing ReplicaSets directly? (Choose two.)

Select 2 answers

A.Support for stateful workloads

B.Declarative scaling

C.Direct access to pod IP addresses

D.Automatic rolling updates and rollbacks

E.Ability to run a pod on every node

AnswersB, D

A Deployment's spec.replicas field lets you declare the desired pod count, and the Deployment controller reconciles ReplicaSets to match it. Managing ReplicaSets directly requires manual scaling of each set, so declarative scaling is a genuine Deployment benefit.

Why this answer

Option B (Declarative scaling) is correct because a Deployment declares the desired replica count in its spec (spec.replicas), and the Deployment controller continuously reconciles the actual number of pods to match that declared state, so scaling is expressed declaratively rather than by manually editing a ReplicaSet. Option D (Automatic rolling updates and rollbacks) is correct because Deployments manage ReplicaSets under the hood to perform rolling updates via spec.strategy (RollingUpdate with maxSurge/maxUnavailable) and preserve revision history (spec.revisionHistoryLimit) so that kubectl rollout undo can roll back to a previous ReplicaSet. Option A is incorrect because stateful workloads requiring stable identities and persistent per-pod storage are handled by StatefulSets, not Deployments.

Option C is incorrect because pod IP addresses are a function of the cluster network (e.g., CNI-assigned IPs) and are not a Deployment-specific benefit; direct pod access is generally discouraged in favor of Services. Option E is incorrect because running one pod on every node is the purpose of a DaemonSet, not a Deployment.

Exam trap

A common misconception is that Deployments are suitable for stateful workloads or provide direct pod networking, when in fact StatefulSets and Services are the correct solutions for those needs.

Practice this question →

153

MCQeasy

What is the primary purpose of a liveness probe in a container?

A.To check resource usage like CPU and memory

B.To check if the container is still alive; restart if not

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

D.To check if the pod is scheduled on the correct node

AnswerB

A liveness probe periodically tests whether the container process is still responsive; on failure, kubelet restarts the container according to its restart policy. This directly matches the stem's requirement to detect a dead container and restart it.

Why this answer

The primary purpose of a liveness probe is to determine whether a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it according to the pod's restart policy, ensuring self-healing. This is distinct from readiness probes, which control traffic routing, and resource checks, which are handled by metrics servers or cAdvisor.

Exam trap

The trap here is that candidates confuse liveness probes with readiness probes, often selecting option C because both involve health checks, but liveness probes manage container lifecycle while readiness probes manage traffic routing.

How to eliminate wrong answers

Option A is wrong because checking resource usage like CPU and memory is the job of the metrics server or cAdvisor, not a liveness probe; liveness probes only test application responsiveness via HTTP, TCP, or exec commands. Option C is wrong because checking if the container is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod is added to Service endpoints; a liveness probe does not affect traffic routing. Option D is wrong because checking if the pod is scheduled on the correct node is handled by the Kubernetes scheduler and node affinity rules, not by a liveness probe, which operates at the container level within an already-scheduled pod.

Practice this question →

154

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Deployment

B.Container

C.Node

D.Pod

AnswerD

A Pod is the smallest deployable unit in Kubernetes, encapsulating one or more containers that share network and storage namespaces. Containers themselves are not scheduled directly; the scheduler places Pods onto nodes, making them the atomic unit of deployment.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. Deployments manage ReplicaSets, which in turn manage Pods, but the Pod itself is the atomic deployable unit.

Exam trap

The trap here is that candidates often confuse 'container' as the smallest unit because of Docker's standalone container model, but Kubernetes abstracts containers into Pods to enforce co-location and resource sharing.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, not the smallest deployable unit. Option B is wrong because a Container is not a Kubernetes object; it is a runtime instance of a container image that runs inside a Pod. Option C is wrong because a Node is a worker machine in the cluster that hosts Pods, not a deployable unit.

Practice this question →

155

MCQeasy

A user wants to run a one-time batch task that processes a dataset and then exits. The task should not be restarted if it completes successfully. Which Kubernetes resource is most appropriate?

A.Job

B.Deployment

C.StatefulSet

D.DaemonSet

AnswerA

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is intended for batch tasks that run to completion. By default, a Job does not restart the Pod if it exits successfully, making it the correct choice for a one-time dataset processing task.

Why this answer

A Job is the Kubernetes resource designed for batch workloads that run to completion. It tracks successful Pod completions and does not restart Pods that exit with success. Deployments, StatefulSets, and DaemonSets are all intended for long-running services and do not provide the same completion guarantees.

Exam trap

The trap here is assuming that any workload controller can run a batch task, but only a Job provides run-to-completion semantics without restarting on success.

Practice this question →

156

MCQmedium

You need to run a batch job that processes a queue and then terminates. Which Kubernetes resource is most appropriate?

A.StatefulSet

B.Job

C.Deployment

D.DaemonSet

AnswerB

A Job runs Pods to successful completion rather than continuously, which suits a queue-processing task that must terminate. Unlike a Deployment, which restarts Pods indefinitely to maintain availability, the Job controller tracks completion and stops once the work finishes.

Why this answer

A Job is the correct resource because it is designed to run a specified number of pods to completion and then terminate, making it ideal for batch processing tasks like processing a queue. Unlike controllers that maintain a desired state indefinitely, a Job ensures the pod runs successfully to completion, even if the pod fails and needs to be restarted, and then stops.

Exam trap

CNCF often tests the distinction between controllers that maintain a desired state (Deployment, StatefulSet, DaemonSet) versus controllers that run to completion (Job), and the trap here is assuming that any workload that processes data must use a Deployment because it's the most common controller.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identifiers and persistent storage, not for batch jobs that terminate. Option C is wrong because a Deployment is designed to maintain a desired number of replica pods running continuously, not to run a task to completion and then stop. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for one-off batch processing.

Practice this question →

157

MCQeasy

A DevOps engineer needs to expose a set of pods running an HTTP API to external clients. The pods are stateless and should be load-balanced. Which Kubernetes resource should they use?

A.StatefulSet with a headless Service

B.Ingress resource without a Service

C.Service of type ClusterIP

D.Service of type LoadBalancer

AnswerD

A Service of type LoadBalancer provisions an external load balancer that distributes traffic across the stateless pod endpoints, exposing the HTTP API to external clients. ClusterIP is internal only, and NodePort lacks integrated load balancing.

Why this answer

A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

Exam trap

The trap here is that candidates often confuse 'exposing to external clients' with internal-only services, leading them to pick ClusterIP (C) or assume Ingress (B) can work without a Service, while the question explicitly requires load balancing for stateless pods, making LoadBalancer the direct and correct answer.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is designed for stateful applications (e.g., databases) that require stable network identities and persistent storage, not for stateless HTTP APIs, and a headless Service does not provide load balancing or external exposure. Option B is wrong because an Ingress resource cannot function without a backing Service; it requires a Service (typically of type NodePort or LoadBalancer) to route traffic to pods, and it does not itself expose pods directly. Option C is wrong because a Service of type ClusterIP is only reachable within the cluster's internal network (e.g., via cluster IP 10.0.0.1) and cannot be accessed by external clients without additional components like a proxy or Ingress.

Practice this question →

158

MCQmedium

A cluster administrator needs to ensure that a logging agent runs on every node in the cluster, including nodes added in the future. The agent should collect logs from each node and forward them to a central system. Which Kubernetes resource should be used?

A.Job

B.DaemonSet

C.Deployment

D.StatefulSet

AnswerB

DaemonSet ensures that a copy of a pod runs on all (or selected) nodes. When new nodes are added to the cluster, the DaemonSet controller automatically schedules a pod on them. This is ideal for node-level services like log collectors, monitoring agents, or network plugins. It directly meets the requirement of running a logging agent on every node, including future ones, without manual intervention.

Why this answer

DaemonSet is specifically designed to run a pod on each node, automatically handling new nodes as they join. This makes it the correct choice for node-level agents like log collectors. Deployments, StatefulSets, and Jobs do not provide this per-node guarantee; they manage replicas or batch tasks without ensuring coverage of every node.

Exam trap

The trap here is thinking that a Deployment with many replicas can cover all nodes, but it lacks the automatic per-node scheduling that DaemonSet provides.

Practice this question →

159

MCQhard

A pod remains in 'Pending' state. Upon inspecting the pod with 'kubectl describe pod', you see the message '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate'. What is the most likely cause?

A.The pod is not using a ServiceAccount

B.The node has a disk pressure condition and the pod lacks a toleration

C.The pod's resource requests exceed the node's capacity

D.The pod's container image does not exist

AnswerB

The scheduler's message names the taint node.kubernetes.io/disk-pressure, meaning the node reports disk pressure. Because the pod defines no matching toleration, the scheduler refuses to bind it, leaving it Pending. This matches the stem's constraint exactly.

Why this answer

The message '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/disk-pressure: }, that the pod didn't tolerate' indicates the node has a taint of 'disk-pressure' which prevents pod scheduling unless the pod has a matching toleration. Since the pod lacks this toleration, it remains in 'Pending' state. Option B correctly identifies the node's disk pressure condition and the missing toleration as the cause.

Exam trap

In the KCNA exam, it's important to distinguish between taint/toleration errors and resource insufficiency errors. Candidates often mistakenly choose 'resource requests exceed capacity' when the message explicitly mentions a taint, not resource limits.

How to eliminate wrong answers

Option A is wrong because a missing ServiceAccount does not cause a 'Pending' state with a taint-based scheduling failure; it would cause authentication issues at runtime, not scheduling. Option C is wrong because resource requests exceeding node capacity would produce a different message, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option D is wrong because a non-existent container image would cause an 'ImagePullBackOff' or 'ErrImagePull' error, not a 'Pending' state with a taint message.

Practice this question →

160

MCQmedium

A team observes that a Pod is stuck in CrashLoopBackOff. The Pod runs a single container with an entrypoint that exits with non-zero code after a few seconds. The team wants to inspect the container's logs to understand why it is crashing. Which command should they use?

A.kubectl get pods

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

C.kubectl describe pod <pod-name>

D.kubectl exec -it <pod-name> -- sh

AnswerB

Because the container exits with a non-zero code, the current instance has already terminated, so its live logs are unavailable. The --previous flag retrieves logs from the prior container instance, exposing the crash output needed to diagnose the CrashLoopBackOff.

Why this answer

The `kubectl logs <pod-name> --previous` command retrieves the logs from the previous instance of a crashed container. Since the Pod is in CrashLoopBackOff, the current container has already exited, and the `--previous` flag accesses the logs of the last terminated container, which contains the crash output (e.g., the non-zero exit code and error messages). This is the direct way to see why the entrypoint failed.

Exam trap

CNCF often tests the distinction between `kubectl logs` (which shows container output) and `kubectl describe pod` (which shows events and status), leading candidates to choose describe when they need actual log content.

How to eliminate wrong answers

Option A is wrong because `kubectl get pods` only lists the Pods and their statuses (e.g., CrashLoopBackOff), but does not provide any logs or crash details. Option C is wrong because `kubectl describe pod <pod-name>` shows the Pod's metadata, events, and container status (including restart count and last exit code), but it does not show the container's stdout/stderr logs, which are needed to understand the crash reason. Option D is wrong because `kubectl exec -it <pod-name> -- sh` attempts to open a shell in a running container, but the container is crashing and not running, so the exec command will fail with an error like 'cannot exec into a container in a crashed state'.

Practice this question →

161

MCQhard

An application requires that configuration data be mounted as a file inside the container. The data may change at runtime, and the application should automatically read the updated values without restarting. Which approach should be used?

A.Store the configuration in a Secret and mount it using subPath

B.Use a ConfigMap mounted as a volume without subPath

C.Use a PersistentVolumeClaim to store the configuration

D.Store the configuration in an environment variable from a ConfigMap

AnswerB

A ConfigMap mounted as a volume without subPath is updated in place when the ConfigMap changes, and kubelet syncs the projected files periodically. The application reads the mounted file and picks up new values without a restart, meeting the runtime-update constraint.

Why this answer

Mounting a ConfigMap as a volume (without subPath) creates a symlink-based mount that automatically updates when the ConfigMap changes. The kubelet periodically syncs the ConfigMap data and updates the symlinks, allowing the application to read the new values without a restart. This satisfies the requirement for runtime configuration updates without container restart.

Exam trap

A common trap is the misconception that subPath mounts support live updates, when in fact they create a static file binding that prevents automatic propagation of ConfigMap changes.

How to eliminate wrong answers

Option A is wrong because using subPath creates a direct file mount that does not support automatic updates; the file content is fixed at mount time and requires a pod restart to reflect changes. Option C is wrong because a PersistentVolumeClaim is used for persistent storage, not for configuration data that needs to be updated at runtime, and it does not provide automatic update capabilities. Option D is wrong because environment variables from a ConfigMap are injected at container startup and cannot be updated at runtime without restarting the container.

Practice this question →

162

MCQeasy

Which Kubernetes component is responsible for maintaining the desired state of the cluster by running controllers?

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerC

The kube-controller-manager runs the built-in control loops that continuously reconcile observed cluster state with the desired state declared in objects, satisfying the stem's requirement for a component that maintains desired state through controllers. It hosts controllers such as Deployment, ReplicaSet and Node, unlike the API server, which only stores state.

Why this answer

The kube-controller-manager is the component that runs controller processes, which are control loops that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. It bundles together controllers such as the Node Controller, Replication Controller, and Endpoint Controller, each responsible for specific aspects of cluster state management.

Exam trap

CNCF often tests the misconception that the kube-apiserver is responsible for maintaining desired state because it is the central API gateway, but the actual enforcement is done by controllers within the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handling authentication, authorization, and validation of API requests, but it does not run controllers to maintain desired state. Option B is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource requirements and constraints, not for running controllers that maintain cluster state. Option D is wrong because etcd is a distributed key-value store that serves as Kubernetes' backing store for all cluster data, but it does not execute controller logic or enforce desired state.

Practice this question →

163

Multi-Selecteasy

Which TWO components are part of the Kubernetes worker node?

Select 2 answers

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-proxy

E.kubelet

AnswersD, E

Kube-proxy runs on every worker node, maintaining network rules that implement Kubernetes Service abstraction, enabling pod-to-pod and external traffic routing. It satisfies the worker node component requirement directly, alongside kubelet and the container runtime, distinguishing node-level networking from control plane functions such as scheduling.

Why this answer

kube-proxy (D) is a worker-node component that maintains network rules on each node to implement the Kubernetes Service abstraction, handling traffic forwarding via iptables/IPVS so Pods can reach Services. kubelet (E) is the primary node agent that runs on every worker node, registering the node with the control plane and managing Pod lifecycle by communicating with the container runtime via CRI. The other options belong to the control plane, not worker nodes: kube-apiserver (A) exposes the Kubernetes REST API and is the front end of the control plane, etcd (B) is the distributed key-value store holding cluster state, and kube-scheduler (C) assigns Pods to nodes from the control plane.

Exam trap

In the CNCF Kubernetes exam (e.g., KCNA), the distinction between control-plane and worker-node components is often tested. Candidates may confuse kube-scheduler or kube-apiserver as worker-node components because they are essential to cluster operation but run only on the control plane.

Practice this question →

164

Multi-Selectmedium

A platform engineer is troubleshooting a Pod that is stuck in Pending. The engineer suspects the scheduler cannot place it. Which two commands are appropriate to gather evidence about why the Pod has not been scheduled? (Choose two.)

Select 2 answers

A.`kubectl delete pod <pod-name> --force --grace-period=0` to trigger rescheduling and observe the outcome.

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

C.`kubectl describe pod <pod-name>` to inspect Events for FailedScheduling messages.

D.`kubectl exec -it <pod-name> -- /bin/sh` to inspect the container's runtime logs.

E.`kubectl logs <pod-name> --previous` to view logs from the prior container instance.

AnswersB, C

Filtering events by the involved object name narrows the event stream to messages about that Pod, including scheduler warnings. It complements kubectl describe by showing timestamped events across the namespace, which helps confirm whether the failure is persistent or intermittent. This is a valid, non-destructive way to collect scheduling evidence.

Why this answer

The scheduler reports its reasoning through Events, so inspecting kubectl describe pod output and filtering cluster events for the Pod both expose FailedScheduling causes like insufficient resources, taints, or affinity mismatches. Commands that require a running container, rely on previous logs, or delete the Pod do not reveal why scheduling failed and are unsuitable for this diagnosis.

Exam trap

The trap here is reaching for exec or logs on a Pending Pod, when no container has started to produce them.

Practice this question →

165

Multi-Selectmedium

A developer is troubleshooting a Pod that remains in the Pending state and never gets scheduled. The developer suspects the issue is related to node selection constraints. Which two kubectl commands can help identify why the Pod cannot be scheduled? (Choose two.)

Select 2 answers

A.kubectl logs <pod-name>

B.kubectl describe pod <pod-name>

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

D.kubectl get events --field-selector involvedObject.name=<pod-name>

E.kubectl top pod <pod-name>

AnswersB, D

kubectl describe pod shows the Pod's status conditions and recent Events, including scheduler messages such as '0/3 nodes are available: 3 node(s) didn't match node selector' or insufficient resources. These Events directly reveal why the scheduler could not place the Pod, making describe the most direct diagnostic for a Pending Pod with a node selection issue.

Why this answer

A Pending Pod has not been scheduled, so diagnostics must come from the control plane rather than the container. kubectl describe pod surfaces scheduler Events and status conditions, and kubectl get events filtered by the Pod name provides the same FailedScheduling reasons in a focused list. Commands that require a running container or metrics pipeline cannot function before scheduling occurs.

Exam trap

The trap here is reaching for logs or exec to debug a Pending Pod, when no container has started and only control-plane events can reveal the scheduling failure.

Practice this question →

166

MCQeasy

Which command creates a Deployment named 'nginx' from the 'nginx:1.19' image?

A.kubectl run nginx --image=nginx:1.19

B.kubectl create deployment nginx --image=nginx:1.19

C.kubectl start deployment nginx --image=nginx:1.19

D.kubectl apply -f nginx-deployment.yaml

AnswerB

This imperative command creates a Deployment object named nginx and sets its pod template container image to nginx:1.19 via the --image flag, satisfying both the name and image constraints in the stem without requiring a YAML manifest.

Why this answer

The `kubectl create deployment` command is the standard Kubernetes imperative method to create a Deployment resource, and specifying `--image=nginx:1.19` directly sets the container image for the pod template. This command generates a Deployment object that manages a ReplicaSet with the specified image, ensuring declarative updates and rollback capabilities.

Exam trap

The trap here is that candidates confuse `kubectl run` (which creates a Pod, not a Deployment) with `kubectl create deployment`, especially since older versions of `kubectl run` could create Deployments, but the current behavior defaults to Pod creation unless the `--generator` flag is used.

How to eliminate wrong answers

Option A is wrong because `kubectl run` creates a standalone Pod (or in newer versions a Deployment with `--generator=deployment/v1beta1` deprecated), not a Deployment resource; it does not provide the same lifecycle management, scaling, or rolling update features as a Deployment. Option C is wrong because `kubectl start deployment` is not a valid kubectl command; the correct imperative verb is `create`, not `start`. Option D is wrong because while `kubectl apply -f nginx-deployment.yaml` can create a Deployment, it requires a pre-existing YAML manifest file, not a direct image specification, and the question asks for the command that creates a Deployment from the image directly.

Practice this question →

167

MCQmedium

You want to isolate a team's workloads within a Kubernetes cluster so that they cannot see or access resources from other teams. Which feature should you use?

A.Annotations

B.Labels and selectors

C.Resource quotas

D.Namespaces

AnswerD

Namespaces partition a single cluster into logically isolated virtual clusters, scoping namespaced resources and their names so a team's workloads cannot see or access another team's objects. This satisfies the stem's isolation requirement without provisioning separate clusters, though network policies are still needed to restrict cross-namespace traffic.

Why this answer

Namespaces are the Kubernetes abstraction that provides a logical partition of the cluster, enabling multi-tenancy by isolating workloads, resources, and access controls. By default, RBAC policies and network policies can be scoped to a namespace, preventing teams from seeing or accessing resources in other namespaces.

Exam trap

The trap is that candidates confuse labels/selectors (which are for organization and routing within the same namespace) with namespaces (which provide true isolation and multi-tenancy across the cluster). This leads them to select Option B, thinking selectors control visibility, but they only filter resources within a namespace.

How to eliminate wrong answers

Option A is wrong because annotations are key-value metadata attached to objects for non-identifying information (e.g., build versions, contact info) and do not provide any isolation or access control. Option B is wrong because labels and selectors are used for grouping and selecting objects (e.g., for services to target pods), but they do not enforce boundaries or prevent cross-team visibility. Option C is wrong because resource quotas limit aggregate resource consumption (CPU, memory, etc.) within a namespace but do not isolate workloads or restrict access to resources from other teams.

Practice this question →

168

Multi-Selectmedium

Which two of the following are valid ways to set resource constraints on a container in a Pod spec?

Select 2 answers

A.Specify 'resources.guarantees.cpu' for CPU guarantees

B.Specify 'resources.limits.memory' for maximum memory

C.Specify 'resources.min.memory' for minimum memory

D.Specify 'resources.requests.cpu' for minimum CPU

E.Specify 'resources.max.cpu' for CPU limits

AnswersB, D

Setting `resources.limits.memory` in a container's spec caps the memory the container may consume, so the kubelet enforces the limit and the container is OOM-killed if it exceeds it. This directly satisfies the stem's requirement for a valid resource constraint mechanism within the Pod spec.

Why this answer

Option B is correct because the Pod spec's container definition uses the 'resources.limits' field to declare the maximum amount of a resource the container may consume, so 'resources.limits.memory' sets a hard memory ceiling that the container cannot exceed. Option D is correct because 'resources.requests.cpu' declares the minimum CPU the container is guaranteed for scheduling purposes, and the kubelet uses this value when allocating CPU shares. The other options are invalid field names: 'resources.guarantees.cpu' (A), 'resources.min.memory' (C), and 'resources.max.cpu' (E) do not exist in the Kubernetes API, which only supports 'requests' and 'limits' under 'resources'.

Exam trap

The trap here is that candidates confuse the naming convention of Kubernetes resource fields (e.g., 'limits' vs 'max', 'requests' vs 'min' or 'guarantees'), leading them to choose plausible-sounding but non-existent keys like 'resources.max.cpu' or 'resources.guarantees.cpu'.

Practice this question →

169

MCQmedium

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

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerC

ConfigMaps hold non-confidential key-value configuration data, decoupling it from pod images so containers can consume it via environment variables, command-line arguments, or mounted volumes. This directly satisfies the stem's requirement for storing non-confidential configuration data consumable by pods, unlike Secrets, which are intended for sensitive data.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-confidential configuration data, such as environment variables, command-line arguments, or configuration files, that can be consumed by pods. Unlike Secrets, ConfigMaps store data in plain text and are designed for configuration that does not require encryption, making them ideal for application settings that are not sensitive.

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, where candidates mistakenly choose Secrets for all configuration data, forgetting that Secrets are intended only for sensitive information and ConfigMaps are the correct choice for non-confidential data.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API server, not for storing configuration data. Option B is wrong because a Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not for non-confidential configuration. Option D is wrong because a PersistentVolume is a storage resource abstraction that provides persistent storage to pods, not a mechanism for injecting configuration data.

Practice this question →

170

MCQeasy

Which Kubernetes resource provides a stable IP address and DNS name to access a set of pods?

A.Ingress

B.EndpointSlice

C.Service

D.NetworkPolicy

AnswerC

A Service assigns a stable virtual IP and DNS name, load-balancing traffic to a dynamic set of pods selected by labels. It satisfies the stem's requirement for stable IP and DNS access to a pod set, unlike ephemeral pod IPs.

Why this answer

A Kubernetes Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as the underlying pods are created, destroyed, or scaled. This abstraction allows clients to reliably reach a set of pods without needing to track individual pod IPs, which are ephemeral. Services use label selectors to dynamically route traffic to matching pods, ensuring high availability and load balancing.

Exam trap

The trap here is that candidates often confuse Ingress (which provides external access) with the internal stable IP/DNS abstraction provided by a Service, or they mistakenly think EndpointSlice (a newer, more scalable replacement for Endpoints) is the resource that offers a stable network identity.

How to eliminate wrong answers

Option A is wrong because Ingress is not a stable IP/DNS resource for pods; it is an API object that manages external HTTP/HTTPS access to Services, typically providing host-based or path-based routing and TLS termination, but it does not itself assign a stable IP or DNS name to a set of pods. Option B is wrong because EndpointSlice is not a stable IP/DNS resource; it is a lower-level object that tracks the actual IP addresses and ports of pods matching a Service's selector, used for scalability and efficiency, but it does not provide a stable endpoint for clients. Option D is wrong because NetworkPolicy is a security resource that controls traffic flow at the IP address or port level (OSI layer 3 or 4) using pod selectors and namespace selectors; it does not provide any IP address or DNS name for accessing pods.

Practice this question →

171

MCQeasy

What is the smallest deployable unit in Kubernetes that you can create and manage?

A.Service

B.Container

C.Pod

D.Deployment

AnswerC

A Pod is the smallest deployable unit Kubernetes creates and manages, wrapping one or more containers that share network and storage. Controllers such as Deployments and ReplicaSets manage Pods rather than replacing them as the atomic unit.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model that you can create and deploy. It represents a single instance of a running process in your cluster and encapsulates one or more containers with shared storage and network resources. While containers are the actual runtime environments, Kubernetes does not manage containers directly; it manages Pods, which are the atomic unit of scheduling and lifecycle management.

Exam trap

The trap here is that candidates confuse the container (the runtime technology) with the Pod (the Kubernetes API object), leading them to select 'Container' because they think of Docker containers as the smallest unit, but Kubernetes abstracts containers into Pods as the atomic deployable unit.

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; it is not a deployable unit but rather a networking resource that sits on top of Pods. Option B is wrong because a Container is not a Kubernetes API object; Kubernetes manages containers only within the context of a Pod, and you cannot create or manage a standalone container via the Kubernetes API. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods; it is not the smallest deployable unit but rather a declarative way to manage Pod scaling and updates.

Practice this question →

172

MCQeasy

Which component runs on every worker node and is responsible for ensuring that containers are running in a pod as specified in the PodSpec?

A.container runtime

B.kube-proxy

C.kubelet

D.kube-scheduler

AnswerC

The kubelet is the primary node agent that runs on every worker node, directly satisfying the stem’s constraint of ensuring containers run per the PodSpec. It achieves this by continuously polling the API server for assigned Pods, then using the container runtime (e.g., containerd) to create, start, and restart containers based on the PodSpec’s declared state, thereby enforcing the desired container lifecycle.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It is responsible for ensuring that containers described in a PodSpec are running and healthy, by interacting with the container runtime (e.g., containerd, CRI-O) to create, start, and monitor pods. The kubelet does not manage containers that were not created by Kubernetes.

Exam trap

The trap here is that candidates confuse the kubelet with the container runtime, assuming the runtime itself reads PodSpecs, when in fact the kubelet is the orchestrator that translates PodSpecs into runtime actions via the CRI.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it does not interpret PodSpecs or enforce desired state — it only executes container lifecycle operations when instructed by the kubelet. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling service-to-pod traffic routing via iptables or IPVS rules, and has no role in container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not run on worker nodes and does not manage running containers.

Practice this question →

173

MCQhard

A cluster administrator notices that a Deployment's pods are not receiving traffic as expected. The Service selector matches the pod labels. What is a possible cause?

A.The pods have a liveness probe that fails

B.The Deployment replicas are set to zero

C.The pods have a failing readiness probe

D.The Service type is NodePort

AnswerC

A failing readiness probe removes the pod from the Service's endpoint list, so kube-proxy stops forwarding traffic to it even though the selector matches. This mechanism explains why matching pods receive no traffic, satisfying the stem's scenario of unexpected traffic loss.

Why this answer

A failing readiness probe removes the pod's endpoint from the Service's EndpointSlice, so the Service stops routing traffic to that pod even though the pod is running and its labels match the Service selector. This is the most direct reason why a Deployment's pods would not receive traffic despite correct label matching.

Exam trap

The exam often tests the distinction between liveness and readiness probes, trapping candidates who confuse a liveness probe failure (which restarts the pod) with a readiness probe failure (which removes the pod from the Service's endpoint list).

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the kubelet to restart the pod, but it does not directly prevent the Service from routing traffic to the pod while it is still running; traffic can still reach a pod with a failing liveness probe until it is terminated. Option B is wrong because if Deployment replicas are set to zero, there are no pods to receive traffic at all, but the question states the pods are not receiving traffic as expected, implying pods exist but traffic is not reaching them. Option D is wrong because a NodePort Service type does not inherently block traffic; it simply exposes the Service on a static port on each node's IP, and traffic can still reach pods as long as the selector matches.

Practice this question →

174

MCQmedium

Which of the following is a correct apiVersion for a Deployment in a modern Kubernetes cluster (v1.19+)?

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta1

AnswerC

apps/v1 is the correct apiVersion for Deployments from Kubernetes v1.9 onward, satisfying the stem's v1.19+ constraint. The older extensions/v1beta1 and apps/v1beta1 versions were removed, so manifests using them are rejected by the API server in modern clusters.

Why this answer

`apps/v1` is the stable API version for Deployments in Kubernetes v1.19+, replacing the deprecated `extensions/v1beta1` and `apps/v1beta1` versions. The `apps/v1` API group provides the full set of features for Deployments, including rolling updates, rollbacks, and scaling, and is required for production clusters running v1.19 or later.

Exam trap

The trap here is that candidates may confuse the core `v1` API group (used for Pods) with the `apps/v1` group required for Deployments, or mistakenly think that beta versions like `apps/v1beta1` are still valid in modern clusters.

How to eliminate wrong answers

Option A is wrong because `extensions/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; it is not a valid apiVersion for Deployments in a modern cluster (v1.19+). Option B is wrong because `v1` is the core API group used for resources like Pods, Services, and ConfigMaps, but Deployments belong to the `apps` API group, not the core group. Option D is wrong because `apps/v1beta1` was deprecated in Kubernetes v1.16 and removed in v1.22; the stable `apps/v1` is the only correct version for Deployments in v1.19+.

Practice this question →

175

MCQhard

A developer created a Deployment with 5 replicas. After applying the manifest, only 3 pods are Running; the other 2 are Pending. Which is the MOST likely cause?

A.The readiness probe is failing

B.A NetworkPolicy is blocking traffic to the pods

C.The container image is misspelled

D.The nodes do not have enough available CPU or memory to schedule the additional pods

AnswerD

Pending means the scheduler cannot bind the pods to any node. Insufficient allocatable CPU or memory leaves no node satisfying the pod's resource requests, so the remaining two replicas stay unscheduled while three already-placed pods run.

Why this answer

D is correct because when a Pod remains in Pending state, it indicates that the scheduler cannot find a node that satisfies the Pod's resource requests. Since 3 Pods are already running and consuming resources, the remaining 2 Pods cannot be placed if the cluster's nodes lack sufficient allocatable CPU or memory. This is a classic resource-constrained scheduling failure, not a runtime or network issue.

Exam trap

The exam often tests the distinction between Pod lifecycle phases (Pending, Running, Failed) and readiness/liveness probes; the trap here is confusing a scheduling failure (Pending) with a runtime failure (CrashLoopBackOff) or network restriction (NetworkPolicy).

How to eliminate wrong answers

Option A is wrong because a failing readiness probe would cause the Pod to be in Running state but not Ready, not Pending; readiness probes affect service endpoints, not scheduling. Option B is wrong because a NetworkPolicy only controls ingress/egress traffic to Pods that are already running, it does not prevent Pods from being scheduled or starting. Option C is wrong because a misspelled container image would cause an ImagePullBackOff or ErrImagePull error, resulting in a CrashLoopBackOff or waiting state, not a Pending state; Pending means the Pod has not been assigned to a node yet.

Practice this question →

176

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster by running controller loops?

A.etcd

B.kube-apiserver

C.kube-controller-manager

D.kube-scheduler

AnswerC

The kube-controller-manager runs the built-in controller loops — ReplicaSet, Deployment, Node and others — that continuously reconcile observed cluster state against the desired state declared in the API server, which is exactly the maintenance role the stem asks for.

Why this answer

The kube-controller-manager is the control plane component that runs controller loops, which are continuous processes that watch the shared state of the cluster through the kube-apiserver and make changes to drive the current state toward the desired state. Each controller (e.g., ReplicaSet, Node, Deployment) is a separate loop that handles a specific aspect of cluster management, ensuring that the actual cluster state matches the desired configuration defined in the API objects.

Exam trap

CNCF often tests the misconception that the kube-apiserver handles all cluster logic, but the trap here is that the kube-apiserver only exposes the API and validates requests, while the actual reconciliation loops that enforce desired state are run exclusively by the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds all cluster data, but it does not run controller loops or enforce desired state; it is a passive storage backend. Option B is wrong because kube-apiserver is the front-end for the Kubernetes API that validates and processes RESTful requests, but it does not execute controller reconciliation logic; it serves as the communication gateway. Option D is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for maintaining the overall desired state of the cluster via controller loops.

Practice this question →

177

MCQhard

You want to run a batch job that processes a queue and then terminates. Which Kubernetes resource should you use?

A.Job

B.Deployment

C.CronJob

D.DaemonSet

AnswerA

A Job creates Pods that run to completion, tracking successful completions and retrying failures until the specified count is reached. This satisfies the stem's requirement for a batch workload that processes a queue and then terminates, unlike a Deployment, which maintains continuously running Pods.

Why this answer

A Kubernetes Job is designed for batch processing tasks that run to completion and then terminate. It creates one or more Pods and ensures they successfully finish executing a specific workload, making it the correct choice for processing a queue and then exiting.

Exam trap

The CNCF exam often tests the distinction between one-time batch processing (Job) and scheduled tasks (CronJob), leading candidates to mistakenly choose CronJob when the question specifies a single run that terminates.

How to eliminate wrong answers

Option B is wrong because a Deployment is intended for long-running, stateless applications that should run continuously, not for batch jobs that terminate after completion. Option C is wrong because a CronJob is used for scheduling recurring tasks at specified times, not for a one-time batch job that runs and stops. Option D is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset) in the cluster, typically for cluster-wide services like logging or monitoring, not for a terminating batch job.

Practice this question →

178

MCQmedium

You notice that a pod is in 'Pending' state for a long time. Which of the following is the most likely cause?

A.The pod's liveness probe is failing.

B.No node has enough CPU or memory to meet the pod's requests.

C.The pod's readiness probe is not configured.

D.The container image does not exist.

AnswerB

The scheduler leaves a pod Pending when no node satisfies its resource requests, since insufficient allocatable CPU or memory prevents binding. Image pull failures or crash loops instead produce ErrImagePull or CrashLoopBackOff, so resource shortfall is the likely cause.

Why this answer

A pod remains in 'Pending' state when the scheduler cannot find a node that satisfies its resource requests. The most common reason is insufficient CPU or memory capacity across all available nodes, preventing the pod from being bound to a node. Unlike probe failures or missing images, which cause 'Running' or 'ImagePullBackOff' states, resource constraints block scheduling entirely.

Exam trap

A common exam trap is confusing scheduling failures (Pending) with runtime failures (CrashLoopBackOff, ImagePullBackOff). Candidates often mistake probe or image issues as causes of the Pending state, but these occur after the pod is scheduled.

How to eliminate wrong answers

Option A is wrong because a failing liveness probe causes the pod to be restarted or enter 'CrashLoopBackOff', not remain in 'Pending' — liveness probes only run after the pod is scheduled and containers start. Option C is wrong because a missing readiness probe does not affect scheduling; it only controls whether the pod receives traffic via Services, and the pod can still be 'Running'. Option D is wrong because a non-existent container image results in 'ImagePullBackOff' or 'ErrImagePull' states, not 'Pending' — the pod must first be scheduled to a node before the kubelet attempts to pull the image.

Practice this question →

179

MCQeasy

What is the primary purpose of the kube-scheduler in a Kubernetes cluster?

A.Assigning pods to nodes

B.Running container runtime operations

C.Storing the cluster state

D.Exposing the Kubernetes API

AnswerA

The kube-scheduler watches for newly created Pods with no assigned node and selects a suitable node based on resource requests, affinity rules and taints. This satisfies the stem's requirement for the component whose primary purpose is assigning Pods to nodes.

Why this answer

The kube-scheduler is the Kubernetes control plane component responsible for selecting an optimal node for newly created pods that have not yet been assigned to a node. It evaluates constraints such as resource requirements, affinity/anti-affinity rules, and data locality, then binds the pod to the chosen node via the Kubernetes API. This makes assigning pods to nodes its primary and defining purpose.

Exam trap

The exam often tests the distinction between control plane components, so the trap here is confusing the kube-scheduler's role with the kubelet's execution role or the API server's exposure role, leading candidates to pick 'Running container runtime operations' or 'Exposing the Kubernetes API'.

How to eliminate wrong answers

Option B is wrong because running container runtime operations (e.g., pulling images, starting containers) is the responsibility of the kubelet on each node, not the kube-scheduler. Option C is wrong because storing the cluster state is the function of etcd, a distributed key-value store, not the kube-scheduler. Option D is wrong because exposing the Kubernetes API is the role of the kube-apiserver, which is the front-end for the control plane; the scheduler only interacts with the API server to watch for unscheduled pods and update pod bindings.

Practice this question →

180

MCQhard

An application requires that a set of Pods each be assigned a unique DNS name that can be used for peer-to-peer communication. Which Kubernetes resource should be used?

A.Job with a Service

B.DaemonSet with a Service

C.StatefulSet with a Headless Service

D.Deployment with a Service

AnswerC

A StatefulSet with a Headless Service satisfies the unique DNS requirement: each Pod receives a stable, ordinal hostname such as pod-0.service.namespace.svc.cluster.local, resolved directly to the Pod IP rather than a load-balanced ClusterIP. This stable per-Pod identity enables direct peer-to-peer communication, which a Deployment behind a normal Service cannot provide.

Why this answer

A StatefulSet with a Headless Service is correct because StatefulSets assign each Pod a stable, unique network identity (e.g., pod-name-0.service-name.namespace.svc.cluster.local) that persists across rescheduling. A Headless Service (clusterIP: None) disables load balancing and DNS round-robin, allowing direct DNS resolution to individual Pod IPs for peer-to-peer communication. This matches the requirement for unique DNS names for each Pod.

Exam trap

The trap here is that candidates often assume any Service provides unique DNS names, but only a Headless Service combined with a StatefulSet yields per-Pod DNS entries; a regular Service (ClusterIP or NodePort) always load-balances to a single virtual IP.

How to eliminate wrong answers

Option A is wrong because a Job is designed for batch processing tasks that run to completion, not for long-running Pods requiring stable DNS identities; a Service with a Job would still use a regular ClusterIP, which load-balances across Pods and does not provide unique per-Pod DNS names. Option B is wrong because a DaemonSet ensures one Pod per Node but does not guarantee stable, unique DNS names for each Pod; combined with a regular Service, DNS resolves to the Service IP, not individual Pods. Option D is wrong because a Deployment creates identical, interchangeable Pods with no stable identity; a regular Service provides a single DNS name that load-balances across all Pods, not unique per-Pod DNS names.

Practice this question →

181

MCQeasy

Which Kubernetes object provides a stable IP address and DNS name for a set of Pods?

A.Ingress

B.ConfigMap

C.Service

D.Deployment

AnswerC

A Service fronts a set of Pods behind a single virtual IP and DNS name, so clients reach a stable endpoint even as individual Pods are replaced. This satisfies the stem's requirement for a stable IP address and DNS name, unlike Pod IPs, which change on recreation.

Why this answer

A Service provides a stable virtual IP address and a DNS name (e.g., my-svc.namespace.svc.cluster.local) that remains constant even as Pods are created or destroyed. This enables reliable network access to a dynamic set of Pods selected via labels, abstracting away Pod IP volatility.

Exam trap

CNCF often tests the misconception that a Deployment provides a stable network identity, when in fact it only manages Pod replicas and their lifecycle, while the Service object is solely responsible for stable IP/DNS abstraction.

How to eliminate wrong answers

Option A is wrong because an Ingress is not an IP/DNS provider for Pods; it is an API object that manages external HTTP/HTTPS routing to Services, typically using a load balancer or reverse proxy, and does not assign a stable IP to Pods directly. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs or files, and it has no networking or IP assignment functionality. Option D is wrong because a Deployment manages the desired state and lifecycle of Pods (e.g., scaling, rolling updates) but does not provide a stable network endpoint; Pods created by a Deployment receive ephemeral IPs that change on restart.

Practice this question →

182

Multi-Selecthard

Which two scenarios would benefit from using a StatefulSet instead of a Deployment? (Choose two.)

Select 2 answers

A.An application that requires persistent storage unique to each instance

B.A database cluster that requires stable network identities

C.A batch job that runs once and exits

D.A stateless web application that can scale horizontally

E.A microservice that can use any available node

AnswersA, B

StatefulSet assigns each replica a stable, ordinal identity and its own PersistentVolumeClaim via volumeClaimTemplates, so storage survives rescheduling and remains bound to that pod. A Deployment's replicas share no such per-instance identity, making it unsuitable when each instance needs persistent storage unique to itself.

Why this answer

Option A is correct because a StatefulSet provides each Pod with a stable, unique identity and its own PersistentVolumeClaim via volumeClaimTemplates, so each replica keeps dedicated persistent storage that survives rescheduling — something a Deployment cannot guarantee since its Pods share no ordinal-based PVC binding. Option B is correct because StatefulSet Pods get predictable, stable DNS names through a headless Service (e.g., pod-0.svc.namespace.svc.cluster.local), which database clusters such as MySQL, PostgreSQL, or etcd need for peer discovery and quorum. Option C is wrong because run-once batch workloads are better handled by a Job (or CronJob), not a StatefulSet or Deployment.

Option D is wrong because stateless horizontally scalable web apps are the canonical use case for a Deployment, which offers rolling updates and replica management without per-Pod identity. Option E is wrong because node-agnostic microservices are stateless by nature and gain nothing from StatefulSet's stable identity or storage guarantees.

Exam trap

The trap here is that candidates may confuse the need for stable network identities (StatefulSet) with the ability to run on any node (Deployment), or mistakenly think batch jobs fit into StatefulSets because they involve 'state' like logs.

Practice this question →

183

MCQmedium

A cluster administrator wants to restrict which nodes a Pod can be scheduled on based on node labels, while also allowing the scheduler to prefer certain nodes but still run elsewhere if needed. Which combination of features should be used?

A.Use `topologySpreadConstraints` with `whenUnsatisfiable: DoNotSchedule` to spread Pods across labeled nodes.

B.Use `taints` on the nodes and `tolerations` on the Pod to define which nodes are preferred.

C.Use `nodeSelector` for a hard requirement and `nodeAffinity` with `preferredDuringSchedulingIgnoredDuringExecution` for soft preferences.

D.Use `podAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` to pin the Pod to nodes with specific labels.

AnswerC

`nodeSelector` provides a simple hard constraint that limits scheduling to nodes with matching labels. `nodeAffinity` with `preferredDuringSchedulingIgnoredDuringExecution` expresses soft preferences that influence scoring but do not block scheduling if no preferred node is available. Combining them gives a hard label requirement plus flexible preference, exactly matching the administrator's goal.

Why this answer

The scenario requires a hard constraint on node labels and a soft preference that still permits scheduling elsewhere. `nodeSelector` enforces the hard label match, while `nodeAffinity` with a preferred rule provides weighted preferences without preventing scheduling. Other mechanisms either constrain by Pod labels, repulse rather than prefer, or focus on spreading, so they do not satisfy both parts of the requirement.

Exam trap

The trap here is mixing up node affinity with pod affinity, or treating taints as a way to prefer nodes rather than to repel Pods.

Practice this question →

184

MCQmedium

A cluster administrator needs to grant a user permission to view Pods in the 'staging' namespace but not in any other namespace. Which combination of Kubernetes objects should be created?

A.A Role and a RoleBinding in the 'staging' namespace

B.A ClusterRole and a RoleBinding in the 'staging' namespace

C.A ClusterRole and a ClusterRoleBinding

D.A Role and a ClusterRoleBinding

AnswerA

A Role defines permissions within a specific namespace, and a RoleBinding grants those permissions to a user within that same namespace. Creating both in the 'staging' namespace limits the user's ability to view Pods to that namespace only, satisfying the requirement.

Why this answer

To grant namespace-scoped permissions, the standard approach is to create a Role that defines the allowed verbs on Pods and a RoleBinding that binds that Role to the user within the 'staging' namespace. This ensures the user can view Pods only in that namespace, following the principle of least privilege.

Exam trap

The trap here is thinking that a ClusterRole and RoleBinding is the only way to grant namespaced access, but a simple Role and RoleBinding is sufficient and more precise.

Practice this question →

185

MCQmedium

You want to view the logs of a container named 'app' inside a pod named 'web-pod-7d4f8'. Which kubectl command should you use?

A.kubectl exec web-pod-7d4f8 -c app -- logs

B.kubectl log web-pod-7d4f8 --container app

C.kubectl logs web-pod-7d4f8 -c app

D.kubectl logs web-pod-7d4f8 app

AnswerC

kubectl logs retrieves stdout/stderr from a single container, and the -c flag selects which container when a pod holds several. Naming web-pod-7d4f8 with -c app satisfies the stem's requirement to target the container named 'app'.

Why this answer

The `kubectl logs` command is the standard way to retrieve container logs in Kubernetes. The `-c` flag specifies the container name within the pod, which is necessary when a pod contains multiple containers. Here, the container is named 'app' inside the pod 'web-pod-7d4f8', so `kubectl logs web-pod-7d4f8 -c app` correctly fetches its logs.

Exam trap

In the KCNA exam, candidates often confuse 'kubectl logs' with 'kubectl exec' or use incorrect flag syntax (e.g., '--container' vs '-c'). Option C is the only correct syntax because 'kubectl logs' requires the pod name and optionally '-c' for container name.

How to eliminate wrong answers

Option A is wrong because `kubectl exec` is used to execute commands inside a running container, not to view logs; the syntax `-- logs` is invalid and would attempt to run a command named 'logs' inside the container. Option B is wrong because the correct subcommand is `kubectl logs`, not `kubectl log`; Kubernetes CLI does not accept 'log' as a valid verb. Option D is wrong because it omits the `-c` flag and instead passes the container name as a positional argument; `kubectl logs` expects the pod name as the first argument and the container name must be specified with `-c` or `--container`, not as a bare argument.

Practice this question →

186

MCQmedium

A Deployment manages ReplicaSets. What is the primary benefit of using a Deployment over directly managing ReplicaSets?

A.Deployments can expose services externally

B.Deployments support rolling updates and rollbacks

C.Deployments automatically configure DNS

D.Deployments provide persistent storage

AnswerB

Deployments add a control layer above ReplicaSets, automatically creating a new ReplicaSet for each pod template change and shifting replicas gradually. This enables rolling updates and rollback to a previous revision, which direct ReplicaSet management does not provide.

Why this answer

The primary benefit of using a Deployment over directly managing ReplicaSets is that Deployments provide declarative updates for Pods and ReplicaSets, including built-in support for rolling updates and rollbacks. This allows you to update the desired state (e.g., a new container image version) and have the Deployment controller automatically orchestrate the transition, while also enabling you to revert to a previous revision if the update fails. Directly managing ReplicaSets would require manual steps to scale down old ReplicaSets and scale up new ones, and it lacks the automated revision history and rollback capabilities that Deployments offer.

Exam trap

CNCF often tests the misconception that Deployments directly manage Pods, but the trap here is that candidates may confuse the Deployment's high-level features (like rolling updates) with other Kubernetes resources (Services, DNS, storage) that handle networking, naming, or data persistence, leading them to pick a wrong answer that describes a capability of a different resource.

How to eliminate wrong answers

Option A is wrong because Deployments do not expose services externally; that is the role of a Service (e.g., NodePort, LoadBalancer) or an Ingress resource. Option C is wrong because Deployments do not automatically configure DNS; DNS resolution for Pods and Services is handled by CoreDNS (or kube-dns) based on Service objects, not Deployments. Option D is wrong because Deployments do not provide persistent storage; persistent storage is managed through PersistentVolumeClaims (PVCs) and StorageClasses, which are referenced by Pods in a Deployment's template, but the Deployment itself does not provision or attach storage.

Practice this question →

187

MCQmedium

Which command would you use to view the logs of a container named 'sidecar' inside a pod named 'app'?

A.kubectl logs app -c sidecar

B.kubectl logs app sidecar

C.kubectl logs sidecar app

D.kubectl logs sidecar -p app

AnswerA

The -c flag selects a specific container within a multi-container pod, so kubectl logs app -c sidecar retrieves output from the sidecar container. Without -c, kubectl would default to the pod's first container, failing the stem's named-container constraint.

Why this answer

The `kubectl logs` command uses the `-c` flag to specify a container name within a pod. When a pod contains multiple containers, you must explicitly indicate which container's logs to retrieve. The syntax `kubectl logs <pod-name> -c <container-name>` is the standard way to view logs from a specific container in a multi-container pod.

Exam trap

The trap is that candidates may assume the container name can be passed as a second positional argument instead of using the `-c` flag.

How to eliminate wrong answers

Option B is wrong because `kubectl logs app sidecar` is invalid syntax; the command expects the pod name first, and the container name must be specified with the `-c` flag, not as a positional argument. Option C is wrong because `kubectl logs sidecar app` reverses the order, treating 'sidecar' as the pod name and 'app' as an unrecognized positional argument, which will fail or produce incorrect output. Option D is wrong because `kubectl logs sidecar -p app` uses the `-p` flag (for previous container logs) incorrectly; the `-p` flag does not accept a container name as its argument, and the pod name 'sidecar' is not the correct pod name in this scenario.

Practice this question →

188

MCQmedium

A developer creates a Pod with a volume of type emptyDir. The Pod writes data to the volume and then is deleted. What happens to the data?

A.The data remains in the container's filesystem layer and can be recovered by restarting the container.

B.The data persists on the node and can be reused by a new Pod if the same emptyDir name is used.

C.The data is permanently deleted when the Pod is removed.

D.The data is automatically backed up to a PersistentVolume before deletion.

AnswerC

An emptyDir volume is created when a Pod is assigned to a node and exists only for the lifetime of that Pod. When the Pod is deleted, the emptyDir volume and all its data are deleted. This makes it suitable for temporary scratch space, caching, or sharing files between containers in the same Pod.

Why this answer

An emptyDir volume is ephemeral and scoped to the Pod. When the Pod is deleted, the volume is removed from the node, and its data is lost. To retain data beyond the Pod's lifetime, you must use a PersistentVolumeClaim backed by durable storage.

This behavior is fundamental for understanding stateless versus stateful workloads.

Exam trap

The trap here is confusing emptyDir with a PersistentVolume, assuming that data written to any volume persists after Pod deletion, when emptyDir is strictly temporary.

Practice this question →

189

MCQmedium

What does the 'kubectl get pods' command display?

A.Detailed information about a specific pod

B.A list of all pods in the current namespace

C.The YAML definition of a pod

D.The logs of all pods

AnswerB

kubectl get pods queries the API server for Pod objects in the active namespace, returning name, ready status, phase, restarts and age. This satisfies the listing requirement; adding --all-namespaces or -A would broaden scope beyond the current namespace.

Why this answer

The 'kubectl get pods' command lists all pods in the current namespace, providing a summary of their status, restarts, and age. This is the default behavior without specifying a namespace or pod name, making it the primary command for pod discovery and health checks.

Exam trap

The exam often tests the distinction between 'get' (list/summary) and 'describe' (detailed info), so candidates mistakenly think 'get pods' shows detailed pod information.

How to eliminate wrong answers

Option A is wrong because 'kubectl describe pod <name>' provides detailed information about a specific pod, not 'kubectl get pods'. Option C is wrong because 'kubectl get pod <name> -o yaml' outputs the YAML definition of a pod, not the plain 'kubectl get pods' command. Option D is wrong because 'kubectl logs <pod-name>' retrieves logs for a specific pod, and 'kubectl logs --all-containers=true' can target multiple containers, but there is no single command to get logs of all pods simultaneously; 'kubectl get pods' does not display logs.

Practice this question →

190

Multi-Selecthard

Which TWO of the following are true about Kubernetes Pods?

Select 2 answers

A.Containers in a pod always have isolated filesystems

B.A pod is the smallest deployable unit in Kubernetes

C.A pod can contain multiple containers that share the same network namespace

D.Pods are designed to be long-lived and never terminated

E.Each container in a pod gets its own IP address

AnswersB, C

A pod wraps one or more containers sharing a network namespace and storage volumes, and it is the atomic unit Kubernetes schedules, deploys and scales. Every higher-level controller, such as a Deployment or ReplicaSet, ultimately manages pods.

Why this answer

Option B is correct because the Pod is the smallest deployable unit in Kubernetes — you cannot deploy a bare container directly; the kubelet schedules and runs Pods, and every workload object (Deployment, StatefulSet, Job, etc.) ultimately creates Pods. Option C is correct because containers within a single Pod share the same network namespace, meaning they share one IP address and can communicate over localhost, and they can also share volumes for data exchange. Option A is wrong because containers in a Pod can share volumes and, when configured, share process namespace; filesystem isolation is not guaranteed across all containers.

Option D is wrong because Pods are ephemeral by design — they are terminated, deleted, or replaced (e.g., by a ReplicaSet) and are not intended to be long-lived. Option E is wrong because the Pod, not each container, is assigned a single IP address; all containers in the Pod share that one IP.

Exam trap

The trap here is that candidates often confuse Pods with virtual machines, assuming each container gets its own IP and filesystem isolation, when in fact Pods are designed for tight coupling and shared resources.

Practice this question →

191

MCQmedium

You have a Kubernetes cluster with multiple namespaces. You need to allow communication only from pods with label 'app: frontend' to pods with label 'app: backend' in the same namespace. Which resource should you use?

A.RBAC Role

B.NetworkPolicy

C.PodSecurityPolicy

D.Service

AnswerB

NetworkPolicy is a namespaced resource applying label selectors to pods, with ingress rules permitting traffic only from pods labelled app: frontend to those labelled app: backend. It enforces the required pod-level segmentation, which plain Services cannot restrict.

Why this answer

NetworkPolicy is a Kubernetes resource that controls ingress and egress traffic between pods based on labels, namespaces, or IP blocks. By defining a NetworkPolicy with a podSelector matching 'app: backend' and an ingress rule that allows traffic only from pods with label 'app: frontend', you can restrict communication to only those pods in the same namespace. This is the correct approach because NetworkPolicy operates at Layer 3/4 (and optionally Layer 7 with Cilium) to enforce network segmentation.

Exam trap

The trap here is that candidates confuse RBAC (which controls API access) with network access control, assuming that a Role or RoleBinding can restrict pod-to-pod traffic, but RBAC has no effect on network-level communication.

How to eliminate wrong answers

Option A is wrong because RBAC Role controls access to Kubernetes API resources (e.g., pods, services) for users or service accounts, not network traffic between pods. Option C is wrong because PodSecurityPolicy (deprecated in v1.21, removed in v1.25) enforces security constraints on pod specifications (e.g., privileged containers, host namespaces), not network communication. Option D is wrong because a Service provides a stable endpoint for accessing a set of pods via DNS or cluster IP, but does not filter or restrict traffic based on source labels.

Practice this question →

192

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster by running reconciliation loops?

A.kube-scheduler

B.etcd

C.kube-apiserver

D.kube-controller-manager

AnswerD

kube-controller-manager runs the built-in controllers whose reconciliation loops continuously compare observed cluster state against the desired state declared in objects, then act to close any drift. This directly satisfies the stem's requirement for the component maintaining desired state through reconciliation.

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, each of which watches the current state of the cluster via the kube-apiserver and makes changes to drive the actual state toward the desired state defined in etcd. This reconciliation loop pattern is fundamental to Kubernetes' self-healing behavior, ensuring that resources like deployments, replica sets, and nodes match their specifications.

Exam trap

CNCF often tests the misconception that etcd is responsible for maintaining desired state because it stores the desired state, but the trap is that etcd is only a data store and does not execute reconciliation loops—that is the job of the kube-controller-manager.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource requirements and policies, not for maintaining desired state via reconciliation loops. Option B is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it does not run reconciliation logic or enforce desired state. Option C is wrong because kube-apiserver serves as the front-end for the Kubernetes control plane, exposing the REST API and validating requests, but it does not perform continuous reconciliation; it is the gateway through which controllers interact.

Practice this question →

193

Drag & Dropmedium

Drag and drop the steps to set up a Kubernetes cluster using kubeadm into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First install runtime and Kubernetes tools, then init control plane, add network plugin, and join workers.

Practice this question →

194

Multi-Selectmedium

Which TWO of the following are control plane components? (Select TWO)

Select 2 answers

A.etcd

B.kube-apiserver

C.kube-proxy

D.kubelet

E.Container runtime

AnswersA, B

etcd is the control plane's distributed key-value store, persisting all cluster state and configuration. It runs alongside the API server on control plane nodes, satisfying the stem's requirement for a control plane component rather than a worker node process such as kubelet or kube-proxy.

Why this answer

In Kubernetes, the control plane is the set of components that make global cluster decisions and store cluster state, and etcd (A) is correct because it is the consistent, highly-available key-value store that persists all cluster data, including objects, configuration, and state. The kube-apiserver (B) is also correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the only component that talks directly to etcd. By contrast, kube-proxy (C) runs on each node and implements Service networking rules via iptables/IPVS, kubelet (D) is the node agent that manages Pods and containers on a worker node, and the container runtime (E) is the node-level software (e.g., containerd, CRI-O) that actually runs containers — all three are node components, not control plane components.

Exam trap

A common mistake is to think that kube-proxy or kubelet are control plane components because they are essential for cluster operation. However, they run on each node and are part of the node-level components, not the control plane.

Practice this question →

195

MCQmedium

A pod has a liveness probe that returns failure. What action will Kubernetes take?

A.The container will be restarted

B.The service endpoint will be removed

C.The pod will be deleted

D.The pod will be rescheduled to another node

AnswerA

A failing liveness probe signals the container is unhealthy, so the kubelet kills it and restarts it according to the pod's restartPolicy. This differs from a readiness probe, which only removes the pod from Service endpoints without restarting.

Why this answer

When a liveness probe fails, Kubernetes interprets this as the container being in a deadlock or unresponsive state from which it cannot recover without a restart. The kubelet on the node where the pod is running directly restarts the container according to the pod's restart policy (defaulting to Always). This is a container-level action, not a pod-level action, so the pod itself remains on the same node.

Exam trap

The trap here is that candidates confuse liveness probes with readiness probes, assuming a failed liveness probe removes the pod from the service endpoint, when in fact only readiness probes affect traffic routing.

How to eliminate wrong answers

Option B is wrong because service endpoints are removed only when a readiness probe fails, not a liveness probe; readiness probes control traffic routing, while liveness probes control container lifecycle. Option C is wrong because a liveness probe failure does not delete the pod; the pod continues to exist and the container is restarted in place. Option D is wrong because rescheduling to another node only happens if the pod is deleted (e.g., by a node failure or higher-level controller), not from a liveness probe failure; the kubelet handles the restart locally without involving the scheduler.

Practice this question →

196

MCQeasy

What is the purpose of a Namespace in Kubernetes?

A.To assign IP addresses to services

B.To limit the number of pods that can be created

C.To logically isolate resources like pods and services

D.To provide DNS names for pods

AnswerC

Namespaces partition a single cluster's API resources, giving each group its own scope for names, quotas and RBAC. This satisfies the stem's requirement for logical isolation of pods and services, since identically named objects can coexist across separate namespaces.

Why this answer

Namespaces in Kubernetes provide a mechanism for logically isolating resources such as Pods, Services, and Deployments within a cluster. They enable multiple virtual clusters to coexist on the same physical cluster, allowing for resource scoping, access control, and organization by team or environment (e.g., dev, staging, prod). This isolation is fundamental to multi-tenancy and resource management in Kubernetes.

Exam trap

The trap here is that candidates confuse Namespaces with resource quotas or network isolation features, assuming Namespaces themselves enforce limits or IP assignments, when in fact they are purely logical grouping mechanisms that require additional controllers (like ResourceQuota or NetworkPolicy) to enforce constraints.

How to eliminate wrong answers

Option A is wrong because assigning IP addresses to Services is the role of the cluster IP address range and the kube-proxy component, not Namespaces; Namespaces do not manage IP allocation. Option B is wrong because limiting the number of Pods that can be created is achieved through ResourceQuotas or LimitRanges applied to a Namespace, not by the Namespace itself; a Namespace is a logical boundary, not a quota mechanism. Option D is wrong because providing DNS names for Pods is handled by CoreDNS (or kube-dns) and the cluster DNS service, which resolves Pod IPs via headless Services or Pod hostnames, not by Namespaces; Namespaces only affect DNS name scoping (e.g., <service>.<namespace>.svc.cluster.local).

Practice this question →

197

Multi-Selecthard

Which THREE statements about Labels and Selectors are correct?

Select 3 answers

A.Services use selectors to determine which Pods receive traffic

B.Selectors are used by Deployments to identify the Pods they manage

C.Labels can be used to organize and select subsets of objects

D.Labels must be unique within a namespace

E.Annotations are used for identification and selection

AnswersA, B, C

Services match Pods through label selectors, continuously evaluating which Pods satisfy the specified key-value criteria. This satisfies the stem's requirement by describing how traffic routing is decoupled from Pod identity: any Pod bearing matching labels joins the Service's endpoint list, regardless of name, IP address or node placement.

Why this answer

Option A is correct because a Service's spec.selector matches Pod labels, and the kube-proxy/EndpointSlice machinery routes traffic only to Pods whose labels satisfy that selector. Option B is correct because a Deployment (and ReplicaSet) uses spec.selector.matchLabels/matchExpressions to determine which Pods it owns and manages, ensuring it only adopts Pods matching those labels. Option C is correct because labels are arbitrary key/value metadata designed for organizing objects and for grouping/selecting subsets via label selectors (equality- and set-based).

Option D is incorrect because label keys must be unique per object, but labels are not required to be unique across a namespace—many objects can share the same labels. Option E is incorrect because annotations are non-identifying metadata and cannot be used with selectors for selection; only labels are queryable by selectors.

Exam trap

CNCF often tests the distinction between labels and annotations, trapping candidates who assume annotations can also be used for selection, when in fact only labels support selector-based filtering.

Practice this question →

198

Multi-Selectmedium

Which three of the following are valid ways to interact with the Kubernetes API? (Select THREE.)

Select 3 answers

A.Using a Kubernetes client library (e.g., client-go)

B.Using the 'kubeadm' command

C.Using the Docker CLI

D.Using kubectl command-line tool

E.Direct HTTP requests to the API server using tools like curl

AnswersA, D, E

Client libraries such as client-go authenticate to the API server and issue REST calls programmatically, letting applications and controllers query or mutate cluster state. This satisfies the stem's requirement for a valid interaction method, alongside kubectl and direct REST calls, because the API server exposes an HTTP endpoint any compliant client can consume.

Why this answer

Option A is correct because Kubernetes provides official client libraries such as client-go (Go), client-python, and client-java that programmatically communicate with the API server via REST, allowing applications and controllers to create, read, update, and delete resources. Option D is correct because kubectl is the standard command-line tool that authenticates to the API server and translates commands like 'kubectl get pods' into REST API calls. Option E is correct because the Kubernetes API server exposes a RESTful HTTP API, so tools like curl can send authenticated requests directly to endpoints such as /api/v1/namespaces/default/pods.

Option B is not a way to interact with the API; kubeadm is a bootstrap tool for initializing clusters and joining nodes, not for querying or managing API resources. Option C is incorrect because the Docker CLI manages containers on a Docker daemon and has no native interface to the Kubernetes API server.

Exam trap

A common pitfall is confusing cluster management tools (like kubeadm) with API interaction tools. kubeadm is used for bootstrapping and managing Kubernetes clusters, not for querying or modifying cluster resources via the API.

Practice this question →

199

MCQeasy

Which command is used to view detailed information about a specific pod?

A.kubectl exec pod -- /bin/sh

B.kubectl logs pod

C.kubectl describe pod

D.kubectl get pod

AnswerC

kubectl describe pod fetches the Pod's full status, events, conditions, container states and resource details from the API server, which is what detailed inspection requires. kubectl logs only shows container output, and kubectl get pod returns a summary.

Why this answer

The `kubectl describe pod` command retrieves detailed information about a specific pod, including its current state, events, labels, annotations, container details, resource limits, and volume mounts. This is the standard Kubernetes command for inspecting the full configuration and lifecycle of a pod object, as opposed to the summary view provided by `kubectl get pod`.

Exam trap

A common mistake is selecting `kubectl get pod` instead of `kubectl describe pod`. While `kubectl get` provides a summary view, `kubectl describe` returns detailed information including events, state, and configuration.

How to eliminate wrong answers

Option A is wrong because `kubectl exec pod -- /bin/sh` is used to execute a command inside a running container within a pod, not to view pod details. Option B is wrong because `kubectl logs pod` retrieves the stdout/stderr logs from a container in the pod, not the pod's metadata or configuration. Option D is wrong because `kubectl get pod` only displays a concise list of pods with basic fields like name, status, and age, without the detailed information that `kubectl describe` provides.

Practice this question →

200

Multi-Selecthard

Which THREE of the following are true about Kubernetes Namespaces?

Select 3 answers

A.PersistentVolumes are namespaced

B.NetworkPolicy can be used to control traffic between pods in different namespaces

C.Nodes are namespaced resources

D.You can apply ResourceQuota to limit resource consumption in a namespace

E.Namespaces are used to isolate resources like Pods and Services

AnswersB, D, E

NetworkPolicy objects are namespaced and select pods by label, so rules can explicitly permit or deny ingress and egress traffic crossing namespace boundaries. This makes cross-namespace pod traffic controllable rather than implicitly open, satisfying the statement about inter-namespace communication.

Why this answer

Option B is correct because NetworkPolicy objects are namespaced and their podSelector rules can reference other namespaces via namespaceSelector, allowing administrators to permit or deny ingress/egress traffic between pods in different namespaces. Option D is correct because ResourceQuota is a namespaced object that caps aggregate resource consumption (e.g., requests.cpu, limits.memory, count/pods) within a single namespace. Option E is correct because namespaces provide logical isolation for namespaced resources such as Pods, Services, Deployments, and ConfigMaps, enabling separate environments or teams to coexist in one cluster.

Option A is incorrect because PersistentVolumes are cluster-scoped resources, not namespaced (only PersistentVolumeClaims are namespaced). Option C is incorrect because Nodes are cluster-scoped resources, not namespaced.

Exam trap

The exam often tests the distinction between cluster-scoped and namespaced resources, and the trap here is that candidates mistakenly think all Kubernetes resources are namespaced, when in fact Nodes, PersistentVolumes, and ClusterRoles are cluster-scoped.

Practice this question →

201

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Increase the memory limit in the pod's container resource specification

B.Increase the CPU request for the container

C.Delete and recreate the pod to clear the crash loop

D.Delete the namespace and redeploy all workloads

AnswerA

OOMKilled means the kernel terminated the container for exceeding its memory limit, so raising that limit gives the process the headroom it needs. The pod ran for days before failing, indicating a genuine memory ceiling rather than a configuration or image fault.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to allocate more memory without being killed, resolving the crash loop. This directly addresses the root cause—insufficient memory limit—without affecting other resources or requiring full redeployment.

Exam trap

A common trap in the CNCF Kubernetes exams is assuming that CrashLoopBackOff always requires pod deletion or restart, but OOMKilled is a resource limit issue that must be fixed by adjusting the memory limit, not by recreating the pod.

How to eliminate wrong answers

Option B is wrong because increasing the CPU request does not affect memory allocation; CPU and memory are independent resources, and OOMKilled is solely a memory issue. Option C is wrong because deleting and recreating the pod only restarts the container with the same memory limit, which will immediately trigger OOMKilled again under the same workload. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme, unnecessary action that disrupts all other resources in the namespace and does not fix the memory limit configuration.

Practice this question →

202

MCQmedium

An operations team runs a stateless web application in a Deployment with 3 replicas. They need each Pod to be able to read application configuration from a single source, and updates to that configuration should be reflected in the running Pods without rebuilding the container image. Which Kubernetes resource should they use to store the configuration and inject it as environment variables into the Pods?

A.Secret

B.ConfigMap

C.PersistentVolumeClaim

D.ResourceQuota

AnswerB

ConfigMap holds non-confidential key-value configuration data and can be consumed as environment variables in a Pod. When a ConfigMap is referenced via envFrom or valueFrom in the Pod spec, Kubernetes injects the values at container start. This avoids baking configuration into the image and allows the same image to be reused across environments, which directly matches the team's requirement.

Why this answer

ConfigMap is designed for non-sensitive configuration data and integrates directly with Pods through environment variables or mounted files. Because the team wants configuration decoupled from the container image and injected at runtime, a ConfigMap is the correct choice. The other resources serve storage, secret handling, or quota enforcement and cannot provide general application configuration to the container environment.

Exam trap

The trap here is assuming that Secret is the default way to pass any configuration into a Pod, when Secrets are specifically meant for sensitive values and ConfigMaps for ordinary configuration.

Practice this question →

203

MCQmedium

You want to expose a set of pods running on node port 30080 to external traffic. Which Service type should you use?

A.ExternalName

B.LoadBalancer

C.NodePort

D.ClusterIP

AnswerC

NodePort allocates a static port on every node's IP, so traffic arriving at node port 30080 is forwarded to the backing pods. ClusterIP and LoadBalancer do not expose a fixed node-level port, failing the stated constraint.

Why this answer

(NodePort) is correct because a NodePort service exposes the application on a static port (30080) on each node's IP address, making it accessible from outside the cluster via <NodeIP>:30080. This is the appropriate choice when you need to expose pods to external traffic using a specific port number without requiring a cloud load balancer.

Exam trap

The trap here is that candidates confuse NodePort with LoadBalancer, thinking a cloud load balancer is required for external access, but NodePort directly exposes a static port on the node's IP without any cloud dependency.

How to eliminate wrong answers

Option A (ExternalName) is wrong because it maps a service to a DNS name (e.g., an external CNAME record) and does not expose pods or provide any network connectivity to external traffic; it is used for internal DNS aliasing. Option B (LoadBalancer) is wrong because it provisions an external cloud load balancer (e.g., AWS ELB, GCP LB) which assigns a dynamic external IP and port, not a fixed node port like 30080; it is overkill and does not guarantee the specific port. Option D (ClusterIP) is wrong because it exposes the service only on a cluster-internal IP, reachable only from within the cluster, and cannot be accessed from external traffic without additional components like an ingress or proxy.

Practice this question →

204

MCQeasy

A container in a pod has been restarted multiple times with 'CrashLoopBackOff' state. What does this indicate?

A.The container is using too much memory

B.The container exits with a non-zero exit code soon after starting

C.The container is running but not responding to health checks

D.The container image cannot be pulled

AnswerB

CrashLoopBackOff means the kubelet repeatedly starts the container, sees it terminate, and applies exponential backoff before retrying. A non-zero exit code confirms the process itself fails soon after launch, satisfying the stem's repeated-restart condition rather than an image pull or scheduling fault.

Why this answer

The 'CrashLoopBackOff' state indicates that a container in a pod repeatedly starts, exits with a non-zero exit code, and is then restarted by the kubelet. This loop triggers an exponential backoff delay, preventing the container from staying up. The core issue is that the container process fails almost immediately after starting, not that it is resource-constrained or unresponsive.

Exam trap

A common trap in the CNCF exam is the distinction between 'CrashLoopBackOff' (container exits immediately) and 'ImagePullBackOff' (image cannot be pulled), so candidates mistakenly choose the image pull failure option when they see 'BackOff' in the state name.

How to eliminate wrong answers

Option A is wrong because excessive memory usage typically leads to an 'OOMKilled' state, not 'CrashLoopBackOff', and the container would be terminated by the kernel, not exit on its own. Option C is wrong because a container that is running but not responding to health checks enters a 'CrashLoopBackOff' only if the liveness probe fails repeatedly and the container is restarted; however, the question states the container has been restarted multiple times with 'CrashLoopBackOff', which implies it exits immediately, not that it runs and fails probes. Option D is wrong because an image pull failure results in 'ImagePullBackOff' or 'ErrImagePull', not 'CrashLoopBackOff', as the container never starts.

Practice this question →

205

Multi-Selectmedium

Which THREE of the following are responsibilities of the kube-controller-manager?

Select 3 answers

A.Assigning Pods to Nodes

B.Creating Endpoints objects for Services

C.Monitoring Node health and reacting to Node failures

D.Ensuring the correct number of Pod replicas are running

E.Serving the Kubernetes API

AnswersB, C, D

Endpoint creation belongs to the endpoint controller, which runs inside the kube-controller-manager alongside controllers for nodes, replication and service accounts. It watches Services and their pod selectors, then writes matching Endpoints objects, satisfying the stem's requirement that this be a kube-controller-manager responsibility rather than kubelet or kube-proxy work.

Why this answer

Option B is correct because the kube-controller-manager runs the endpoints controller (and endpointslice controller), which populates Endpoints/EndpointSlice objects for Services by tracking the Pods matching each Service's selector. Option C is correct because the node lifecycle controller inside the kube-controller-manager monitors Node heartbeats/status and applies taints such as node.kubernetes.io/not-ready or unreachable and evicts Pods when Nodes fail. Option D is correct because the ReplicaSet controller (and Deployment/StatefulSet controllers) run in the kube-controller-manager and reconcile the actual number of Pod replicas to the desired count.

Option A is not part of the kube-controller-manager; Pod-to-Node assignment is performed by the kube-scheduler. Option E is not part of the kube-controller-manager; the Kubernetes API is served by kube-apiserver.

Exam trap

The trap here is that candidates confuse the kube-controller-manager's role in 'managing controllers' with the scheduler's role in 'assigning Pods to nodes', or they mistakenly think the controller-manager serves the API because it interacts with the API server.

Practice this question →

206

MCQmedium

A development team deploys a microservice that crashes every few minutes. The deployment uses a single replica, and the pod restarts repeatedly. Which Kubernetes feature should be enabled to ensure the service remains available during failures?

A.Move the deployment to a separate namespace

B.Increase the replicas in the Deployment to at least 2

C.Store the application configuration in a ConfigMap

D.Add a readiness probe to the pod

AnswerB

Increasing replicas to at least 2 keeps the service available because the ReplicaSet controller maintains the desired count, rescheduling pods onto healthy nodes when one crashes. This satisfies the availability constraint, unlike a single replica, which leaves no capacity during restarts. Note that this masks crashes rather than fixing the underlying fault.

Why this answer

Increasing the replicas to at least 2 ensures that if one pod crashes, the other replica(s) can continue serving traffic, maintaining availability. With only a single replica, the service becomes unavailable every time the pod restarts. This is the most direct way to provide redundancy and fault tolerance for a stateless microservice.

Exam trap

The trap here is that candidates often confuse health probes (readiness/liveness) with redundancy; while probes help detect and manage unhealthy pods, they do not provide the multiple running instances needed to maintain availability during a crash.

How to eliminate wrong answers

Option A is wrong because moving the deployment to a separate namespace does not affect pod availability or crash recovery; namespaces are for logical isolation, not high availability. Option C is wrong because storing configuration in a ConfigMap decouples configuration from the container image but does not prevent or recover from pod crashes. Option D is wrong because a readiness probe only controls whether a pod receives traffic; it does not keep the service available if the pod crashes—it merely stops sending traffic to an unhealthy pod, but with a single replica, no other pod exists to handle requests.

Practice this question →

207

MCQeasy

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

A.Pod

B.Deployment

C.Node

D.Container

AnswerA

A Pod is the smallest deployable unit Kubernetes creates, schedules and manages, wrapping one or more containers that share a network namespace and storage volumes. This satisfies the stem's constraint that the unit be creatable, schedulable and manageable, unlike individual containers.

Why this answer

A Pod is the smallest and simplest unit in the Kubernetes object model that can be created, scheduled, and managed. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the underlying runtime, Kubernetes does not schedule containers directly; it schedules Pods as the atomic unit of deployment.

Exam trap

The trap here is that candidates often confuse 'container' as the smallest unit because it is the runtime process, but Kubernetes explicitly treats the Pod as the smallest deployable and schedulable object, not the container.

How to eliminate wrong answers

Option B is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit; Pods are scheduled onto Nodes. Option D is wrong because a Container is the runtime process, but Kubernetes schedules and manages Pods, not individual containers; containers must be wrapped in a Pod to be deployed.

Practice this question →

208

MCQeasy

A developer creates a Deployment with 3 replicas. After a few seconds, they run `kubectl get deployments` and see `READY 2/3`. They want to quickly identify why one replica is not ready. Which command should they use to inspect the status of the individual Pods?

A.kubectl describe deployment myapp

B.kubectl get pods -l app=myapp -o wide

C.kubectl get events --field-selector involvedObject.name=myapp

D.kubectl logs deployment/myapp

AnswerB

This command lists all Pods matching the label selector app=myapp, showing their status, restarts, and node assignment. It directly reveals which Pod is not Ready and provides basic details. The -o wide flag adds IP and node information, which can help correlate with node issues. This is the quickest way to see the individual Pod statuses and identify the problematic replica.

Why this answer

To quickly identify which Pod is not ready, listing Pods with the Deployment's label selector and wide output shows each Pod's status and node. This provides an immediate view of which replica is failing and basic context. Describing the Deployment or fetching logs from the Deployment does not show per-Pod readiness.

Filtering events by the Deployment name misses Pod-level events. The correct approach is to query the Pods directly.

Exam trap

The trap here is using a Deployment-level command when the issue is at the Pod level; always inspect the Pods themselves to see individual readiness and status.

Practice this question →

209

Multi-Selectmedium

Which two of the following are responsibilities of the kubelet? (Select TWO.)

Select 2 answers

A.Reporting the node's status to the control plane

B.Implementing network rules for services

C.Assigning pods to nodes based on resource availability

D.Storing cluster state in a key-value store

E.Ensuring that containers are running in a pod as specified

AnswersA, E

The kubelet runs on each node and continuously reports node and pod status to the control plane, typically via the API server. This satisfies the stem's requirement by covering the node-level agent's duty to communicate health and capacity information upward.

Why this answer

Option A is correct because the kubelet runs on each node and periodically reports node status (including conditions, capacity, and allocatable resources) to the control plane via the API server, typically through NodeStatus updates. Option E is correct because the kubelet acts as the node agent that watches PodSpecs assigned to its node and ensures the specified containers are running and healthy, restarting them as needed via the container runtime. Option B is incorrect because implementing network rules for services is the job of kube-proxy (using iptables/IPVS), not the kubelet.

Option C is incorrect because assigning pods to nodes is performed by the kube-scheduler, which selects a node based on resource availability and constraints. Option D is incorrect because storing cluster state in a key-value store is the role of etcd, the cluster's backing datastore.

Exam trap

This certification exam often tests the distinction between the kubelet and other control plane components like the kube-scheduler or kube-proxy, so candidates must remember that the kubelet is a node-level agent focused on pod lifecycle and node status, not scheduling or networking.

Practice this question →

210

MCQeasy

Which component runs on every worker node and is responsible for ensuring that containers are running in a pod according to the pod specification?

A.kube-scheduler

B.kubelet

C.container runtime

D.kube-proxy

AnswerB

The kubelet is the node agent that watches the API server for pods bound to its node and drives the container runtime to start, stop and health-check containers to match the pod specification. It runs on every worker node, exactly as the stem requires.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It registers the node with the API server, watches for PodSpecs assigned to its node, and ensures the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime to create, start, and stop containers as needed, and it reports the node and pod status back to the control plane.

Exam trap

The trap here is that candidates confuse the kubelet with the container runtime, thinking the runtime itself reads the pod spec, when in fact the kubelet is the agent that interprets the spec and delegates container operations to the runtime via the Container Runtime Interface (CRI).

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is a control plane component that decides which worker node a new pod should be placed on, but it does not run on worker nodes nor does it manage container lifecycle. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is not responsible for reading the pod specification from the API server or ensuring the pod's desired state is maintained; that is the kubelet's job. Option D is wrong because kube-proxy is a network proxy that runs on each node and handles network rules for service traffic (e.g., iptables or IPVS), but it has no role in container lifecycle management or pod specification enforcement.

Practice this question →

211

MCQeasy

A company wants to ensure that a database pod runs on a node with SSD storage. How should this be achieved?

A.Label SSD nodes with 'disk=ssd' and add a nodeSelector to the pod

B.Set a resource request for local SSD storage in the pod spec

C.Use pod anti-affinity to avoid non-SSD nodes

D.Add a taint to nodes without SSDs and a toleration to the pod

AnswerA

Labelling SSD nodes with `disk=ssd` and adding a matching `nodeSelector` to the pod spec forces the Kubernetes scheduler to bind the database pod only to nodes carrying that label, directly satisfying the SSD-storage placement constraint. Node affinity would also work, but nodeSelector is the simplest mechanism for this exact requirement.

Why this answer

NodeSelector is a field in the Pod spec that constrains which nodes the Pod can be scheduled on, based on node labels. By labeling nodes with SSD storage as 'disk=ssd' and adding a nodeSelector with that label to the Pod, Kubernetes will only schedule the Pod on nodes that have the matching label, ensuring it runs on SSD storage.

Exam trap

The KCNA exam often tests the distinction between scheduling constraints (nodeSelector/node affinity) and repulsion mechanisms (taints/tolerations), trapping candidates who confuse tolerations as a way to select nodes rather than as a way to bypass node restrictions.

How to eliminate wrong answers

Option B is wrong because resource requests for local SSD storage are not supported in the standard Kubernetes resource model; storage is requested via PersistentVolumeClaims, not as a compute resource in the Pod spec. Option C is wrong because pod anti-affinity is used to avoid co-locating Pods on the same node or topology, not to select nodes based on hardware characteristics like SSD storage. Option D is wrong because taints and tolerations are used to repel Pods from nodes unless they have a matching toleration, but they do not actively select nodes with specific hardware; a toleration would allow the Pod to run on non-SSD nodes if they are not tainted, and tainting all non-SSD nodes is impractical and does not guarantee scheduling on SSD nodes.

Practice this question →

212

MCQhard

You notice that a newly created Pod remains in 'Pending' state. Which of the following is the MOST likely cause?

A.The Pod manifest has a syntax error

B.The container image does not exist

C.There are insufficient resources available on any node to meet the Pod's requests

D.The Service does not exist

AnswerC

The scheduler cannot bind a Pod to any node when no node has enough allocatable CPU or memory to satisfy its resource requests, leaving it Pending. Image pull failures or crashes occur after scheduling, producing different states such as ImagePullBackOff or CrashLoopBackOff.

Why this answer

A Pod enters 'Pending' state when it cannot be scheduled onto a node. The most common reason is insufficient CPU, memory, or other resources on any available node to satisfy the Pod's resource requests. The Kubernetes scheduler continuously evaluates node capacity against Pod requests, and if no node can accommodate the Pod, it remains unscheduled in Pending.

Exam trap

The KCNA exam often tests the distinction between scheduling failures (Pending) and runtime failures (ImagePullBackOff, CrashLoopBackOff), leading candidates to confuse image issues or syntax errors with resource constraints.

How to eliminate wrong answers

Option A is wrong because a syntax error in the Pod manifest would cause the API server to reject the manifest at creation time, resulting in an error message, not a Pod stuck in Pending. Option B is wrong because a missing container image would cause the Pod to be scheduled onto a node and then fail with an ImagePullBackOff or ErrImagePull status, not remain in Pending. Option D is wrong because the existence of a Service is irrelevant to Pod scheduling; Pods can run without any Service, and a missing Service does not affect the Pod's lifecycle or scheduling.

Practice this question →

213

MCQmedium

A team runs a stateless web application as a Deployment with 4 replicas. They want each replica to be reachable through a single stable virtual IP inside the cluster, and they want the traffic distributed across all healthy replicas. They have already created a Service of type ClusterIP with the correct selector. A new engineer asks what backend object the Service actually targets. What does the Service select?

A.The Deployment object itself, because the Service selector matches the Deployment's labels.

B.The individual Pods whose labels match the Service selector, tracked via EndpointSlices.

C.The ReplicaSet created by the Deployment, because it owns the Pods.

D.The nodes running the Pods, using each node's kubelet port as the backend.

AnswerB

A Service with a selector causes the endpoints controller to create EndpointSlice objects listing the IP addresses of matching, ready Pods. kube-proxy on each node programs iptables or IPVS rules to load-balance traffic to those Pod IPs. The Service's ClusterIP is stable, but the actual backends are the selected Pods, which can change as Pods are created or deleted.

Why this answer

A Service with a selector targets Pods, not Deployments or ReplicaSets. The endpoints controller watches for Pods matching the selector and populates EndpointSlice objects with their IPs and readiness state. kube-proxy then programs load-balancing rules to send traffic to those Pod IPs. This decoupling is why Services remain stable even as Pods are replaced.

Exam trap

The trap here is assuming a Service selects the Deployment or ReplicaSet that owns the Pods, when in fact it selects Pod labels directly.

Practice this question →

214

MCQmedium

A Deployment named 'app-deploy' is configured with strategy type: RollingUpdate. You want to update the container image to a new version. What kubectl command should you use?

A.kubectl apply -f updated-deployment.yaml

B.kubectl edit deployment app-deploy

C.kubectl patch deployment app-deploy -p '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"new:tag"}]}}}}'

D.kubectl set image deployment/app-deploy app=new:tag

AnswerD

The kubectl set image command updates a Deployment's container image in place, triggering the configured RollingUpdate strategy to replace pods gradually. Targeting deployment/app-deploy with the container name and new tag satisfies the stem's requirement to roll out the new version without editing YAML manually.

Why this answer

`kubectl set image` is the dedicated command for updating the container image of an existing deployment without modifying other fields. It directly modifies the deployment's pod template spec to use the new image, triggering a rolling update as defined by the deployment's strategy type.

Exam trap

The trap here is that candidates may think `kubectl apply` or `kubectl edit` are always the correct ways to update a deployment, but the exam tests the understanding that `kubectl set image` is the purpose-built command for updating container images in a deployment without needing a full manifest or interactive editing.

How to eliminate wrong answers

Option A is wrong because `kubectl apply -f updated-deployment.yaml` would work only if you have a YAML file with the updated image, but the question does not mention any file; it asks for a command to update the image directly, and `apply` is not the most direct or intended command for a simple image change. Option B is wrong because `kubectl edit deployment app-deploy` opens an interactive editor to modify the entire deployment manifest, which is overkill and error-prone for a simple image update; it is not the most efficient or recommended command for this task. Option C is wrong because `kubectl patch` can update the image, but the provided JSON patch is syntactically correct yet unnecessarily complex; `kubectl set image` is the simpler, more idiomatic command for this specific operation.

Practice this question →

215

Multi-Selecthard

A team is deciding how to isolate workloads across namespaces. Which two statements about Kubernetes Namespaces are accurate? (Choose two.)

Select 2 answers

A.Namespaces provide kernel-level isolation between Pods, equivalent to Linux namespaces used by containers.

B.A NetworkPolicy that selects all Pods in a namespace automatically blocks traffic from other namespaces without additional rules.

C.Deleting a Namespace triggers deletion of the resources it contains, and the Namespace stays in Terminating until finalizers complete.

D.Cluster-scoped resources such as Nodes and PersistentVolumes can be created inside any namespace for organizational clarity.

E.ResourceQuota and LimitRange are namespace-scoped objects used to cap aggregate consumption and set per-container defaults.

AnswersC, E

Namespace deletion is asynchronous: the API server marks the Namespace Terminating and removes its contents, but the object remains until all finalizers and contained resources are cleared. A stuck finalizer on a resource can leave the Namespace terminating indefinitely, which is a common operational issue. This behavior is why namespace deletion should be treated as destructive and potentially slow rather than instantaneous.

Why this answer

Namespace deletion is finalizer-gated and removes contained resources, and ResourceQuota plus LimitRange are the namespaced mechanisms for aggregate caps and per-container defaults. The other statements misstate Kubernetes Namespaces as network isolation, kernel isolation, or a container for cluster-scoped objects, none of which reflects how the API partitions resources.

Exam trap

The trap here is equating Kubernetes Namespaces with Linux namespaces, when the former is only an API-level partition.

Practice this question →

216

Multi-Selectmedium

Which THREE of the following are valid ways to expose a Service to external traffic? (Select exactly three.)

Select 3 answers

A.Ingress

B.ExternalName

C.ClusterIP

D.NodePort

E.LoadBalancer

AnswersA, D, E

Ingress satisfies external exposure by routing HTTP and HTTPS traffic from outside the cluster to Services, using host- or path-based rules defined in an Ingress resource and implemented by an ingress controller. It provides layer 7 load balancing, terminating external requests and forwarding them internally, which meets the requirement for exposing Services to external traffic.

Why this answer

Ingress (A) is correct because an Ingress resource defines HTTP/HTTPS routing rules that expose Services externally through an Ingress controller acting as a layer-7 entry point. NodePort (D) is correct because it allocates a static port on every node's IP (default range 30000-32767), making the Service reachable from outside the cluster via <NodeIP>:<NodePort>. LoadBalancer (E) is correct because it provisions an external load balancer (e.g., via a cloud provider) that distributes traffic to the Service from outside the cluster.

ExternalName (B) is not a way to expose a Service; it merely maps a Service to an external DNS name via a CNAME record without proxying traffic. ClusterIP (C) is not externally accessible since it only assigns an internal virtual IP reachable within the cluster.

Exam trap

Candidates often mistakenly think ExternalName is an external exposure method, but it only creates a DNS alias within the cluster and does not route external traffic.

Practice this question →

217

Multi-Selectmedium

Which TWO of the following are true about Kubernetes Services? (Select 2)

Select 2 answers

A.Services automatically handle Pod replication and scaling.

B.Services can distribute traffic across Pods using labels and selectors.

C.Services can only expose Pods internally within the cluster.

D.Services provide a stable IP address and DNS name for a set of Pods.

E.Services are required for Pods to have persistent storage.

AnswersB, D

A Service uses label selectors to match a dynamic set of Pod endpoints, then load-balances traffic across them as Pods are added or removed. This satisfies the stem's requirement that Services distribute traffic using labels and selectors rather than fixed IP addresses.

Why this answer

Option B is correct because a Kubernetes Service uses label selectors to identify the set of backing Pods (typically via Endpoints/EndpointSlices) and load-balances traffic across them, providing a single access point regardless of how many Pod replicas exist. Option D is correct because a Service is assigned a stable virtual IP (ClusterIP) and a DNS name (e.g., my-svc.my-namespace.svc.cluster.local) that remain constant even as the underlying Pods are created, deleted, or rescheduled with new IPs. Option A is wrong because replication and scaling are handled by controllers such as ReplicaSets or Deployments, not by Services.

Option C is wrong because Services can also be exposed externally via NodePort, LoadBalancer, or ExternalName types, not only internally. Option E is wrong because persistent storage is provided by PersistentVolumes and PersistentVolumeClaims, which are independent of Services.

Exam trap

A common misconception is that Services handle Pod scaling or replication; in fact, Services only provide stable networking and load balancing to a set of Pods selected by labels.

Practice this question →

218

MCQeasy

A team wants a single stable IP address and DNS name that load-balances traffic across a changing set of backend Pods. The Pods are managed by a Deployment and are regularly replaced during rollouts. Which Kubernetes object should they create to provide this stable virtual IP and DNS entry?

A.A NetworkPolicy

B.A ConfigMap

C.An Ingress resource

D.A Service of type ClusterIP

AnswerD

A ClusterIP Service is assigned a stable virtual IP and a DNS name, and it selects backend Pods by label. As Pods are created or deleted during rollouts, the Service's Endpoints or EndpointSlices are updated, so clients keep using the same address. This directly meets the requirement for stable load-balanced access to a dynamic Pod set.

Why this answer

A Service abstracts a set of Pods behind a stable virtual IP and DNS name, and its label selector keeps the backend list current as Pods come and go. ClusterIP is the default type and is ideal for internal access. Ingress, NetworkPolicy, and ConfigMap serve routing, security, and configuration purposes respectively, and none of them supplies a stable virtual IP for a dynamic Pod set.

Exam trap

The trap here is assuming Ingress replaces a Service, when Ingress normally routes to a Service that provides the stable virtual IP.

Practice this question →

219

MCQmedium

A cluster administrator needs to run a node-level logging agent on every node, including nodes added later. The agent must collect logs from the host filesystem and must run even if a node is cordoned. Which workload resource should be used?

A.A StatefulSet with one replica per node

B.A Job with a parallelism equal to the number of nodes

C.A Deployment with a nodeSelector matching each node's label

D.A DaemonSet

AnswerD

A DaemonSet ensures that a copy of a pod runs on every node in the cluster, and it automatically schedules pods onto nodes added later. Its pods are created by the DaemonSet controller with tolerations that allow them to run on nodes that are cordoned or have standard taints, making it the correct choice for node-level agents such as log collectors.

Why this answer

DaemonSets are purpose-built for per-node workloads. The DaemonSet controller creates a pod on each eligible node and adds new pods when nodes join the cluster. Its default tolerations allow the pods to run on nodes that are unschedulable or carry common taints, which is essential for infrastructure agents like log shippers, monitoring exporters, and CNI plugins that must operate everywhere.

Exam trap

The trap here is choosing a Deployment with a nodeSelector, which can place pods on labeled nodes but does not guarantee one pod per node or cover nodes added later.

Practice this question →

220

MCQmedium

An administrator needs to run a stateful database in Kubernetes that requires a stable network identity, persistent storage that survives pod rescheduling, and ordered deployment and scaling. Which Kubernetes resource should be used to meet these requirements?

A.StatefulSet

B.ReplicaSet

C.Deployment

D.DaemonSet

AnswerA

StatefulSet is designed for stateful applications, providing stable, unique network identifiers (pod name and headless Service), persistent storage through volumeClaimTemplates, and ordered, graceful deployment and scaling. It satisfies the need for a stable identity and durable storage across rescheduling, making it the correct choice for a stateful database.

Why this answer

StatefulSet is the only workload resource that provides stable network identities, persistent storage per replica, and ordered deployment and scaling. Deployments, DaemonSets, and ReplicaSets are designed for stateless or node-wide workloads and do not offer these guarantees. For a stateful database, StatefulSet is the correct and standard Kubernetes solution.

Exam trap

The trap here is assuming that any workload controller can manage stateful applications, when only StatefulSet provides stable identities and persistent storage per pod.

Practice this question →

221

MCQmedium

A pod is stuck in 'Pending' state. After running 'kubectl describe pod', you see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?

A.The pod's CPU request exceeds the available CPU on all nodes

B.The pod is exceeding its memory limit

C.The network plugin is not installed

D.The container image is too large

AnswerA

The scheduler's predicate phase filters nodes by the pod's CPU request against each node's allocatable capacity. All three nodes fail that filter, so no feasible node remains and the pod stays unscheduled. Raising requests or adding capacity resolves it.

Why this answer

The pod is stuck in 'Pending' state because the Kubernetes scheduler cannot find a node that satisfies the pod's resource requirements. The event '0/3 nodes are available: 3 Insufficient cpu' explicitly indicates that every node in the cluster lacks sufficient allocatable CPU capacity to meet the pod's CPU request. This means the sum of CPU requests across all pods on each node, plus the new pod's request, exceeds the node's CPU capacity, causing the scheduler to leave the pod unscheduled.

Exam trap

A common mistake in Kubernetes is confusing resource requests (used for scheduling) with resource limits (used for runtime enforcement). Candidates may incorrectly think a pod stuck in 'Pending' is due to exceeding a limit rather than an unsatisfied request.

How to eliminate wrong answers

Option B is wrong because exceeding a memory limit causes a pod to be terminated (OOMKilled) or restarted, not stuck in 'Pending' state; 'Pending' relates to scheduling, not runtime resource limits. Option C is wrong because a missing network plugin (e.g., CNI) would cause pods to fail with 'CrashLoopBackOff' or 'ContainerCreating' errors, not a scheduling failure due to insufficient CPU. Option D is wrong because a large container image affects image pull time and can cause 'ImagePullBackOff' or 'ErrImagePull' events, but does not prevent the scheduler from assigning the pod to a node; the pod would still be scheduled and then fail during container creation.

Practice this question →

222

MCQmedium

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerB

etcd is the distributed key-value store that holds all cluster state, including object definitions, configuration and metadata. The API server reads and writes exclusively through it, making etcd the sole control plane component responsible for persisting the entire cluster state.

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.) and their desired and current status. The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes are persisted durably and consistently. Without etcd, the cluster would have no record of its configuration or running workloads.

Exam trap

A common trap is to think the kube-apiserver persists state because it is the central API gateway, but in reality, the API server is stateless and relies entirely on etcd for durable storage.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the API server and makes changes to move the current state toward the desired state; it does not persist any data itself. Option C 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 store data locally. Option D is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints; it reads cluster state from the API server but never writes or persists any state.

Practice this question →

223

MCQmedium

A team is designing a Kubernetes cluster for a production workload that requires high availability. They have three worker nodes in different availability zones. Which statement about scheduling Pods is correct?

A.Use nodeSelector to assign Pods to nodes in different zones.

B.Add tolerations for the zone taint.

C.Use podAntiAffinity with a requiredDuringSchedulingIgnoredDuringExecution rule.

D.Define a Pod topology spread constraint with topologyKey: topology.kubernetes.io/zone.

AnswerD

A topology spread constraint with topologyKey topology.kubernetes.io/zone distributes Pods across availability zones, so replicas are not concentrated in one zone. This satisfies the high-availability requirement by ensuring zone-level failure does not take down every Pod.

Why this answer

A Pod topology spread constraint with `topologyKey: topology.kubernetes.io/zone` explicitly instructs the scheduler to distribute Pods evenly across the specified failure domains (availability zones). This ensures that if one zone fails, the remaining zones still have running Pods, achieving high availability for the production workload.

Exam trap

The KCNA exam often tests the distinction between mechanisms that merely allow placement (tolerations, nodeSelector) versus those that enforce distribution (topology spread constraints), leading candidates to confuse permission with active scheduling policy.

How to eliminate wrong answers

Option A is wrong because `nodeSelector` only matches Pods to nodes with specific labels, but it does not enforce distribution across zones; Pods could still be scheduled on a single zone if all matching nodes are there. Option B is wrong because tolerations allow Pods to be scheduled on tainted nodes (e.g., zone-specific taints), but they do not guarantee spread across zones; they merely permit scheduling on nodes that would otherwise repel the Pod. Option C is wrong because `podAntiAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` prevents Pods from being co-located on the same node (or topology), but it does not ensure balanced distribution across zones; it only avoids placing replicas together, which could still result in all replicas landing in one zone if only one zone has enough nodes.

Practice this question →

224

Multi-Selecteasy

Which TWO components run on every worker node in a Kubernetes cluster?

Select 2 answers

A.kube-scheduler

B.kubelet

C.etcd

D.kube-proxy

E.kube-apiserver

AnswersB, D

The kubelet runs as an agent on every worker node, receiving PodSpecs from the control plane and ensuring the described containers are running and healthy via the container runtime. It is a node-level, not control-plane, component.

Why this answer

kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles by ensuring containers described in PodSpecs are running and healthy. kube-proxy (D) is also correct because it runs on every worker node to maintain network rules (via iptables, IPVS, or nftables) that implement Kubernetes Service abstraction and enable pod-to-pod and external communication. In contrast, kube-scheduler (A), etcd (C), and kube-apiserver (E) are control plane components that typically run on master/control-plane nodes, not on every worker node, so they do not belong in this answer.

Exam trap

CNCF often tests the distinction between control plane components and worker node components, trapping candidates who assume that all core Kubernetes components (like kube-scheduler or etcd) run on every node.

Practice this question →

225

Matchingmedium

Match each cloud native concept to its definition.

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

Concepts

Matches

Lightweight, standalone executable package that includes everything needed

Architectural style that structures an app as a collection of loosely coupled services

Automated configuration, coordination, and management of containers

Approach where servers are never modified after deployment; replaced instead

Specifying the desired state, letting the system achieve and maintain it

Why these pairings

The correct matches are: Microservices with loosely coupled services, Service Mesh with service-to-service communication, Serverless with cloud provider managing resources, and Orchestration with automated management. Common confusions include swapping definitions between Microservices and Service Mesh, or between Serverless and Orchestration.

Practice this question →