CCNA Kubernetes Fundamentals Questions — Page 4 of 6

226

MCQmedium

A developer runs `kubectl get pods` and notices that one Pod is stuck in the `Pending` state. The Pod's resource requests are modest, and the node has sufficient CPU and memory. Which of the following is the MOST likely reason the Pod is not being scheduled?

A.The Pod's service account does not exist.

B.The Pod's container image is not available in the registry.

C.The Pod's liveness probe is failing.

D.The Pod has a nodeSelector that does not match any node's labels.

AnswerD

A nodeSelector restricts scheduling to nodes with matching labels. If no node has the specified label, the scheduler cannot place the Pod, leaving it Pending. Other factors like resource availability are not the issue here, so this is the most likely cause.

Why this answer

The scheduler assigns Pods to nodes based on resource requests, node selectors, affinity rules, and taints/tolerations. When a Pod remains Pending despite adequate resources, a nodeSelector mismatch is a common cause. The scheduler cannot find a node that satisfies the label constraint, so it leaves the Pod unscheduled until a suitable node becomes available or the selector is corrected.

Exam trap

The trap here is assuming that Pending always means insufficient resources, while ignoring scheduling constraints like nodeSelector or affinity.

Practice this question →

227

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 kube-apiserver is the sole control plane component that reads from and writes to etcd, serving as the only gateway to cluster state. Controllers and schedulers watch and mutate resources exclusively through it, satisfying the constraint that no other component holds a direct etcd connection.

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 →

228

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

Network policies are namespaced resources, so applying a NetworkPolicy within a namespace scopes ingress and egress rules to the pods it selects there, satisfying the requirement to isolate traffic between teams sharing a cluster. This is a genuine namespace use, unlike cluster-wide concerns such as node affinity or storage provisioning.

Why this answer

Option B is correct because Kubernetes NetworkPolicy objects are namespaced resources, so network policies are defined and applied per namespace to control ingress and egress traffic for the pods within that namespace. Option C is correct because namespaces provide logical partitioning of cluster resources, allowing teams to run dev, staging, and prod workloads in the same physical cluster with separate names, quotas, and access controls. Option A is not correct because CPU and memory limits are set on Pods/Containers (via resources.requests/limits) or enforced cluster-wide per namespace using ResourceQuota and LimitRange objects, not as a namespace-level setting itself.

Option D is not correct because namespaces do not isolate node resources; node-level isolation is achieved through taints, tolerations, node affinity, or separate node pools. Option E is not correct because namespaces do not provide authentication; RBAC handles authorization, while authentication is performed by the API server via tokens, certificates, or external identity providers, with RoleBindings scoped to a namespace.

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 →

229

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

kubectl describe pod retrieves a single Pod's full state, including container statuses, conditions and the recent event stream from the API server. This satisfies the requirement to see events and conditions, which kubectl get pod alone does not display.

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 →

230

MCQmedium

A cluster administrator needs to run a critical system daemon that must continue running even when a node is marked as unschedulable for maintenance. The DaemonSet Pods should tolerate the node's taint. Which taint should the DaemonSet Pod tolerate to achieve this?

A.node.kubernetes.io/unreachable

B.node.kubernetes.io/unschedulable

C.node.kubernetes.io/not-ready

D.node.kubernetes.io/memory-pressure

AnswerB

When a node is cordoned using kubectl cordon, Kubernetes adds the taint node.kubernetes.io/unschedulable:NoSchedule. To allow DaemonSet Pods to continue running on that node, the Pod template must include a toleration for this taint. This is the correct taint to tolerate for maintenance scenarios where you want existing Pods to keep running but prevent new scheduling.

Why this answer

Cordoning a node adds the taint node.kubernetes.io/unschedulable:NoSchedule. To keep DaemonSet Pods running on that node during maintenance, the Pod template must tolerate this taint. The other taints represent different node conditions and do not address the unschedulable state.

Exam trap

The trap here is assuming that tolerating not-ready or unreachable taints would allow Pods to run on cordoned nodes, but only the unschedulable taint is added during cordon.

Practice this question →

231

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

Within a Deployment manifest, spec.replicas is the integer field declaring how many identical pod instances the ReplicaSet should maintain. It sits under spec alongside selector and template, directly answering the stem's request for the replica-count field.

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 →

232

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

maxSurge: 1 lets the Deployment add one pod above the desired count, while maxUnavailable: 0 forbids dropping below it. The controller therefore starts a new pod and waits for it to become Ready before terminating an old one, guaranteeing zero downtime.

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 →

233

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

A ConfigMap holds non-confidential key-value configuration data that Pods consume as environment variables, command-line arguments or mounted files. This satisfies the stem's requirement for storing non-sensitive configuration, distinguishing it from Secrets, which are intended for sensitive data such as credentials.

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 →

234

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 →

235

MCQmedium

A user runs 'kubectl get pods -n default' but receives an error: 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group'. What is the most likely cause?

A.The pod does not exist in the namespace

B.The user's kubeconfig file is corrupted

C.The user lacks RBAC permissions to list pods

D.The API server is down

AnswerC

The Forbidden error names the user and the verb 'list' on pods, which is exactly what RBAC authorises. Authentication succeeded, so the cause is a missing Role or ClusterRole binding granting list on pods in the default namespace.

Why this answer

The error message 'Error from server (Forbidden): pods is forbidden: User cannot list resource pods in API group' directly indicates that the Kubernetes RBAC (Role-Based Access Control) system has denied the request. The user's current context in their kubeconfig does not have a Role or ClusterRole binding that grants the 'list' verb on 'pods' in the 'v1' API group (core group). This is a standard authorization failure, not a connectivity or resource existence issue.

Exam trap

The trap here is that candidates confuse a missing resource (NotFound) with a permissions error (Forbidden), or assume the API server is down when the error is actually a structured RBAC denial. The CNCF exam often tests the distinction between authentication failures (401 Unauthorized) and authorization failures (403 Forbidden).

How to eliminate wrong answers

