CCNA Kcna Kubernetes Fundamentals Questions — Page 3 of 5

151

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 lists pods with name, ready status, and other columns.

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 →

152

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

Pods are the smallest and most basic deployable objects.

Why this answer

A Pod is the smallest and most fundamental deployable unit in Kubernetes. It represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. You cannot deploy a container directly; you must always wrap it in a Pod.

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 →

153

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 defines rules for allowed ingress and egress traffic between pods based on pod labels, namespaces, or IP blocks.

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 →

154

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

The controller manager runs controllers that implement reconciliation loops to ensure the actual state matches the desired state.

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 →

155

Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

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 →

156

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

Yes, etcd is a control plane component.

Why this answer

etcd is a distributed key-value store that holds the cluster's state and configuration data, making it a core control plane component. The kube-apiserver is the front-end for the Kubernetes control plane, exposing the Kubernetes API and handling all RESTful requests to manage the cluster. Both are essential for cluster management and orchestration, not for running application workloads.

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 →

157

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

The liveness probe restart the container to recover from a deadlock.

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 →

158

MCQhard

You want to create a new Namespace called 'staging' and apply a ResourceQuota to it. Which of the following YAML snippets correctly defines a ResourceQuota that limits total memory to 10Gi and total CPU to 5 cores in namespace 'staging'?

A.apiVersion: v1\nkind: ResourceQuota\nmetadata:\n name: staging-quota\n namespace: staging\nspec:\n hard:\n requests.cpu: "5"\n requests.memory: 10Gi

B.apiVersion: v1\nkind: ResourceQuota\nmetadata:\n name: staging-quota\n namespace: staging\nspec:\n hard:\n limits.cpu: "5"\n limits.memory: 10Gi

C.apiVersion: v1\nkind: LimitRange\nmetadata:\n name: staging-limits\n namespace: staging\nspec:\n limits:\n - default:\n cpu: 5\n memory: 10Gi\n defaultRequest:\n cpu: 1\n memory: 1Gi

D.apiVersion: v1\nkind: ResourceQuota\nmetadata:\n name: staging-quota\nspec:\n hard:\n cpu: 5\n memory: 10Gi

AnswerB

Correct syntax for ResourceQuota.

Why this answer

It defines a ResourceQuota with `limits.cpu` and `limits.memory` under `spec.hard`, which restricts the total CPU and memory that all pods in the namespace can consume. The values are specified as strings ("5" for CPU and 10Gi for memory), which is the correct format for ResourceQuota resources in Kubernetes.

Exam trap

The exam often tests the distinction between ResourceQuota (namespace-wide aggregate limits) and LimitRange (per-container defaults), and the requirement to specify `limits.cpu`/`limits.memory` (not just `cpu`/`memory`) in the ResourceQuota spec to target the actual resource limits.

How to eliminate wrong answers

Option A is wrong because it uses `requests.cpu` and `requests.memory` instead of `limits.cpu` and `limits.memory`, which would only limit the total requested resources, not the actual limits that pods can use. Option C is wrong because it defines a LimitRange, not a ResourceQuota; LimitRange sets default resource requests/limits per container, not aggregate namespace-wide quotas. Option D is wrong because it omits the `namespace` field in metadata, so the ResourceQuota would not be applied to the 'staging' namespace; also, the syntax `cpu: 5` and `memory: 10Gi` without the `limits.` prefix is ambiguous and not the standard way to specify resource quotas.

Practice this question →

159

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 provide logical isolation.

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 →

160

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 use label selectors to route traffic to matching Pods.

Why this answer

A Kubernetes Service uses a label selector to identify which Pods should receive traffic. When a Service is created with a selector matching certain labels, the endpoint controller dynamically updates the Service's Endpoints object to include the IP addresses of all Pods with those labels, enabling traffic routing.

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 →

161

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 wrap API calls.

Why this answer

Client-go is an official Kubernetes client library that provides Go developers with programmatic access to the Kubernetes API. It handles authentication, serialization, and API version negotiation, allowing applications to create, read, update, and delete Kubernetes resources directly via the 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 →

162

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 can allow or deny traffic between namespaces when properly configured.

Why this answer

B is correct because NetworkPolicy resources can define ingress and egress rules that allow or deny traffic between pods based on labels, and these rules can explicitly target pods in other namespaces using the namespaceSelector field. This enables fine-grained network segmentation across namespace boundaries, which is a common requirement for multi-tenant clusters.

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 →

163

MCQeasy

What is the primary purpose of a Kubernetes Service?

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

B.To manage rolling updates of Pods

C.To schedule Pods onto Nodes

D.To store configuration data for Pods

AnswerA

A Service enables other components to access Pods reliably, even as Pods change.

Why this answer

A Service provides a stable endpoint for a set of Pods, enabling discovery and load balancing across them.

Practice this question →

164

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 opens a static port on each node's IP.

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 →

165

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

The Endpoints Controller populates Endpoints objects based on Service selectors.

Why this answer

The kube-controller-manager includes the EndpointSlice controller (or the legacy Endpoints controller), which is responsible for creating and updating Endpoints (and EndpointSlice) objects to reflect the IP addresses and ports of Pods that match a Service's label selector. This ensures that the Service's DNS or iptables rules point to healthy Pods.

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 →

166

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 allows the ReplicaSet to maintain multiple copies, so if one crashes, others still serve traffic.

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 →

167

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

Pods are the atomic unit of deployment in Kubernetes.

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 →

168

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 sends node status updates to the API server.

Why this answer

The kubelet is the primary node agent that registers the node with the Kubernetes control plane and periodically reports the node's status, including conditions like Ready, DiskPressure, and MemoryPressure, via the NodeStatus API. This heartbeat mechanism allows the control plane to maintain an accurate view of cluster health and node availability.

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 →

169

MCQeasy

A Pod has two containers. You need to see the logs of the second container named 'sidecar'. Which kubectl command should you use?

A.kubectl logs pod-name --container sidecar

B.kubectl logs sidecar pod-name

C.kubectl logs pod-name sidecar

D.kubectl logs pod-name -c sidecar

AnswerA

Uses the --container flag to specify the sidecar container, which is correct.

Why this answer

The command `kubectl logs pod-name --container sidecar` (option A) explicitly specifies the sidecar container. While `-c sidecar` is also a valid shorthand, this question expects the command as listed in option A. Both forms achieve the same result, but in this single-choice format, option A is the designated correct answer.

Exam trap

A common mistake is to think that only the `-c` flag is valid; however, `--container` is equally valid. For this question, note that the correct choice is the `--container` flag form.

How to eliminate wrong answers

Option A is wrong because `--container sidecar` is not a valid flag; the correct flag is `-c sidecar` or `--container=sidecar`. Option B is wrong because the syntax `kubectl logs sidecar pod-name` reverses the expected order — the container name must follow the `-c` flag, not precede the pod name. Option C is wrong because `kubectl logs pod-name sidecar` treats `sidecar` as a second positional argument, which is not supported; the container name must be specified with the `-c` flag.