Option A is wrong because if the pod did not exist in the namespace, the error would be 'Error from server (NotFound): pods not found', not a Forbidden error. Option B is wrong because a corrupted kubeconfig file would typically produce errors like 'invalid configuration' or 'unable to read client-cert', not a structured Forbidden response from the API server. Option D is wrong because if the API server were down, the user would receive a connection refused or timeout error, not a structured HTTP 403 Forbidden response with RBAC details.

Practice this question →

236

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

Kubernetes DNS resolves ClusterIP Services as `<service>.<namespace>.svc.cluster.local`, so `db-service.prod.svc.cluster.local` satisfies the stem's same-cluster requirement, combining the service name with its `prod` namespace. The `svc` segment denotes the Service record type, and `cluster.local` is the default cluster domain suffix.

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 →

237

Multi-Selecthard

Which TWO of the following are valid ways to expose a Service to external traffic?

Select 2 answers

A.ExternalName

B.Headless

C.LoadBalancer

D.NodePort

E.ClusterIP

AnswersC, D

A LoadBalancer Service provisions an external cloud load balancer that routes inbound traffic to the backing pods. This exposes the Service beyond the cluster, unlike ClusterIP, which remains reachable only internally within the cluster network.

Why this answer

NodePort (D) is correct because it exposes a Service on each cluster node's IP at a static port in the 30000–32767 range, allowing external clients to reach the Service via <NodeIP>:<NodePort>. LoadBalancer (C) is correct because it builds on NodePort and provisions an external load balancer (e.g., via a cloud provider) that routes external traffic to the Service's endpoints. ExternalName (A) is not a way to expose a Service to external traffic; it simply returns a CNAME DNS record pointing to an external hostname without proxying traffic.

Headless (B) sets clusterIP: None and returns pod IPs directly via DNS, which is used for direct pod discovery, not external exposure. ClusterIP (E) is the default internal-only Service type, reachable only from within the cluster, so it does not expose the Service externally.

Exam trap

A common pitfall is assuming ExternalName or Headless Services provide external exposure. ExternalName only provides an internal DNS alias, while Headless is for internal pod discovery. Only NodePort and LoadBalancer directly expose the Service externally.

Practice this question →

238

MCQeasy

A platform engineer needs to run a one-time batch job that processes a dataset and then exits. The job must run exactly once and not be restarted if it completes successfully. Which Kubernetes resource should be used?

A.DaemonSet

B.CronJob

C.Deployment

D.Job

AnswerD

A Job creates one or more Pods and ensures that a specified number of them successfully terminate. It is designed for run-to-completion workloads. By default, it does not restart Pods after successful completion, making it ideal for a one-time batch process that must finish and exit.

Why this answer

A Job is the correct resource for run-to-completion workloads. It creates Pods that are expected to terminate successfully, and it does not restart them after successful completion. Deployments, CronJobs, and DaemonSets are designed for different use cases: long-running services, scheduled tasks, and node-level agents, respectively.

Exam trap

The trap here is confusing a Job with a CronJob; a CronJob is for scheduled recurring tasks, not a single immediate execution.

Practice this question →

239

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 →

240

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 stateless workloads through ReplicaSets, supporting rolling updates that replace Pods incrementally rather than all at once. This satisfies the zero-downtime requirement: the rollout proceeds one Pod at a time while remaining replicas keep serving traffic, and it maintains the desired count of five throughout.

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 →

241

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

A Pod groups one or more containers sharing a network namespace and storage volumes, and is the atomic unit Kubernetes schedules and deploys. This satisfies the stem's requirement for a Pod characteristic: it is the smallest deployable unit.

Why this answer

Option B is correct because the Pod is the smallest and most basic deployable object in Kubernetes — you cannot deploy a container directly; it must be wrapped in a Pod, which represents a single instance of a running process in the cluster. Option C is correct because all containers in a Pod share the same network namespace, meaning they share one IP address and port space and can communicate with each other via localhost, and they can also share storage volumes. Option A is incorrect because a Pod can run one or multiple containers (e.g., sidecar, ambassador, or adapter patterns), not only a single container.

Option D is incorrect because Pods are ephemeral by design — they are not intended to be long-lived; they are created, terminated, and replaced rather than repaired in place. Option E is incorrect as a defining characteristic of a Pod itself: replication is performed by higher-level controllers such as Deployments or ReplicaSets, which manage Pods but are not properties of the Pod object.

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 →

242

MCQeasy

A developer wants to run a one-time batch job that processes a dataset and then exits. The job must complete successfully and not be restarted after completion. Which Kubernetes resource should be used?

A.Deployment

B.StatefulSet

C.Job

D.CronJob

AnswerC

A Job creates one or more pods and ensures that a specified number of them successfully terminate. It is designed for batch processing, where the workload runs to completion and then stops. Once the pods complete successfully, the Job is considered finished, and no further pods are created. This matches the requirement for a one-time batch job that exits after processing.

Why this answer

Job is the correct resource for batch workloads that run to completion. It ensures that a specified number of pods finish successfully and then stops creating new ones. CronJob is for scheduled recurring tasks, while Deployment and StatefulSet are for long-running services that restart on exit.

Thus, Job best fits the one-time batch processing requirement.

Exam trap

The trap here is confusing Job with CronJob, or assuming that any controller can handle run-to-completion workloads.

Practice this question →

243

MCQhard

A team wants to deploy a stateful application that requires each pod to have a unique, stable network identity and persistent storage that persists across rescheduling. Which Kubernetes resource is most appropriate?

A.DaemonSet

B.Deployment

C.StatefulSet

D.Job

AnswerC

StatefulSet assigns each pod a stable ordinal hostname and its own PersistentVolumeClaim via volumeClaimTemplates, so identity and storage survive rescheduling. Deployments give pods random names and share or recreate storage, failing the stable-identity and persistence constraints the stem requires.

Why this answer

StatefulSet is the correct choice because it provides each pod with a unique, stable network identity (via a predictable hostname derived from the StatefulSet name and ordinal index) and dedicated persistent storage that persists across rescheduling. This is achieved through a headless Service and PersistentVolumeClaims (PVCs) that are bound to each pod's identity, ensuring that when a pod is rescheduled, it reattaches to the same storage and retains its network identity.

Exam trap

A common mistake is to think that a Deployment can be used for stateful workloads because it supports PersistentVolumeClaims. However, Deployment does not guarantee stable pod identities or ordered pod creation/termination, which are essential for stateful applications like databases.

How to eliminate wrong answers

Option A (DaemonSet) is wrong because it ensures one pod per node, not unique stable identities or persistent storage per pod; it is designed for node-level services like logging agents. Option B (Deployment) is wrong because it creates pods with random, ephemeral hostnames and does not guarantee stable network identities or persistent storage; it is intended for stateless applications where pods are interchangeable. Option D (Job) is wrong because it runs a finite task to completion and does not provide persistent storage or stable network identities; it is used for batch processing, not long-running stateful applications.

Practice this question →

244

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

A Pending status means the pod has been accepted by the API server but no node has been bound to it. The kube-scheduler assigns pods to nodes, and when no node satisfies the pod's CPU, memory, or affinity constraints, it remains unscheduled and reports Pending.

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 →

245

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

A nodeSelector with `disk-type: ssd` in the pod spec makes the scheduler place the pod only on nodes carrying that exact label, directly satisfying the SSD constraint. Unlike taints, tolerations or affinity, nodeSelector is a hard requirement evaluated at scheduling time, so pods stay Pending rather than landing on non-SSD nodes.

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 →

246

MCQmedium

A developer wants to run a batch job that processes a large dataset. The job should run to completion, and if the Pod fails, it should be retried up to 4 times before being marked as failed. Which Kubernetes resource and configuration should be used?

A.A Deployment with replicas set to 5 and restartPolicy set to Always

B.A CronJob with schedule set to a future time and backoffLimit set to 4

C.A Pod with restartPolicy set to Never and no controller

D.A Job with backoffLimit set to 4 and restartPolicy set to OnFailure

AnswerD

A Job is designed for run-to-completion workloads. Setting backoffLimit to 4 allows up to 4 retries after a failure, and restartPolicy: OnFailure ensures the container is restarted within the same Pod on failure. This combination meets the requirement of retrying up to 4 times. The Job controller will mark the Job as failed after the backoffLimit is exceeded.

Why this answer

The requirement is a run-to-completion workload with limited retries. A Job is the correct resource, and backoffLimit specifies the number of retries before marking the Job as failed. Setting restartPolicy to OnFailure allows the container to restart within the Pod on failure, which is necessary for retries to occur.

Deployments and bare Pods do not provide completion semantics, and CronJobs are for scheduled tasks, not immediate one-time jobs.

Exam trap

The trap here is confusing the retry behavior of a Job with that of a Deployment; Deployments restart containers indefinitely and never complete, so they cannot satisfy a batch job requirement.

Practice this question →

247

MCQeasy

A developer needs to store non-confidential configuration data, such as a database hostname and port, that can be consumed by multiple Pods in a namespace. The data should be decoupled from the Pod specification to allow updates without rebuilding images. Which Kubernetes resource is designed for this purpose?

A.ConfigMap

B.ServiceAccount

C.PersistentVolumeClaim

D.Secret

AnswerA

A ConfigMap is specifically designed to hold non-confidential configuration data as key-value pairs. It can be consumed by Pods via environment variables, command-line arguments, or volume mounts. This decouples configuration from the Pod spec, allowing updates without image changes.

Why this answer

ConfigMaps are the standard Kubernetes resource for storing non-confidential configuration data. They allow you to separate configuration from container images, making applications more portable and easier to manage. Pods can reference ConfigMaps as environment variables, command-line arguments, or files in a volume.

This enables dynamic updates to configuration without redeploying Pods, depending on how the ConfigMap is consumed.

Exam trap

The trap here is assuming that Secrets should be used for any configuration data, but Secrets are meant for sensitive information, not general configuration.

Practice this question →

248

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 set image command patches the Deployment's pod template with myapp:v2. The Deployment controller then creates a new ReplicaSet and progressively shifts Pods from the old to the new template, performing a rolling update that maintains availability throughout.

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 →

249

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 the built-in controller loops — such as Deployment, ReplicaSet and Node controllers — that continuously reconcile observed cluster state with the declared desired state, satisfying the requirement for a component that maintains 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 →

250

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 provide a logical partition within a single cluster, scoping names, resource quotas and RBAC so teams or environments like dev and prod stay isolated. They satisfy the requirement for logical resource isolation without provisioning separate 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 →

251

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

Setting nodeName directly bypasses the scheduler, binding the Pod to that named node at creation. It satisfies the requirement for assigning a Pod to a specific node, though it skips scheduling checks such as resource fit and taints.

Why this answer

Option A is correct because setting the 'nodeName' field directly in the pod spec bypasses the scheduler and binds the pod to that exact node by name. Option B is correct because 'nodeAffinity' rules under 'affinity' let the scheduler place the pod on nodes matching label expressions, including required and preferred constraints. Option C is correct because 'nodeSelector' matches node labels and constrains the scheduler to only nodes carrying the specified labels.

Option D is not a placement mechanism; a ServiceAccount provides an identity for pods to authenticate to the API server, not to select a node. Option E is invalid because 'clusterName' is not a pod spec field used for node assignment and has no scheduling effect.

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 →

252

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

With maxUnavailable=0, no old Pod may be removed until a replacement is ready, so the controller adds one new Pod (maxSurge=1) first. Once that Pod passes readiness, one old Pod terminates, repeating until all three run the new image.

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 →

253

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

A Service's clusterIP and DNS name remain fixed while pod IPs change on restart or rescheduling, so traffic reaches whichever pods currently match the selector. This decouples clients from ephemeral pod lifecycles, satisfying the requirement for a stable endpoint.

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 →

254

MCQeasy

A developer creates a Pod with the following YAML snippet: spec: containers: - name: web image: nginx ports: - containerPort: 80 The Pod is running, but the developer cannot reach it from another Pod in the same namespace using the Pod's IP address. Which command should the developer run first to verify that the container process is listening on port 80?

A.kubectl describe pod <pod-name>

B.kubectl logs <pod-name>

C.kubectl get pod <pod-name> -o yaml

D.kubectl exec -it <pod-name> -- netstat -tuln

AnswerD

Running netstat inside the container shows which ports are listening. If the nginx process is bound to port 80, the output will include a LISTEN entry for 0.0.0.0:80 or :::80. This directly verifies whether the application is listening and helps distinguish application issues from network policy or Service misconfiguration.