Practice this question →

170

MCQhard

A user wants to ensure that a Deployment undergoes a rolling update with zero downtime, and that new Pods are fully ready before old Pods are terminated. Which field in the Deployment spec controls this behavior?

A.spec.minReadySeconds

B.spec.strategy.rollingUpdate.maxUnavailable and maxSurge

C.spec.replicas

D.spec.template.spec.containers[].resources

AnswerB

These fields control how many Pods can be unavailable and how many can be created above the desired count during a rolling update.

Why this answer

`spec.strategy.rollingUpdate.maxUnavailable` and `maxSurge` control how many Pods can be unavailable and how many can be created above the desired count during a rolling update. Setting `maxUnavailable=0` ensures no old Pods are terminated until new Pods are fully ready, achieving zero-downtime updates. `maxSurge` allows extra Pods to be created before old ones are removed, enabling a controlled rollout.

Exam trap

CNCF often tests the misconception that `minReadySeconds` controls the rolling update order, but it only affects the Pod's availability status after readiness, not the termination timing of old Pods.

How to eliminate wrong answers

Option A is wrong because `spec.minReadySeconds` defines the minimum time a Pod must be ready before it is considered available, but it does not control the order or parallelism of Pod termination during a rolling update. Option C is wrong because `spec.replicas` sets the desired number of Pod replicas but has no direct influence on the update strategy or the readiness check before terminating old Pods. Option D is wrong because `spec.template.spec.containers[].resources` defines CPU and memory requests/limits for containers, which affects scheduling but not the rolling update behavior or Pod readiness gating.

Practice this question →

171

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

nodeSelector ensures the pod is scheduled only on nodes with the matching label.

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 →

172

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 provides HTTP/HTTPS routing to services.

Why this answer

Ingress is correct because it provides HTTP/HTTPS routing rules to expose Services externally, typically using a reverse proxy like NGINX or HAProxy. It operates at Layer 7, allowing host and path-based routing to multiple Services behind a single external endpoint, which is a valid way to expose traffic.

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 →

173

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

Services use label selectors to target Pods.

Why this answer

Kubernetes Services use label selectors to identify a set of Pods and then distribute incoming traffic to those Pods. This is the core mechanism that decouples the Service from the specific Pod instances, enabling load balancing and dynamic routing.

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 →

174

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Deployment

B.Node

C.Pod

D.Container

AnswerC

A Pod is the smallest deployable unit in Kubernetes.

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 they think of Docker containers, but Kubernetes abstracts containers into Pods to enforce resource sharing and lifecycle management.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods; it is not the smallest deployable unit. Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster that hosts Pods, not a deployable unit itself. Option D is wrong because a Container is the runtime environment for an application, but Kubernetes does not deploy containers directly; it wraps them inside a Pod to provide shared networking and storage context.

Practice this question →

175

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 reports insufficient CPU resources.

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 →

176

MCQeasy

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

A.Container

B.Node

C.Pod

D.Deployment

AnswerC

A Pod is the smallest deployable unit that can be created and managed.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto Nodes; instead, Kubernetes always schedules and manages Pods, making the Pod the atomic unit of deployment.

Exam trap

CNCF often tests the misconception that a Container is the smallest unit because candidates come from Docker backgrounds, but Kubernetes abstracts containers into Pods as the fundamental scheduling and deployment atom.

How to eliminate wrong answers

Option A is wrong because a Container is not a standalone deployable unit in Kubernetes; containers are always wrapped inside a Pod and cannot be created or scheduled directly by the API server. Option B is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, but it is not a deployable unit — you do not deploy a Node; you deploy Pods onto Nodes. Option D is wrong because a Deployment is a higher-level controller that manages the desired state and lifecycle of ReplicaSets and Pods, but it is not the smallest unit — it orchestrates Pods, which are the actual deployable entities.

Practice this question →

177

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 stores all cluster data.

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 →

178

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

Topology spread constraints explicitly spread Pods across zones for high availability.

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 →

179

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

kubelet is the primary node agent that ensures containers are running in a Pod.

Why this answer

The kubelet is the primary node agent that runs on every worker node, responsible for managing pod lifecycle and ensuring containers are running as expected. kube-proxy runs on every node to handle network routing and load balancing for Kubernetes services, implementing rules via iptables or IPVS.

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 →

180

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 →

181

MCQeasy

Which component of the control plane is the only one that directly interacts with etcd?

A.kube-apiserver

B.kube-controller-manager

C.kube-scheduler

D.kubelet

AnswerA

The API server is the only component that directly reads and writes to etcd.

Why this answer

The kube-apiserver is the only component of the Kubernetes control plane that directly interacts with etcd. It acts as the front-end for the control plane, exposing the Kubernetes API, and all reads and writes to the cluster's state stored in etcd must go through the API server. Other components like the kube-controller-manager and kube-scheduler only communicate with etcd indirectly via the kube-apiserver, never directly.

Exam trap

The trap here is that candidates often assume the kube-controller-manager or kube-scheduler directly access etcd because they manage cluster state, but in reality they only interact with etcd indirectly through the kube-apiserver.

How to eliminate wrong answers

Option B is wrong because the kube-controller-manager watches and reconciles cluster state by making API calls to the kube-apiserver, not by directly querying or writing to etcd. Option C is wrong because the kube-scheduler assigns pods to nodes by communicating with the kube-apiserver to update pod bindings, and it never directly accesses etcd. Option D is wrong because kubelet is a node-level agent that interacts only with the kube-apiserver (e.g., to report node status or watch for pod assignments) and has no direct connection to etcd.

Practice this question →

182

Multi-Selectmedium

Which TWO of the following are valid uses of Kubernetes Namespaces? (Select 2)

Select 2 answers

A.Setting CPU and memory limits at the namespace level

B.Enforcing network policies per namespace

C.Providing logical separation between different environments (e.g., dev, staging, prod) within the same cluster

D.Isolating node resources for different workloads

E.Enabling RBAC authentication for users in a namespace

AnswersB, C

NetworkPolicies can be applied within a namespace to control traffic between pods.

Why this answer

Kubernetes NetworkPolicies are namespace-scoped resources that allow you to define ingress and egress traffic rules for pods within a specific namespace. By applying a NetworkPolicy to a namespace, you can isolate workloads from each other, controlling which pods can communicate based on labels and ports, which is a fundamental use of namespaces for security and segmentation.

Exam trap

CNCF often tests the misconception that namespaces can enforce resource limits directly, when in fact ResourceQuotas and LimitRanges are the mechanisms that operate within a namespace, not the namespace itself.

Practice this question →

183

MCQeasy

Which command is used to view detailed information about a specific pod, including events and conditions?

A.kubectl logs pod