Why this answer

The correct first step is to check listening sockets inside the container. Because the Pod is running but unreachable, the issue could be the application not listening on the expected port. Using kubectl exec with netstat (or ss) inside the container provides direct evidence of whether the process is bound to port 80, guiding further troubleshooting.

Exam trap

The trap here is relying on containerPort in the Pod spec as proof that the application listens on that port, when containerPort is only metadata and does not configure the application.

Practice this question →

255

MCQmedium

A user reports that they can access a service by its ClusterIP but not by its DNS name from within the cluster. What is the most likely cause?

A.The CoreDNS pod is not running or is misconfigured

B.The kube-proxy is not running on the node

C.The service is of type NodePort

D.The service selector does not match any pods

AnswerA

ClusterIP access works because kube-proxy rules route directly to Pod IPs, bypassing DNS. Name resolution depends entirely on CoreDNS, so a stopped or misconfigured CoreDNS pod breaks cluster DNS lookups while leaving ClusterIP connectivity intact.

Why this answer

Accessing a service by ClusterIP works because it relies on iptables/IPVS rules managed by kube-proxy, which are independent of DNS. However, DNS name resolution within the cluster is handled by CoreDNS, which translates service names to ClusterIPs. If CoreDNS is not running or misconfigured, DNS queries for the service name will fail, while direct ClusterIP access remains functional.

This is the most likely cause because the symptom specifically points to a DNS resolution failure.

Exam trap

The CNCF exam often tests the distinction between network-level connectivity (ClusterIP via kube-proxy) and service discovery (DNS via CoreDNS), trapping candidates who assume any connectivity issue must involve kube-proxy or pod matching.

How to eliminate wrong answers

Option B is wrong because kube-proxy is responsible for implementing the ClusterIP-based network rules (iptables/IPVS) that allow direct ClusterIP access; if kube-proxy were not running, ClusterIP access would also fail, not just DNS. Option C is wrong because the service type (NodePort, ClusterIP, etc.) does not affect DNS resolution; NodePort merely exposes the service on a node port, but DNS still resolves the service name to its ClusterIP. Option D is wrong because if the service selector does not match any pods, the service would have no endpoints, and both ClusterIP access and DNS resolution would fail (DNS would still resolve, but connections would be refused); the symptom of working ClusterIP access proves endpoints exist.

Practice this question →

256

MCQhard

A developer creates a Pod with a single container that writes data to /data. The Pod spec includes a volume of type hostPath with path /mnt/data. After the Pod is deleted, the developer notices that the data persists on the node. What is the primary reason for this behavior?

A.hostPath volumes are not deleted when the Pod is deleted; they persist on the node's filesystem.

B.The Pod's restartPolicy is set to Always, which causes the volume to be recreated after deletion.

C.The volume is backed by a PersistentVolume that retains data even after the Pod is deleted.

D.The kubelet caches volume data in memory and writes it back to the hostPath after Pod deletion.

AnswerA

hostPath volumes mount a file or directory from the host node's filesystem into the Pod. The data written to the hostPath persists beyond the Pod's lifecycle because it is stored on the node itself. Deleting the Pod does not remove the host directory or its contents.

Why this answer

hostPath volumes directly mount a node's filesystem path into a Pod. Data written to that path is stored on the node and remains there even after the Pod is deleted. This is why the data persists, as the node's directory is not automatically cleaned up by Kubernetes.

Exam trap

The trap here is assuming that all volumes are deleted with the Pod, or that hostPath volumes behave like emptyDir volumes.

Practice this question →

257

MCQeasy

An administrator is troubleshooting a cluster and runs `kubectl get pods -n kube-system`. They see a Pod named `kube-apiserver-controlplane` running on the control plane node. Which statement best describes the role of this component?

A.It schedules Pods onto nodes by evaluating resource requests and node affinity.

B.It stores and serves the cluster's API, acting as the front end for all control plane communication.

C.It watches for changes to desired state and reconciles them by creating or deleting Pods.

D.It runs the container runtime and manages the lifecycle of containers on each node.

AnswerB

The kube-apiserver exposes the Kubernetes API and is the only component that talks directly to etcd. All other components, including kubelet, kube-scheduler, and controllers, communicate through it. It validates and persists objects, performs admission control, and serves REST endpoints for kubectl and clients. This makes it the central hub of the control plane.

Why this answer

The kube-apiserver is the central control plane component that exposes the Kubernetes API and is the sole client of etcd. It authenticates, authorizes, validates, and persists requests, and all other components interact with the cluster through it. Scheduling, container runtime management, and controller reconciliation are handled by separate components, not by the API server.

Exam trap

The trap here is conflating the API server with the scheduler or controller manager, since all three are control plane components that appear in kube-system.

Practice this question →

258

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

The kubelet is the node agent that watches the API server for pods bound to its node, then starts, monitors and restarts containers via the container runtime to match the manifest. It runs on every worker node.

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 →

259

MCQmedium

A developer creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. Which command would help identify why the third pod was not created?

A.kubectl logs deployment/my-deployment

B.kubectl get pods -o wide

C.kubectl get events --all-namespaces

D.kubectl describe deployment my-deployment

AnswerD

This command shows deployment events and status that reveal issues.

Why this answer

`kubectl describe deployment my-deployment` provides a detailed status of the Deployment, including the ReplicaSet events, pod template, and any conditions (e.g., `Available`, `Progressing`) that explain why the desired 3 replicas are not met. It surfaces errors like insufficient resources, failed scheduling, or image pull failures that prevent the third pod from being created.

Exam trap

The trap here is that candidates often choose `kubectl get events` (Option C) thinking it shows all cluster events, but they overlook that `kubectl describe deployment` already includes relevant events for that specific resource, making it the most targeted and efficient diagnostic tool for replica count discrepancies.

How to eliminate wrong answers