B.kubectl describe pod

C.kubectl exec pod

D.kubectl get pod

AnswerB

This command shows detailed information about a specific pod.

Why this answer

The `kubectl describe pod` command retrieves detailed information about a specific pod, including its current state, metadata, labels, annotations, container details, resource limits, and a chronological list of events and conditions (e.g., PodScheduled, Initialized, Ready, ContainersReady). This makes it the correct tool for viewing comprehensive pod status and lifecycle events.

Exam trap

The trap here is that candidates often confuse `kubectl get pod` (which shows a summary) with `kubectl describe pod` (which shows full details and events), leading them to choose the 'get' option when the question explicitly asks for 'detailed information including events and conditions'.

How to eliminate wrong answers

Option A is wrong because `kubectl logs pod` only streams or retrieves the console output (stdout/stderr) from a container within a pod, not the pod's metadata, conditions, or events. Option C is wrong because `kubectl exec pod` runs a command inside a container of the pod for interactive debugging, not for viewing pod details or events. Option D is wrong because `kubectl get pod` outputs a concise, tabular summary of pods (name, status, restarts, age) without the detailed conditions, events, or full configuration that `describe` provides.

Practice this question →

184

MCQhard

In a YAML manifest for a Deployment, which field defines the number of pod replicas?

A.spec.strategy.replicas

B.metadata.replicas

C.spec.replicas

D.spec.template.replicas

AnswerC

spec.replicas is the correct field for setting the number of replicas.

Why this answer

In a Kubernetes Deployment manifest, the `spec.replicas` field is the correct place to define the desired number of pod replicas. This field is a top-level attribute under the Deployment's `spec` object, and the ReplicaSet controller uses this integer value to ensure the specified number of Pods are running at all times.

Exam trap

The trap here is that candidates confuse the `spec.replicas` field with `spec.template` or `metadata`, or incorrectly assume that replica count is nested under `strategy` or `template`, leading them to pick A, B, or D.

How to eliminate wrong answers

Option A is wrong because `spec.strategy.replicas` does not exist; the `strategy` field defines the update strategy (e.g., RollingUpdate or Recreate), not replica count. Option B is wrong because `metadata.replicas` is not a valid field; `metadata` contains labels, annotations, and the resource name, not replica configuration. Option D is wrong because `spec.template.replicas` is invalid; the `template` field describes the Pod template (e.g., containers, volumes) and does not include a replicas field.

Practice this question →

185

MCQhard

You have a Deployment with the following rollout strategy: rollingUpdate: maxSurge: 1, maxUnavailable: 0. What behavior does this configuration enforce?

A.The rollout will terminate all old pods at once and then create new ones

B.The rollout will create all new pods first, then delete all old pods

C.The rollout will terminate one old pod before creating a new one

D.The rollout will create one additional pod before terminating the old pod, ensuring zero downtime

AnswerD

This strategy ensures at least desired replicas are always running.

Why this answer

The rolling update strategy `maxSurge: 1, maxUnavailable: 0` ensures that during the rollout, one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees that the total number of available pods never drops below the desired count, achieving zero downtime. The `maxUnavailable: 0` setting prevents any pod from being taken down until a new one is ready, while `maxSurge: 1` allows one extra pod to be created temporarily.

Exam trap

The trap in this question is that candidates often mistakenly think 'maxSurge: 1, maxUnavailable: 0' allows one old pod to be terminated before a new one starts (like a 'one-by-one' strategy). In reality, 'maxUnavailable: 0' forces a new pod to be created and become ready before any existing pod is removed, ensuring zero downtime. This is Kubernetes-specific and differs from simpler rolling update strategies.

How to eliminate wrong answers

Option A is wrong because terminating all old pods at once would violate `maxUnavailable: 0`, which explicitly prohibits any pods from being unavailable during the update. Option B is wrong because creating all new pods first would exceed the `maxSurge: 1` limit, which only allows one extra pod above the desired count, not a full parallel creation. Option C is wrong because terminating one old pod before creating a new one would temporarily reduce the available pod count below the desired replicas, violating `maxUnavailable: 0`; the correct behavior is to create a new pod first (surge) before terminating the old one.

Practice this question →

186

MCQhard

You have a Service of type ClusterIP named 'my-svc' in the 'default' namespace. A Pod in the same cluster wants to reach this Service using DNS. What is the fully qualified domain name (FQDN) that resolves to the Service's cluster IP?

A.my-svc.default.svc.cluster.local

B.my-svc.default.cluster.local

C.default.my-svc.svc.cluster.local

D.my-svc.svc.default.cluster.local

AnswerA

Correct format: <service>.<namespace>.svc.cluster.local.

Why this answer

The standard DNS naming convention for a Kubernetes Service is `<service-name>.<namespace>.svc.cluster.local`. This FQDN resolves to the ClusterIP of the Service, allowing Pods to discover and communicate with the Service using DNS. The `svc` subdomain is a fixed part of the cluster domain, and `cluster.local` is the default cluster domain suffix.

Exam trap

The trap here is that candidates often forget the `svc` subdomain or mix up the order of service name and namespace, leading them to choose options that omit `svc` or reverse the components, which Cisco tests to see if you know the exact DNS format for Kubernetes Services.

How to eliminate wrong answers

Option B is wrong because it omits the required `svc` subdomain, which is part of the standard Kubernetes DNS schema; without `svc`, the DNS query will not match the Service record. Option C is wrong because it reverses the order of the service name and namespace, placing the namespace first, which does not follow the `<service>.<namespace>.svc.cluster.local` format. Option D is wrong because it places `svc` after the namespace instead of before it, and also incorrectly orders the components; the correct structure is `<service>.<namespace>.svc.cluster.local`.

Practice this question →

187

MCQhard

You have a Service named 'my-svc' in namespace 'default'. A pod in namespace 'other' tries to reach it using the DNS name 'my-svc'. What is the correct DNS name for cross-namespace service discovery?

A.my-svc

B.my-svc.default

C.my-svc.other

D.my-svc.namespace

AnswerB

Why this answer

Kubernetes DNS resolves service names using the format `<service>.<namespace>.svc.cluster.local`. For cross-namespace access, the namespace must be included. Since the pod is in namespace 'other' and the service is in 'default', the correct DNS name is 'my-svc.default' (the full cluster domain suffix is optional).

Exam trap

The trap here is that candidates assume a bare service name works globally across namespaces, forgetting that Kubernetes DNS scopes short names to the pod's own namespace.

How to eliminate wrong answers

Option A is wrong because a bare service name like 'my-svc' only resolves within the same namespace; a pod in namespace 'other' would get a DNS lookup failure or a different service. Option C is wrong because 'my-svc.other' would look for a service named 'my-svc' in namespace 'other', not in 'default'. Option D is wrong because 'my-svc.namespace' is not a valid Kubernetes DNS pattern; the literal word 'namespace' is not substituted—the actual namespace name must be used.

Practice this question →

188

MCQmedium

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

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolume

AnswerC

ConfigMaps store non-sensitive configuration.

Why this answer

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

Exam trap

Kubernetes often tests the distinction between ConfigMap and Secret, trapping candidates who assume all configuration data must be stored in Secrets, ignoring that ConfigMap is the correct choice for non-sensitive data.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed to store sensitive data (e.g., passwords, tokens, SSH keys) and is base64-encoded, not plaintext, making it unsuitable for non-sensitive configuration. Option B is wrong because ServiceAccount is an identity object used to control pod-level authentication to the Kubernetes API, not for storing configuration data. Option D is wrong because PersistentVolume is a storage resource that provides persistent storage volumes to pods, not a mechanism for injecting configuration data like key-value pairs or files.

Practice this question →

189

MCQmedium

A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?

A.The update pauses, keeping the remaining old replicas running

B.The entire update is rolled back and all old pods are deleted

C.The Deployment automatically rolls back to the previous image

D.The failed pod is terminated and not retried

AnswerA

The rolling update stops when a new pod fails, ensuring availability of old pods.

Why this answer

By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.

Exam trap

The KCNA exam often tests the misconception that a failed pod in a rolling update triggers an automatic rollback or deletion, when in fact the default behavior is to pause the update and keep old replicas running until the issue is resolved manually.

How to eliminate wrong answers

Option B is wrong because the Deployment does not automatically roll back or delete old pods; it only pauses the rollout, leaving old replicas running. Option C is wrong because a failed pod does not trigger an automatic rollback to the previous image; rollback requires manual intervention or a specific `kubectl rollout undo` command. Option D is wrong because the failed pod is not simply terminated and not retried; the ReplicaSet controller will retry creating the pod indefinitely (with exponential backoff) until the image issue is resolved or the rollout is manually paused.

Practice this question →

190

MCQhard

A ClusterIP Service named 'db-service' in namespace 'prod' selects pods with label 'app: database'. A pod in the same cluster needs to reach this service using DNS. What is the fully qualified domain name (FQDN) for the service?

A.db-service.cluster.local

B.db-service.prod.svc.cluster.local

C.db-service.svc.cluster.local

D.db-service.prod.cluster.local

AnswerB

This is the standard FQDN for a Service.

Why this answer

The correct FQDN for a Kubernetes Service follows the pattern <service-name>.<namespace>.svc.cluster.local. Since the 'db-service' ClusterIP Service is in the 'prod' namespace, the FQDN is 'db-service.prod.svc.cluster.local'. This allows any pod in the cluster to resolve the service's cluster IP via DNS, using the cluster domain 'cluster.local' by default.

Exam trap

The trap here is that candidates often forget the 'svc' subdomain or the namespace component, leading them to pick options like 'db-service.cluster.local' or 'db-service.svc.cluster.local', which are only valid for services in the default namespace or are incomplete.

How to eliminate wrong answers

Option A is wrong because it omits the namespace and the 'svc' subdomain, resulting in 'db-service.cluster.local', which is not a valid Kubernetes service DNS name. Option C is wrong because it includes 'svc' but omits the namespace 'prod', leading to 'db-service.svc.cluster.local', which would only work if the service were in the 'default' namespace. Option D is wrong because it uses 'prod.cluster.local' instead of 'prod.svc.cluster.local', missing the mandatory 'svc' component that distinguishes service DNS records from pod DNS records.

Practice this question →

191

Multi-Selectmedium

Which TWO statements about Kubernetes namespaces are true?

Select 2 answers

A.All Kubernetes objects are namespaced.

B.Namespaces automatically isolate services in different namespaces from communicating.

C.Namespaces provide network isolation between pods by default.

D.Namespaces are used to divide cluster resources between multiple users or teams.

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

AnswersD, E

Correct; namespaces provide logical isolation.

Why this answer

Namespaces are a fundamental mechanism in Kubernetes for dividing cluster resources among multiple users or teams, enabling multi-tenancy and resource management through policies like Role-Based Access Control (RBAC) and ResourceQuotas. Option E is correct because ResourceQuotas are Kubernetes objects that can be applied to a namespace to enforce aggregate limits on CPU, memory, and other resources, preventing any single team from exhausting cluster capacity.

Exam trap

The trap here is that candidates confuse namespaces with network isolation, assuming that simply placing resources in different namespaces automatically blocks cross-namespace traffic, when in fact Kubernetes allows all pod-to-pod communication across namespaces by default and requires explicit NetworkPolicy rules to restrict it.

Practice this question →

192

MCQmedium

A developer wants to run a stateless web application with 5 replicas and ensure that when a new version is released, Pods are updated one by one with no downtime. Which Kubernetes resource is best suited?

A.Job

B.DaemonSet

C.StatefulSet

D.Deployment

AnswerD

Deployment manages replicas and supports rolling updates.

Why this answer

A Deployment is the correct resource because it is designed for managing stateless, replicated applications with declarative updates. It supports rolling updates (configurable via `strategy.type: RollingUpdate`), which update Pods one by one, ensuring zero downtime by gradually replacing old Pods with new ones while maintaining the desired replica count.

Exam trap

The trap here is that candidates may confuse StatefulSet with Deployment because both support rolling updates, but StatefulSet is specifically for stateful workloads requiring ordered Pod identity and persistent storage, not for stateless web apps where Pods are ephemeral and interchangeable.

How to eliminate wrong answers

Option A is wrong because a Job is used for running batch or one-off tasks to completion, not for continuously running stateless web applications or managing rolling updates. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes), which is intended for node-level services like logging or monitoring, not for scaling a stateless web app with a fixed replica count. Option C is wrong because a StatefulSet is designed for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), and its rolling update behavior is more conservative (e.g., ordered, graceful shutdown) but it is not the best fit for a stateless web app where Pods are interchangeable.

Practice this question →

193

Multi-Selecteasy

Which TWO of the following are characteristics of a Kubernetes Pod?

Select 2 answers

A.Pods can only run a single container

B.Pods are the smallest deployable units in Kubernetes

C.Containers within a Pod share the same network namespace

D.Pods are designed to be long-lived and rarely replaced

E.Pods are typically replicated by a Deployment or ReplicaSet

AnswersB, C

Pods are the atomic unit of scheduling.

Why this answer

B is correct because Pods are the smallest and most fundamental deployable units in Kubernetes, representing a single instance of a running process in the cluster. A Pod encapsulates one or more containers, storage resources, and a unique network IP, and is the atomic unit of scheduling. This is defined in the Kubernetes core API and is a foundational concept for the KCNA exam.

Exam trap

CNCF often tests the misconception that Pods are long-lived or that they can only run a single container, confusing Pods with virtual machines or containers themselves, while the key exam point is that Pods are the smallest deployable unit and share network namespaces.