Option A is wrong because `kubectl logs deployment/my-deployment` is not a valid command; logs can only be retrieved from individual pods, not from a Deployment object, and even if corrected to target a pod, it would show application logs, not the reason for missing replicas. Option B is wrong because `kubectl get pods -o wide` only lists existing pods with additional details like node IPs, but it does not reveal why a pod was never created or why the ReplicaSet failed to reach the desired count. Option C is wrong because `kubectl get events --all-namespaces` shows events across all namespaces, which is overly broad and may obscure the specific Deployment-related events; while events can help, the most direct and efficient command for diagnosing a Deployment’s replica shortfall is `kubectl describe deployment`.

Practice this question →

260

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

Since the database Service resolves and is reachable from other pods, DNS and networking are fine; the crash stems from the application's own connection settings, such as a wrong hostname, port, or credentials in its configuration.

Why this answer

The error 'cannot connect to database at db-service:5432' while the Service is reachable from other pods strongly indicates the application's configuration (e.g., wrong hostname, port, credentials, or database name) is incorrect. Since other pods can reach the database, the issue is isolated to this pod's config, not cluster networking or the database itself. This is a classic misconfiguration scenario.

Exam trap

KCNA often tests troubleshooting logic where candidates overlook that the problem is isolated to one pod's configuration when the Service is reachable from others, instead blaming cluster-wide components like kube-proxy or the database pod.

How to eliminate wrong answers

Option A is wrong because if kube-proxy were broken, other pods would also fail to reach the Service, but the question states the database is reachable from other pods. Option B is wrong because low resource limits would typically cause OOMKills or throttling, not a specific 'cannot connect' error. Option C is wrong because the database Service is reachable from other pods, implying the database pod is running.

Practice this question →

261

MCQeasy

Which command would you use to view the current state of all Pods in the default namespace?

A.kubectl describe pods

B.kubectl get pods

C.kubectl list pods

D.kubectl show pods

AnswerB

`kubectl get pods` queries the Kubernetes API server for Pod objects in the active namespace, which defaults to `default`, returning their current phase and status. It satisfies the stem's requirement to view all Pods in that namespace without extra flags, unlike commands needing `-n` or `--all-namespaces`.

Why this answer

The `kubectl get pods` command retrieves and displays the current state of all Pods in the default namespace. It is the standard imperative command for listing Kubernetes resources, showing key fields like NAME, READY, STATUS, RESTARTS, and AGE.

Exam trap

The trap here is that candidates may confuse `kubectl get` with non-existent verbs like `list` or `show`, or mistakenly think `describe` is used for listing all resources, when `describe` is actually for detailed inspection of specific resources.

How to eliminate wrong answers

Option A is wrong because `kubectl describe pods` provides detailed information about one or more Pods (including events and container details) but does not give a concise list of all Pods and their states. Option C is wrong because `kubectl list pods` is not a valid kubectl command; the correct verb for listing resources is `get`. Option D is wrong because `kubectl show pods` is not a valid kubectl command; kubectl does not support a `show` subcommand for resources.

Practice this question →

262

Multi-Selecthard

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

Select 3 answers

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

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

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

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

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

AnswersB, D, E

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

Why this answer

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

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

Exam trap

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

Practice this question →

263

MCQhard

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

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

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

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

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

AnswerD

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

Why this answer

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

Exam trap

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

Practice this question →

264

MCQhard

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

A.The container will be evicted from the node

B.The container will be throttled

C.The container will continue to run normally

D.The container will be terminated

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

265

MCQeasy

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

A.kubectl logs web-pod -c nginx

B.kubectl logs web-pod nginx

C.kubectl describe pod web-pod

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

266

MCQhard

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

A.The container image is too large

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

C.The pod has a liveness probe that is failing

D.The kubelet on the node is not running

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

267

Multi-Selectmedium

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

Select 3 answers

A.etcd

B.kube-apiserver

C.container runtime

D.kube-proxy

E.kubelet

AnswersC, D, E

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

Why this answer

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

Exam trap

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

Practice this question →

268

MCQmedium

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

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

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

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

D.db.prod.pod.cluster.local

AnswerA

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

Why this answer

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

Exam trap

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

Practice this question →

269

MCQeasy

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

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerC

kube-apiserver exposes the REST API that kubectl, controllers and schedulers all call; it is the only component that reads and writes etcd. Every administrative task therefore passes through it, making it the cluster's single entry point.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

270

MCQeasy

Which Kubernetes component is responsible for storing the cluster state?

A.kube-scheduler

B.kube-apiserver

C.etcd

D.kube-controller-manager

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

271

MCQeasy

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

A.kubectl describe

B.kubectl get

C.kubectl exec

D.kubectl logs

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

272

MCQhard

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

A.10.0.0.1:30080

B.10.0.0.1:80

C.ClusterIP:80

D.10.0.0.2:8080

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

273

MCQhard

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

A.Set spec.affinity.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution.

B.Set spec.nodeSelector with disktype: ssd.

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

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

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

274

Multi-Selectmedium

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

Select 2 answers

A.kube-proxy

B.kube-scheduler

C.etcd

D.kubelet

E.kube-apiserver

AnswersA, D

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

Why this answer

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

Exam trap

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

Practice this question →

275

MCQeasy

What is the primary purpose of a Kubernetes Service?

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

B.To implement network routing rules on each node

C.To manage rolling updates of applications

D.To store configuration data as key-value pairs

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

276

MCQmedium

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

A.ClusterIP

B.Headless Service

C.ExternalName Service

D.NodePort

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

277

MCQeasy

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

A.kube-apiserver

B.kube-controller-manager

C.etcd

D.kube-scheduler

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

278

MCQmedium

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

A.A DaemonSet

B.A StatefulSet

C.A Job

D.A Deployment

AnswerC

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

Why this answer

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

Exam trap

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

Practice this question →

279

MCQeasy

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

A.DaemonSet

B.ReplicaSet

C.StatefulSet

D.Deployment

AnswerA

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

Why this answer

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

Exam trap

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

Practice this question →

280

MCQhard

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

A.etcd

B.Deployment controller in kube-controller-manager

C.kubelet

D.kube-scheduler

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

281

MCQhard

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

A.The apiVersion is deprecated and not supported

B.The namespace does not exist

C.The YAML syntax is invalid

D.The 'kind' field is misspelled

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

282

Multi-Selecthard

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

Select 2 answers

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

B.CPU limits are enforced using CFS quotas