Practice this question →

194

MCQmedium

You run 'kubectl get pods' and see a pod with status 'Pending'. Which is the most likely cause?

A.The pod's container has crashed

B.The scheduler cannot find a node that meets the pod's resource requirements

C.The container image is not found

D.The pod has been deleted by a controller

AnswerB

Pending often means the scheduler is unable to place the pod due to resource constraints.

Why this answer

A pod with status 'Pending' indicates that the pod has been accepted by the cluster but is not yet running. The most common cause is that the Kubernetes scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other constraints (node selector, taints/tolerations, affinity rules). The scheduler continuously evaluates nodes and if none match, the pod remains in Pending state until a suitable node becomes available.

Exam trap

The CNCF's KCNA exam often tests the distinction between pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) and common error states (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate 'Pending' with image or runtime issues rather than scheduling failures.

How to eliminate wrong answers

Option A is wrong because a container crash would result in a 'CrashLoopBackOff' or 'Error' status, not 'Pending'. Option C is wrong because an unfound container image would cause an 'ImagePullBackOff' or 'ErrImagePull' status, not 'Pending'. Option D is wrong because if a pod is deleted by a controller, it would simply disappear from the list; 'Pending' is a lifecycle phase before the pod is scheduled, not a deletion state.

Practice this question →

195

MCQhard

A cluster administrator wants to ensure that a specific pod only runs on nodes that have an SSD for local storage. The nodes with SSDs have the label 'disk-type: ssd'. How should the administrator configure the pod to enforce this constraint?

A.Add a toleration for node.kubernetes.io/disk-type: ssd

B.Add a nodeSelector with 'disk-type: ssd' to the pod spec

C.Use a readiness probe to check for SSD

D.Add an annotation 'disk-type: ssd' to the pod

AnswerB

nodeSelector is the simplest way to constrain a pod to nodes with specific labels.

Why this answer

The `nodeSelector` field in a Pod spec is the standard Kubernetes mechanism for constraining a Pod to run only on nodes that match specific labels. By setting `nodeSelector: { disk-type: ssd }`, the scheduler will ensure the Pod is placed exclusively on nodes with that label, enforcing the administrator's requirement.

Exam trap

The trap here is that candidates confuse tolerations (for taints) with node selectors (for labels), or think annotations or probes can influence scheduling, when only `nodeSelector` or node affinity directly control node placement based on labels.

How to eliminate wrong answers

Option A is wrong because tolerations are used to allow Pods to run on nodes with taints, not to select nodes based on labels; a toleration for `node.kubernetes.io/disk-type: ssd` would be meaningless as this is not a well-known taint key. Option C is wrong because a readiness probe checks whether a container is ready to serve traffic, not the hardware characteristics of the node; it cannot enforce node selection. Option D is wrong because annotations are metadata for non-identifying information and are not used by the scheduler for node placement decisions.

Practice this question →

196

MCQmedium

A developer created a Deployment with image 'myapp:v1' and then ran 'kubectl set image deployment/myapp myapp=myapp:v2'. What is the effect of this command?

A.It updates the Service selector to point to pods with the new image.

B.It updates the Deployment's pod template to use the new image, triggering a rolling update.

C.It creates a new Deployment named 'v2' with the new image.

D.It immediately restarts all pods with the new image.

AnswerB

The command modifies the Deployment's container image, initiating a rolling update.

Why this answer

The `kubectl set image deployment/myapp myapp=myapp:v2` command updates the pod template within the Deployment's specification to use the new image `myapp:v2`. This change triggers a rolling update, where the Deployment controller creates new pods with the updated image and gradually terminates old pods, ensuring zero downtime. The command does not affect Services, create new Deployments, or restart pods immediately without a rolling update strategy.

Exam trap

CNCF often tests the distinction between updating a Deployment's pod template (which triggers a rolling update) versus directly restarting pods or modifying Services, leading candidates to mistakenly think the command affects Service selectors or creates a new Deployment.

How to eliminate wrong answers

Option A is wrong because `kubectl set image` only modifies the Deployment's pod template; it does not update Service selectors, which are used to route traffic to pods based on labels, not image versions. Option C is wrong because the command updates the existing Deployment's pod template in place, not creating a new Deployment; Kubernetes Deployments are versioned through their pod template changes, not by creating separate Deployment objects. Option D is wrong because the command does not immediately restart all pods; it updates the desired state in the Deployment's pod template, and the Deployment controller performs a rolling update according to the `strategy` field (defaulting to RollingUpdate), which gradually replaces pods rather than restarting them all at once.

Practice this question →

197

MCQeasy

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerA

The kube-controller-manager runs controller processes that reconcile the actual state with the desired state.

Why this answer

The kube-controller-manager is the component that runs controller loops to regulate the state of the cluster. Each controller (e.g., Node Controller, Replication Controller) watches the shared state via the API server and makes changes to drive the actual cluster state toward the desired state defined in the control plane. This is the core mechanism for self-healing and maintaining declarative configuration.

Exam trap

CNCF often tests the misconception that the API server (kube-apiserver) is responsible for maintaining desired state because it is the central hub, but the API server only serves the API and stores state in etcd, while the actual reconciliation is done by the controller-manager's loops.

How to eliminate wrong answers

Option B (etcd) is wrong because etcd is a distributed key-value store used for cluster data persistence, not for running controller loops; it stores the desired and current state but does not reconcile them. Option C (kube-apiserver) is wrong because the API server is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it does not execute controller logic or maintain desired state through loops. Option D (kube-scheduler) is wrong because the scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for running controller loops to maintain desired state.

Practice this question →

198

MCQeasy

Which Kubernetes object is used to logically isolate resources within a cluster, such as for separating environments like dev and prod?

A.ClusterRole

B.ResourceQuota

C.Node

D.Namespace

AnswerD

Namespaces partition the cluster into virtual sub-clusters.

Why this answer

D is correct because a Namespace is the Kubernetes object designed to logically isolate resources within a single cluster. By creating separate Namespaces for environments like dev and prod, you can apply distinct policies, quotas, and access controls without needing multiple physical clusters.

Exam trap

The trap here is that candidates often confuse Namespaces with other cluster-scoped or resource-limiting objects, mistakenly thinking a ClusterRole or ResourceQuota can provide logical isolation, when in fact Namespaces are the fundamental building block for environment separation.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is a cluster-scoped RBAC object that defines permissions across the entire cluster, not a mechanism for isolating resources or environments. Option B is wrong because a ResourceQuota is an object that sets hard limits on resource consumption (e.g., CPU, memory) within a specific Namespace, but it does not itself create logical isolation or separate environments. Option C is wrong because a Node is a worker machine (physical or virtual) that runs Pods; it is a compute resource, not an object for logically separating environments within a cluster.

Practice this question →

199

Multi-Selecthard

Which THREE of the following are valid ways to assign a pod to a specific node? (Choose three.)

Select 3 answers

A.Setting the 'nodeName' field in the pod spec

B.Using 'affinity' with 'nodeAffinity' rules

C.Using 'nodeSelector' with label matching

D.Using a ServiceAccount

E.Setting the 'clusterName' field

AnswersA, B, C

Directly assigns the pod to a node.

Why this answer

Setting the 'nodeName' field in the pod spec directly assigns the pod to a specific node by name. This bypasses the scheduler entirely, as the kubelet on that node will see the pod and attempt to run it. It is a valid, though inflexible, method for node assignment.

Exam trap

Candidates often confuse direct node assignment (nodeName) with scheduling constraints (nodeSelector, nodeAffinity). ServiceAccount and clusterName do not affect node placement.

Practice this question →

200

MCQhard

A Deployment has a strategy of RollingUpdate with maxSurge=1 and maxUnavailable=0. The Deployment manages 3 replicas. The image is updated. What happens during the update?

A.All 3 new Pods are created, and then the old ones are terminated all at once

B.One new Pod is created, and once it is ready, one old Pod is terminated. This repeats until all Pods are updated.

C.All 3 old Pods are terminated simultaneously before new ones start

D.The update fails because maxUnavailable cannot be 0

AnswerB

This matches the rolling update behavior with maxSurge=1 and maxUnavailable=0.

Why this answer

The RollingUpdate strategy with maxSurge=1 and maxUnavailable=0 ensures that during the update, exactly one new Pod is created above the desired replica count (surge of 1) while keeping all existing Pods running (maxUnavailable=0). Once the new Pod reaches the Ready state, one old Pod is terminated, maintaining the desired 3 replicas throughout the process. This cycle repeats until all Pods are updated, guaranteeing zero downtime.

Exam trap

A common misconception is that maxUnavailable=0 prevents any Pod termination, but in a RollingUpdate with maxSurge>0, old Pods are terminated only after new ones are ready, ensuring zero downtime while the update proceeds.

How to eliminate wrong answers

Option A is wrong because it describes a Recreate strategy, not a RollingUpdate; with maxSurge=1, only one new Pod is created at a time, not all three simultaneously. Option C is wrong because terminating all old Pods before starting new ones violates maxUnavailable=0, which prohibits any Pods from being unavailable during the update. Option D is wrong because maxUnavailable=0 is a valid and commonly used setting to ensure zero downtime; the update does not fail as long as there is capacity to surge (maxSurge>0).

Practice this question →

201

MCQeasy

What is the purpose of a Kubernetes Service?

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

B.To store configuration data as key-value pairs

C.To manage rolling updates of container images

D.To schedule pods onto nodes

AnswerA

Services abstract access to pods and provide load balancing.

Why this answer

A Kubernetes Service provides a stable, virtual IP address and DNS name that acts as a consistent endpoint for accessing a set of pods, even as pods are created, destroyed, or rescheduled. This abstraction decouples clients from the ephemeral nature of pod IPs, enabling reliable communication within the cluster. Services use label selectors to dynamically route traffic to the appropriate pods, and they support multiple types (ClusterIP, NodePort, LoadBalancer) to expose applications internally or externally.

Exam trap

The trap here is that candidates often confuse a Service with a Deployment, thinking both manage pod lifecycle, but a Service only provides network abstraction and does not handle pod creation, scaling, or updates.

How to eliminate wrong answers

Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap or Secret, not a Service. Option C is wrong because managing rolling updates of container images is handled by a Deployment or StatefulSet controller, not a Service. Option D is wrong because scheduling pods onto nodes is the responsibility of the Kubernetes Scheduler, which uses resource requests, constraints, and affinity rules, while a Service only handles network abstraction and traffic routing.

Practice this question →

202

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Pod

B.Node

C.Deployment

D.Container

AnswerA

A Pod represents a single instance of a running process.

Why this answer

A 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. Containers are not directly scheduled onto Nodes; instead, Kubernetes always schedules and manages Pods as the atomic unit of deployment.

Exam trap

A common trap is to think that a Container is the smallest unit because it is the fundamental runtime entity, but Kubernetes abstracts containers inside Pods, making the Pod the smallest deployable and schedulable object.

How to eliminate wrong answers

Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit; Pods are scheduled onto Nodes, but Nodes themselves are not deployed as application units. Option C is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest deployable unit. Option D is wrong because a Container is the runtime environment for an application process, but Kubernetes does not deploy containers directly; it wraps them inside a Pod, which is the smallest schedulable and deployable entity.

Practice this question →

203

Multi-Selecthard

Which TWO of the following are valid reasons that a PersistentVolumeClaim (PVC) may remain in 'Pending' state?

Select 2 answers

A.The pod that references the PVC is not scheduled yet

B.No PersistentVolume exists that matches the PVC's storage class and size requirements

C.The PVC is using a StorageClass that does not exist

D.The PVC's access mode is 'ReadWriteMany' but the underlying storage only supports 'ReadWriteOnce'

E.The cluster's dynamic provisioner is unavailable or misconfigured

AnswersB, C

No PersistentVolume exists that matches the PVC's storage class and size requirements – Correct. If no matching PV exists, the PVC cannot bind and remains Pending.

Why this answer

A PersistentVolumeClaim (PVC) stays in 'Pending' state until a suitable PersistentVolume (PV) is available to bind. Two common reasons are: (1) No existing PV matches the PVC's storage class and size requirements (static provisioning failure), and (2) The PVC references a StorageClass that does not exist, preventing dynamic provisioning. Other reasons like pod scheduling or dynamic provisioner unavailability are not among the two correct answers.

Exam trap

Candidates often assume only PV unavailability causes Pending, but a missing or misconfigured StorageClass is equally valid. The KCNA exam may test that PVCs using a non-existent StorageClass will also remain Pending.

Practice this question →

204

MCQhard

A developer deploys a CronJob that runs a batch job every 5 minutes. After a while, they notice that the job fails with 'DeadlineExceeded' and the pod is stuck in 'PodInitializing' state. What is the most likely reason?

A.A pre-existing InitContainer is failing or stuck

B.The CronJob schedule is misconfigured

C.The container runtime is not installed on the node

D.The job's backoffLimit is set too low

AnswerA

A stuck InitContainer prevents the main container from starting, causing the pod to remain in PodInitializing. If the job's activeDeadlineSeconds passes, the job is terminated with DeadlineExceeded.

Why this answer

The 'PodInitializing' state indicates that the pod is stuck before its main containers can start, which is typically caused by an InitContainer that is failing or hanging. Since the job fails with 'DeadlineExceeded', the pod's activeDeadlineSeconds (or the CronJob's startingDeadlineSeconds) has been reached while the InitContainer is still running, preventing the main container from executing. This is the most likely reason because InitContainers run sequentially to completion before any main containers start, and a stuck InitContainer blocks the entire pod lifecycle.