C.Memory limits are soft and can be exceeded temporarily

D.Limits must be greater than or equal to requests

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

AnswersB, D

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

Why this answer

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

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

Exam trap

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

Practice this question →

283

MCQmedium

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

A.Service of type NodePort

B.Ingress

C.NetworkPolicy

D.Service of type ClusterIP

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

284

MCQmedium

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

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

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

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

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

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

285

MCQeasy

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

A.kube-apiserver

B.etcd

C.kube-scheduler

D.kube-controller-manager

AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

286

MCQmedium

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

A.The Pod's container is crashing

B.The container image has a typo

C.No node has enough resources to run the Pod

D.The Pod's liveness probe is failing

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

287

MCQhard

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

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

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

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

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

AnswerB

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

Why this answer

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

Exam trap

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

Practice this question →

288

MCQmedium

Which component is responsible for ensuring that containers are running as specified in a Pod's specification on a node?

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerB

The kubelet runs as an agent on each node, watching the API server for PodSpecs bound to its node and starting, stopping and restarting containers to match that specification. This directly satisfies the stem's requirement for the component ensuring containers run as specified on a node.

Why this answer

The kubelet is the primary node agent that runs on each node in a Kubernetes cluster. It is responsible for ensuring that containers described in Pod specifications (PodSpecs) are running and healthy. The kubelet watches for Pod assignments from the API server, creates or terminates containers via the container runtime, and continuously reports the node and Pod status back to the control plane.

Exam trap

A common pitfall is confusing the kubelet, which ensures containers are running according to the Pod spec, with the container runtime, which actually executes containers. Candidates often choose 'container runtime' because they associate 'running containers' with the container runtime, but the kubelet is the agent that manages Pod lifecycle on the node.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for actually pulling images and running containers, but it does not interpret Pod specifications or enforce desired state — it only executes commands from the kubelet via the CRI (Container Runtime Interface). Option C is wrong because kube-proxy is a network proxy that runs on each node, handling IPVS/iptables rules for Service traffic and network policies, not container lifecycle management. Option D is wrong because kube-scheduler is a control plane component that selects which node a Pod should run on based on resource availability and constraints, but it does not run on the node or manage running containers.

Practice this question →

289

MCQmedium

A user runs 'kubectl create deployment my-deploy --image=nginx' and then wants to scale the deployment to 5 replicas. Which command should they use?

A.kubectl apply -f deployment.yaml with replicas: 5

B.kubectl edit deployment my-deploy and change replicas to 5

C.kubectl patch deployment my-deploy -p '{"spec":{"replicas":5}}'

D.kubectl scale deployment my-deploy --replicas=5

AnswerD

`kubectl scale` adjusts the replica count on an existing Deployment's spec, letting the controller reconcile five Pods. It directly satisfies the stem's requirement to scale an already-created Deployment named my-deploy, without editing YAML or recreating the resource.

Why this answer

`kubectl scale` is the dedicated imperative command to change the replica count of a deployment. It directly updates the `spec.replicas` field in the deployment's desired state, and the deployment controller then adjusts the ReplicaSet and Pods accordingly. This is the simplest and most direct way to scale a deployment without modifying a YAML file or using an editor.

Exam trap

The trap is that candidates may think `kubectl edit` or `kubectl patch` are the only ways to change replicas, but the KCNA exam expects knowledge of the dedicated imperative `kubectl scale` command for direct scaling operations.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` requires a YAML file with the desired state; the user did not create a deployment.yaml file, and the command as written would fail or create a new resource. Option B is wrong because `kubectl edit` opens an interactive editor, which is not a single command and can be error-prone in scripts or automated workflows; it works but is not the recommended imperative approach. Option C is wrong because `kubectl patch` uses a JSON patch to modify the deployment, which is valid but more complex and less intuitive than the dedicated `kubectl scale` command; it also requires correct JSON syntax and is prone to typos.

Practice this question →

290

MCQeasy

A developer wants to store non-confidential configuration data as key-value pairs that can be consumed by Pods as environment variables or mounted files. Which Kubernetes resource is designed for this purpose?

A.PersistentVolumeClaim

B.Volume

C.ConfigMap

D.Secret

AnswerC

A ConfigMap is designed to hold non-confidential configuration data in key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or configuration files in a volume. It decouples configuration from container images, making applications portable and easier to manage across environments.

Why this answer

ConfigMaps are the standard Kubernetes resource for managing non-confidential configuration data. They allow you to decouple configuration artifacts from image content, and Pods can consume them as environment variables or mounted files. Secrets are for sensitive data, while Volumes and PersistentVolumeClaims are storage abstractions, not configuration stores.

Exam trap

The trap here is assuming that any key-value store can be used for configuration; Secrets are for confidential data, and using them for non-sensitive data is not recommended.

Practice this question →

291

MCQeasy

What is the primary purpose of a Kubernetes Service object?

A.To store configuration data that can be consumed by Pods

B.To manage rolling updates and rollbacks for Pods

C.To provide a stable IP address and DNS name for a set of Pods

D.To persist data beyond the lifecycle of a Pod

AnswerC

A Service selects Pods via labels and exposes them behind a single stable virtual IP and DNS name, so clients reach a consistent endpoint even as Pod IPs change on restart or rescheduling. This satisfies the stem's requirement for stable addressing across a dynamic Pod set.

Why this answer

The primary purpose of a Kubernetes Service object is to provide a stable network endpoint (a fixed IP address and DNS name) that abstracts and load-balances traffic across a dynamic set of Pods. Pods are ephemeral and can be rescheduled with new IP addresses, so the Service ensures clients can reliably reach the application without needing to track individual Pod IPs.

Exam trap

The trap here is that candidates often confuse the Service's role with that of a Deployment or ConfigMap, mistakenly thinking a Service manages Pod lifecycles or stores configuration, when its core function is purely about stable network abstraction and load balancing.

How to eliminate wrong answers

Option A is wrong because storing configuration data that can be consumed by Pods is the role of a ConfigMap (or Secret for sensitive data), not a Service. Option B is wrong because managing rolling updates and rollbacks for Pods is the responsibility of a Deployment controller, which handles replica sets and update strategies. Option D is wrong because persisting data beyond the lifecycle of a Pod is achieved through PersistentVolume (PV) and PersistentVolumeClaim (PVC) objects, not a Service.

Practice this question →

292

Multi-Selectmedium

Which TWO of the following are Kubernetes control plane components?

Select 2 answers

A.kube-apiserver

B.container runtime

C.etcd

D.kube-proxy

E.kubelet

AnswersA, C

The kube-apiserver is the control plane's front end, exposing the Kubernetes API that every other component and user interacts with. It validates and persists object state to etcd, so it runs on control plane nodes rather than worker nodes, satisfying the question's control plane component criterion.

Why this answer

kube-apiserver (A) is correct because it is the central control plane component that exposes the Kubernetes API, validating and processing all REST requests and serving as the front end of the control plane. etcd (C) is correct because it is the consistent, highly-available key-value store that persists all cluster state and is a core control plane component. The container runtime (B) is not a control plane component; it runs on each node as part of the kubelet's node-level machinery to execute containers. kube-proxy (D) is a node-level networking component that maintains network rules for Service traffic, not a control plane component. kubelet (E) is the node agent that manages pods on a worker node, so it is also not part of the control plane.

Exam trap

CNCF often tests the distinction between control plane and worker node components, expecting candidates to mistakenly include kubelet or kube-proxy as control plane components because they are essential for cluster operation but run on nodes, not the control plane.

Practice this question →

293

Multi-Selecteasy

Which TWO of the following are functions of the kube-controller-manager?

Select 2 answers

A.Managing replication and ensuring the desired number of pods are running

B.Storing cluster state

C.Exposing the Kubernetes API

D.Monitoring node health and responding to node failures

E.Assigning pods to nodes

AnswersA, D

The kube-controller-manager runs the ReplicationController and ReplicaSet controllers, which continuously reconcile observed pod counts against the declared replica count, creating or deleting pods to close any gap. This satisfies the stem's requirement for managing replication and maintaining the desired number of running pods.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicationController/ReplicaSet controller, which continuously reconciles the actual number of running pods with the desired replica count specified in the resource. Option D is correct because the kube-controller-manager includes the node controller, which monitors node health via heartbeats/leases and responds to node failures by marking nodes NotReady and evicting or rescheduling their pods. Option B is incorrect because cluster state is persisted in etcd, not by the kube-controller-manager.

Option C is incorrect because the Kubernetes API is exposed by the kube-apiserver. Option E is incorrect because pod-to-node assignment (scheduling) is performed by the kube-scheduler.

Exam trap

CNCF often tests the distinction between the kube-controller-manager and the kube-scheduler, so the trap here is that candidates mistakenly think pod-to-node assignment is a controller function, when it is exclusively handled by the scheduler.

Practice this question →

294

MCQeasy

Which component runs on every worker node and is responsible for maintaining the lifecycle of pods?

A.container runtime

B.kube-scheduler

C.kubelet

D.kube-proxy

AnswerC

The kubelet is the node agent that watches the API server for pods bound to its node, then starts, monitors and restarts containers via the container runtime. It therefore maintains pod lifecycle on every worker node, unlike the scheduler or control-plane components.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a Pod as expected, by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor Pods based on PodSpecs received from the API server. Without the kubelet, the node cannot manage Pod lifecycles.

Exam trap

A common trap on CNCF exams is confusing the kubelet (node agent for Pod lifecycle) with kube-proxy (node agent for networking), as both run on worker nodes, but kube-proxy does not manage Pods.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it does not manage Pod lifecycles or interact with the Kubernetes control plane; the kubelet delegates container operations to it via the CRI. Option B is wrong because kube-scheduler runs on the control plane, not on worker nodes, and its sole job is to assign Pods to nodes based on resource constraints and policies; it does not maintain Pod lifecycles after scheduling. Option D is wrong because kube-proxy runs on each node but handles network proxying and service abstraction (e.g., implementing iptables or IPVS rules for ClusterIP), not Pod lifecycle management.

Practice this question →

295

MCQmedium

A pod is in 'Pending' state for a long time. What is the most likely cause?

A.The pod's container has crashed

B.The pod's service endpoint is misconfigured

C.The scheduler cannot find a node that satisfies the pod's resource requests or constraints

D.The container image is invalid

AnswerC

The scheduler places pods onto nodes; when no node satisfies resource requests, affinity rules or taints, it leaves the pod unscheduled. That unsatisfied scheduling constraint is the most likely cause of a prolonged Pending state.

Why this answer

A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.

Exam trap

CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so the trap here is confusing a pod that cannot be placed on a node with a pod that fails after it starts running.

How to eliminate wrong answers

Option A is wrong because a container crash (e.g., CrashLoopBackOff) occurs after the pod is scheduled and running, not while it is still in Pending. Option B is wrong because a misconfigured service endpoint (e.g., wrong selector or port) affects network connectivity to the pod, not the pod's scheduling state; the pod would still be scheduled and running. Option D is wrong because an invalid container image (e.g., wrong tag or registry path) causes the pod to fail during container creation after scheduling, resulting in ImagePullBackOff or ErrImagePull, not a prolonged Pending state.

Practice this question →

296

Multi-Selectmedium

A cluster administrator is configuring a Pod to use a ConfigMap for environment variables. Which two methods can be used to expose ConfigMap data as environment variables in a container? (Choose two.)

Select 2 answers

A.Using envFrom with a ConfigMap reference

B.Using env with valueFrom and a ConfigMapKeyRef

C.Using a Secret with the same name as the ConfigMap

D.Using a downward API to reference the ConfigMap

E.Mounting the ConfigMap as a volume

AnswersA, B

envFrom allows you to expose all key-value pairs from a ConfigMap as environment variables in the container. This is a convenient way to inject multiple variables at once. The keys must be valid environment variable names. This method is commonly used when you want to inject all data from a ConfigMap without specifying each key individually.

Why this answer

The two correct methods are using envFrom to expose all keys from a ConfigMap as environment variables, and using env with valueFrom.configMapKeyRef to expose a specific key. These are the standard ways to inject ConfigMap data as environment variables. Mounting as a volume provides files, not environment variables, and the downward API and Secrets are unrelated to ConfigMap data exposure.

Exam trap

The trap here is confusing volume mounts with environment variable injection, or assuming that Secrets and ConfigMaps are interchangeable for this purpose.

Practice this question →

297

MCQeasy

Which kubectl command would you use to view the logs of a specific pod?

A.kubectl logs <pod-name>

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

C.kubectl describe pod <pod-name>

D.kubectl get logs <pod-name>

AnswerA

Retrieves stdout/stderr from a named container in the specified pod, satisfying the requirement to inspect that pod's output. The pod name is the positional argument; flags like -c and -f refine container selection or streaming but are not required to view logs.

Why this answer

`kubectl logs <pod-name>` is the standard Kubernetes command to retrieve logs from a specified pod. This command fetches the container's stdout and stderr streams, which are captured by the kubelet and stored as log files on the node. It directly accesses the pod's log output without requiring any additional flags or subcommands.

Exam trap

The trap here is that candidates confuse `kubectl logs` with `kubectl exec` or `kubectl describe`, thinking that logs are accessed via an exec command or that describe includes log output, when in fact logs are a distinct resource accessed through the dedicated `logs` subcommand.

How to eliminate wrong answers

Option B is wrong because `kubectl exec <pod-name> -- logs` attempts to execute a command called 'logs' inside the container, which does not exist; `kubectl exec` is used to run arbitrary commands in a running container, not to retrieve logs. Option C is wrong because `kubectl describe pod <pod-name>` displays detailed metadata, status, and events for a pod, but it does not show the actual log output from the container's stdout/stderr. Option D is wrong because `kubectl get logs` is not a valid kubectl subcommand; the correct verb is `logs`, not `get logs`, and `kubectl get` is used to list resources, not to fetch logs.

Practice this question →

298

MCQmedium

You want to run a batch job that processes data and then terminates. Which Kubernetes resource is best suited for this workload?

A.StatefulSet

B.DaemonSet

C.Job

D.Deployment

AnswerC

A Kubernetes Job creates one or more pods that run to completion, then stops — exactly matching a batch workload that processes data and terminates. Unlike a Deployment, which maintains a desired replica count indefinitely, a Job tracks successful completions, satisfying the stem's requirement for finite, run-to-finish execution.

Why this answer

A Kubernetes Job is designed for batch processing workloads that run to completion and then terminate. Unlike controllers that maintain a desired number of running Pods (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit. Once the specified number of successful completions is reached, the Job stops, making it the ideal choice for a one-time data processing task.

Exam trap

CNCF often tests the distinction between controllers that maintain 'desired state' (Deployments, StatefulSets) versus controllers that manage 'completion' (Jobs), and the trap here is that candidates mistakenly choose Deployment for any workload that 'processes data' without recognizing the terminating nature of the task.

How to eliminate wrong answers

Option A is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage (e.g., databases), not for terminating batch jobs. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for cluster-level services like logging or monitoring, not for one-off tasks. Option D is wrong because a Deployment manages a set of identical Pods with a desired replica count and supports rolling updates, but it is designed for long-running services, not for workloads that should terminate after completion.

Practice this question →

299

MCQhard

Which of the following kubectl commands would you use to apply a manifest file and also save it for later updates?

A.kubectl create -f manifest.yaml

B.kubectl patch -f manifest.yaml

C.kubectl replace -f manifest.yaml

D.kubectl apply -f manifest.yaml

AnswerD

kubectl apply sends the manifest declaratively and records the applied configuration in the last-applied-configuration annotation, enabling subsequent three-way merges. This satisfies the requirement to apply a manifest and retain it for later updates, unlike create or replace.

Why this answer

`kubectl apply` uses a declarative approach: it creates the resource if it doesn't exist and updates it if it does, while also storing the last-applied configuration as an annotation (`kubectl.kubernetes.io/last-applied-configuration`). This allows future `apply` calls to perform a three-way merge diff (current live state, last-applied config, and new manifest) to intelligently update the resource, making it the standard for managing manifests that need ongoing updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (which works for initial creation but fails on re-apply) with `kubectl apply` (which is idempotent and designed for ongoing updates), or they mistakenly think `kubectl replace` is equivalent to `apply` when it actually performs a full replacement without merge logic.

How to eliminate wrong answers

Option A is wrong because `kubectl create` is imperative and will fail with an error if the resource already exists, so it cannot be used for later updates. Option B is wrong because `kubectl patch` applies partial modifications directly to a live resource without saving the manifest state for future reconciliation; it does not store a last-applied configuration. Option C is wrong because `kubectl replace` is a destructive imperative command that replaces the entire resource definition, but it does not track the manifest for later updates and can cause drift if the resource was modified outside the manifest.

Practice this question →

300

MCQeasy

Which Kubernetes object provides stable network endpoints and load balancing for a set of pods?

A.Deployment

B.ConfigMap

C.Service

D.Pod

AnswerC

A Kubernetes Service provides a stable virtual IP and DNS name that persists independently of pod lifecycles, satisfying the stem’s requirement for stable network endpoints. It uses label selectors to identify target pods and distributes incoming traffic across them via kube-proxy’s iptables or IPVS rules, fulfilling the load-balancing constraint without relying on individual pod IPs that change on rescheduling.

Why this answer

A Kubernetes Service provides a stable virtual IP (ClusterIP) and DNS name that remains constant even as Pods are created or destroyed. It uses label selectors to identify target Pods and performs TCP/UDP load balancing across them, ensuring reliable network access without requiring clients to track ephemeral Pod IPs.

Exam trap

The trap here is that candidates often confuse a Deployment’s ability to manage Pod replicas with providing a stable network endpoint, forgetting that Pod IPs are ephemeral and only a Service offers a fixed virtual IP and load balancing.

How to eliminate wrong answers

Option A is wrong because a Deployment manages Pod replicas and their rollout strategy, but it does not provide a stable network endpoint or load balancing; Pod IPs change on restart. Option B is wrong because a ConfigMap is used to inject configuration data (key-value pairs) into Pods, not to expose network endpoints. Option D is wrong because a Pod is an ephemeral unit with a non-static IP address; it cannot guarantee stable network access or load balancing across multiple Pods.

Practice this question →