Exam trap

CNCF often tests the distinction between 'PodInitializing' (caused by InitContainers or image pull issues) and 'ContainerCreating' (caused by container runtime or volume mount problems), leading candidates to incorrectly blame the container runtime or schedule misconfiguration.

How to eliminate wrong answers

Option B is wrong because a misconfigured CronJob schedule (e.g., wrong cron expression) would cause the job to run at incorrect times or not at all, but it would not cause a pod to be stuck in 'PodInitializing' with a 'DeadlineExceeded' error. Option C is wrong because if the container runtime were not installed on the node, the pod would likely remain in 'Pending' state (with an event like 'FailedCreatePodSandBox') rather than reaching 'PodInitializing', and the kubelet would report a runtime error. Option D is wrong because a low backoffLimit affects the number of retries after a job fails (e.g., if the main container exits with non-zero), but it does not cause a pod to be stuck in 'PodInitializing'; the 'DeadlineExceeded' error here is about the pod's active deadline, not the retry limit.

Practice this question →

205

MCQmedium

Which component runs on every worker node and ensures that containers are running in a Pod as specified in the Pod manifest?

A.kube-controller-manager

B.container runtime

C.kubelet

D.kube-proxy

AnswerC

kubelet is the node agent that reads Pod manifests and ensures containers are running.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives Pod specifications (Pod manifests) from the API server, either directly or via the kube-apiserver, and ensures that the containers described in those manifests are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers as needed.

Exam trap

The trap here is that candidates often confuse the container runtime with the kubelet, thinking the runtime directly reads Pod manifests, when in fact the kubelet is the orchestrator that interprets the manifest and delegates container operations to the runtime via the CRI.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs on the control plane, not on worker nodes; it manages controllers like the ReplicaSet controller and Node controller, but does not directly ensure containers are running on a specific node. Option B is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually running containers, but it does not interpret Pod manifests or enforce the desired state; it only executes commands from the kubelet via the Container Runtime Interface (CRI). Option D is wrong because kube-proxy runs on each node but handles network proxying and service load balancing (e.g., iptables or IPVS rules), not container lifecycle management.

Practice this question →

206

MCQhard

A developer creates a Service of type ClusterIP in namespace 'default'. They attempt to reach the Service from another pod in the same namespace using the Service name 'my-svc'. The connection fails. What is the most likely cause?

A.The Service port does not match the container port

B.The cluster DNS service (CoreDNS) is not running or misconfigured

C.The Service type should be NodePort

D.The Service selector does not match any pod labels

AnswerB

DNS is required for Service name resolution.

Why this answer

The most likely cause is that the cluster DNS service (CoreDNS) is not running or misconfigured. When a pod attempts to reach a Service by its DNS name (e.g., 'my-svc'), Kubernetes relies on CoreDNS to resolve that name to the ClusterIP. If CoreDNS is down, misconfigured, or the pod's DNS resolver is not pointing to it, the name resolution fails, causing the connection to fail even if the Service itself is correctly configured.

Exam trap

The trap here is that candidates often assume the issue is with the Service configuration (selector or port) rather than the underlying DNS infrastructure, because they forget that name resolution is a prerequisite for Service discovery within the cluster.

How to eliminate wrong answers

Option A is wrong because a port mismatch would cause a connection timeout or connection refused at the transport layer, but the question states the connection fails entirely, which is more indicative of a DNS resolution failure. Option C is wrong because a ClusterIP Service is perfectly reachable from within the same namespace by its DNS name; NodePort is only needed for external access. Option D is wrong because if the Service selector does not match any pod labels, the Service would have no endpoints, but the connection attempt would still resolve the DNS name and reach the ClusterIP, resulting in a connection refused or timeout, not a complete failure to connect.

Practice this question →

207

MCQhard

A pod is in CrashLoopBackOff state. 'kubectl logs pod' shows 'Error: cannot connect to database at db-service:5432'. The database Service exists and is reachable from other pods. What is the most likely cause?

A.The kube-proxy is not functioning

B.The pod's resource limits are too low

C.The database pod is not running

D.The application's configuration has incorrect database connection details

AnswerD

Why this answer

The error indicates the application cannot connect to the database. Since other pods can reach the database, the issue is specific to this pod. A common cause is that the pod's configuration (e.g., environment variables, config file) contains wrong connection details, such as incorrect service name, port, or credentials.

Practice this question →

208

Multi-Selectmedium

Which TWO of the following are true about Kubernetes Pods?

Select 2 answers

A.A Pod always runs exactly one container

B.Pods are automatically rescheduled if a node fails

C.A Pod is the smallest deployable unit in Kubernetes

D.Containers within the same Pod share the same network namespace

E.Pods are directly created by the kube-scheduler

AnswersC, D

Pods are the smallest and simplest Kubernetes object.

Why this answer

A Pod is the smallest and most basic deployable unit in Kubernetes. It represents a single instance of a running process and encapsulates one or more containers, storage resources, and a unique network IP. You cannot deploy a container directly; you must always wrap it in a Pod.

Exam trap

The trap here is that candidates confuse the Pod's ability to run multiple containers with the requirement to run exactly one, or they mistakenly think the scheduler creates Pods instead of only assigning them to nodes.

Practice this question →

209

MCQhard

You deploy a new version of your application by updating the container image in the Deployment manifest. The rollout seems to be progressing, but after a few minutes you notice that the new Pods are failing and the old Pods are still running. What is the most likely reason?

A.The Deployment was created with 'kubectl create deployment' instead of 'kubectl apply'

B.The new Pods are failing readiness probes, so the Deployment pauses the rollout and keeps the old replicas

C.The new Pods are not receiving traffic because the Service selector doesn't match

D.The Deployment's update strategy is set to 'Recreate'

AnswerB

If readiness probes fail, the new Pods are not considered ready, and the Deployment controller will not continue the rollout, preserving the old replicas.

Why this answer

When a new Pod fails its readiness probe, the Deployment controller considers the new ReplicaSet unhealthy and pauses the rollout. The controller keeps the old ReplicaSet running to maintain the desired number of available replicas, preventing traffic disruption until the new Pods pass their probes or the rollout is manually resumed.

Exam trap

The CNCF Kubernetes exam often tests the distinction between liveness and readiness probes; candidates mistakenly think a failing liveness probe causes the same behavior, but only readiness probe failures pause a rollout while liveness failures restart the Pod without affecting the rollout progress.

How to eliminate wrong answers

Option A is wrong because 'kubectl create deployment' and 'kubectl apply' both create a Deployment resource; the command used does not affect rollout behavior or cause Pod failures. Option C is wrong because a Service selector mismatch would prevent traffic from reaching new Pods, but it would not cause the old Pods to remain running during a rollout; the Deployment would still replace old Pods with new ones. Option D is wrong because the 'Recreate' strategy terminates all old Pods before creating new ones, so old Pods would not still be running; the scenario describes old Pods remaining, which matches a rolling update with a paused rollout due to failed readiness probes.

Practice this question →

210

MCQeasy

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

A.kubectl logs web-pod -c nginx

B.kubectl logs web-pod nginx

C.kubectl describe pod web-pod

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

AnswerA

The -c flag specifies the container name when there are multiple containers.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

211

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.Delete and recreate the pod to clear the crash loop

B.Delete the namespace and redeploy all workloads

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

D.Increase the CPU request for the container

AnswerC

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, which means the container's memory usage exceeded its configured memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to use more memory without being terminated by the Out-Of-Memory (OOM) killer. This directly addresses the root cause—insufficient memory allocation—while preserving the existing pod configuration and data.

Exam trap

The trap here is that candidates may confuse OOMKilled with a generic crash or resource issue and choose to delete/recreate the pod (Option A) or adjust CPU (Option D), rather than recognizing that the specific OOMKilled message points directly to a memory limit problem that must be addressed by increasing the memory limit.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod does not resolve the underlying memory limit issue; the new pod would still have the same resource constraints and would likely be OOMKilled again. Option B is wrong because deleting the entire namespace and redeploying all workloads is an extreme, disruptive action that unnecessarily affects other workloads and does not target the specific pod's memory problem. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOMKilled error is caused by memory exhaustion, not CPU starvation, so this change would not prevent the container from being killed.

Practice this question →

212

MCQhard

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

A.The container image is too large

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

C.The pod has a liveness probe that is failing

D.The kubelet on the node is not running

AnswerB

If the memory request exceeds the available memory on all nodes, the scheduler cannot place the pod, leaving it in Pending.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

213

Multi-Selectmedium

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

Select 3 answers

A.etcd

B.kube-apiserver

C.container runtime

D.kube-proxy

E.kubelet

AnswersC, D, E

Container runtime runs containers.

Why this answer

A container runtime is a core component of a Kubernetes worker node. It is responsible for actually running the containers (e.g., containerd, CRI-O) and is required by the kubelet to manage pod lifecycle. Without a container runtime, the kubelet cannot start or stop containers on the node.

Exam trap

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

Practice this question →

214

MCQeasy

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerC

It is the front-end for the Kubernetes control plane.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative tasks and API requests. It validates and processes RESTful API calls (using JSON/YAML over HTTP/HTTPS) before persisting state to etcd or delegating work to other controllers. Without the API server, no kubectl command, automation script, or internal component can interact with the cluster.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

215

MCQeasy

Which Kubernetes component is responsible for storing the cluster state?

A.kube-scheduler

B.kube-apiserver

C.etcd

D.kube-controller-manager

AnswerC

etcd stores all cluster state, including configurations and desired state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

216

Multi-Selectmedium

Which TWO of the following are valid ways to expose a set of pods to traffic from outside the Kubernetes cluster?

Select 2 answers

A.Service of type NodePort

B.Ingress

C.Service of type ExternalName

D.Service of type ClusterIP

E.Service of type LoadBalancer

AnswersA, E

Why this answer

A Service of type NodePort exposes the service on a static port on each node's IP address. Traffic sent to that port on any cluster node is forwarded to the underlying service, making it accessible from outside the cluster without requiring a cloud load balancer.

Exam trap

CNCF often tests the distinction between Ingress (a routing layer) and Service types (the actual exposure mechanism), leading candidates to mistakenly select Ingress as a direct exposure method.

Practice this question →

217

MCQhard

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

A.10.0.0.1:30080

B.10.0.0.1:80

C.ClusterIP:80

D.10.0.0.2:8080

AnswerA

NodePort makes the service accessible on each node's IP at the nodePort.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

218

MCQmedium

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

A.ClusterIP

B.Headless Service

C.ExternalName Service

D.NodePort

AnswerA

A ClusterIP Service exposes the application on a cluster-internal IP and load-balances across all pods in the backing set.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

219

MCQhard

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

A.etcd

B.Deployment controller in kube-controller-manager

C.kubelet

D.kube-scheduler

AnswerB

The Deployment controller watches the Deployment and manages the ReplicaSet to achieve the desired number of replicas.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

220

Multi-Selecthard

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

Select 2 answers

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

B.CPU limits are enforced using CFS quotas

C.Memory limits are soft and can be exceeded temporarily

D.Limits must be greater than or equal to requests

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

AnswersB, D

CPU limits are enforced via Completely Fair Scheduler (CFS) quotas.

Why this answer

Kubernetes enforces CPU limits using Completely Fair Scheduler (CFS) quotas. When a CPU limit is set, the kubelet configures the container's cgroup `cpu.cfs_quota_us` parameter, which restricts the total CPU time the container can consume over a CFS period (default 100ms). This ensures the container cannot exceed its specified CPU limit, even if the node has idle CPU resources.

Exam trap

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

Practice this question →

221

MCQmedium

You need to update a running Deployment to use a new container image. Which kubectl command should you use?

A.kubectl replace -f deployment.yaml

B.kubectl set image deployment/<name> <container>=<new-image>

C.kubectl edit deployment <name>

D.kubectl patch deployment <name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","image":"<new-image>"}]}}}}'

AnswerB

This command directly updates the image.

Why this answer

`kubectl set image` is the dedicated command for updating the container image of a running Deployment without modifying the entire manifest. It directly updates the Deployment's pod template spec, triggering a rolling update to replace pods with the new image.

Exam trap

CNCF often tests whether candidates know that `kubectl set image` is the idiomatic, single-purpose command for updating container images, versus using more complex or less appropriate commands like `kubectl replace` or `kubectl patch`.

How to eliminate wrong answers

Option A is wrong because `kubectl replace -f deployment.yaml` would replace the entire Deployment object, which is not the standard way to update just the image; it requires a complete YAML file and can cause downtime if not handled carefully. Option C is wrong because `kubectl edit deployment <name>` opens an interactive editor, which is not a single command for automation and can introduce human error or syntax issues. Option D is wrong because `kubectl patch` can technically update the image, but it requires a complex JSON patch string and is more error-prone than the simpler `kubectl set image` command; it is not the recommended or most straightforward approach for this common task.

Practice this question →

222

MCQmedium

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

A.Service of type NodePort

B.Ingress

C.NetworkPolicy

D.Service of type ClusterIP

AnswerD

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

223

MCQmedium

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

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

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

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

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

AnswerA

Exit code 137 indicates SIGKILL, often from OOM.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

224

MCQeasy

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

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-controller-manager

AnswerB

etcd is the cluster state store.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

225

MCQmedium

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

A.The Pod's container is crashing

B.The container image has a typo

C.No node has enough resources to run the Pod

D.The Pod's liveness probe is failing

AnswerC

Scheduler cannot place the Pod, so it remains Pending.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →