CCNA Kubernetes Fundamentals Questions — Page 2 of 6

Multi-Selecthard

A developer is troubleshooting a Pod that is stuck in the Pending state. Which two commands can help identify the reason for the scheduling failure? (Choose two.)

Select 2 answers

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

B.kubectl top pod <pod-name>

C.kubectl logs <pod-name>

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

E.kubectl describe pod <pod-name>

AnswersD, E

This command filters cluster events related to the specific Pod. Events include scheduler messages such as '0/3 nodes are available: 3 Insufficient cpu', which directly explain why the Pod cannot be scheduled. It is an effective way to isolate relevant scheduling failures.

Why this answer

When a Pod is Pending, the scheduler has not placed it on a node. The describe command and filtered events both surface scheduler events that state the reason, such as insufficient resources or taints. Logs, exec, and top require a running container and are not useful for a Pod that has never started.

Exam trap

The trap here is reaching for logs or exec to debug a Pending Pod, but those require a running container and will not work before scheduling.

Practice this question →

Multi-Selecteasy

Which two of the following are benefits of using Kubernetes for container orchestration? (Select TWO.)

Select 2 answers

A.Integrated continuous integration pipeline

B.Automatic code compilation

C.Self-healing: automatically restarts failed containers

D.Built-in database management

E.Automated rollouts and rollbacks

AnswersC, E

Kubernetes self-healing is performed by the kubelet and ReplicaSet controllers, which detect failed containers and restart or replace them automatically. This satisfies the availability benefit, maintaining the desired replica count without manual intervention when a container crashes.

Why this answer

Option C is correct because Kubernetes provides self-healing through controllers such as ReplicaSets and Deployments: when a container or Pod fails, the kubelet and control-plane reconciliation loop detect the deviation from the desired state and automatically restart or replace the failed container to maintain the declared replica count. Option E is correct because Kubernetes supports automated rollouts and rollbacks via Deployment objects, where changes to the Pod template trigger a rolling update (using maxSurge/maxUnavailable) and `kubectl rollout undo` reverts to a previous ReplicaSet revision. The unmarked options do not belong: A is incorrect because Kubernetes is an orchestration platform, not a CI system (CI is handled by tools like Jenkins, GitLab CI, or Tekton), B is incorrect because Kubernetes does not compile source code—it runs pre-built container images, and D is incorrect because Kubernetes does not provide built-in database management; stateful databases require operators or external services.

Exam trap

A common pitfall is assuming that Kubernetes includes built-in CI/CD, code compilation, or database management features. In reality, these are external tools integrated separately. Kubernetes core features focus on container orchestration, including self-healing (via liveness probes and controllers) and automated rollouts/rollbacks (via Deployments).

Practice this question →

MCQeasy

An operator needs a workload that runs exactly one Pod on every node in the cluster, including nodes added later, to collect host-level logs. Which Kubernetes resource should be used?

A.A Job with a high parallelism value

B.A StatefulSet with podManagementPolicy set to Parallel

C.A DaemonSet

D.A Deployment with replicas equal to the node count

AnswerC

A DaemonSet ensures that a copy of a Pod runs on every eligible node and automatically schedules new Pods onto nodes that join the cluster later. That matches the requirement of one log-collector Pod per node, including future nodes, without manual intervention or node-specific manifests.

Why this answer

Per-node agents such as log shippers, node exporters, and CNI components are implemented as DaemonSets. The DaemonSet controller creates one Pod per eligible node and reacts to cluster membership changes by adding Pods on new nodes, which no replica-count-based controller can guarantee. Deployments, StatefulSets, and Jobs lack that node-scoped placement semantics.

Exam trap

The trap here is assuming a Deployment with a replica count matching the number of nodes will spread Pods evenly, when the scheduler actually offers no such per-node guarantee.

Practice this question →

MCQhard

A developer wants to inject environment variables into a pod from a ConfigMap named 'app-config'. Which YAML snippet correctly mounts all key-value pairs from the ConfigMap as environment variables?

A.env: - name: CONFIG value: "$(CONFIGMAP)"

B.envFrom: - configMapRef: name: app-config

C.volumes: - name: config configMap: name: app-config volumeMounts: - name: config mountPath: /etc/config

D.env: - name: CONFIG valueFrom: configMapKeyRef: name: app-config key: config.yaml

AnswerB

Using `envFrom` with `configMapRef` imports every key-value pair from `app-config` as environment variables in one declaration, satisfying the requirement to mount all pairs rather than selecting individual keys. The alternative `valueFrom.configMapKeyRef` maps a single key per variable, so it cannot expose the whole ConfigMap without listing each key explicitly.

Why this answer

`envFrom` with a `configMapRef` injects all key-value pairs from the ConfigMap named 'app-config' as environment variables into the container. This is the standard Kubernetes method for bulk injection of ConfigMap data into environment variables, as opposed to selecting individual keys.

Exam trap

The trap here is that candidates often confuse `envFrom` (bulk injection) with `env` + `configMapKeyRef` (single key injection) or volume mounts (file-based injection), leading them to pick options that inject only one key or mount files instead of environment variables.

How to eliminate wrong answers

Option A is wrong because `env` with `value: "$(CONFIGMAP)"` is not valid syntax; Kubernetes does not support referencing a ConfigMap via a variable expansion like `$(CONFIGMAP)` — it requires explicit `valueFrom` or `envFrom`. Option C is wrong because it mounts the ConfigMap as a volume at `/etc/config`, which injects keys as files, not as environment variables — this does not satisfy the requirement to inject them as environment variables. Option D is wrong because it uses `env` with `configMapKeyRef` to inject only a single key (`config.yaml`) from the ConfigMap, not all key-value pairs.

Practice this question →

MCQeasy

A developer wants to run a one-time batch job that processes a queue and then terminates. Which Kubernetes resource should they use?

A.Job

B.StatefulSet

C.Deployment

D.DaemonSet

AnswerA

A Job creates pods that run to completion and then stops, tracking successful finishes rather than maintaining a persistent replica count. That matches a one-time batch process that drains a queue and terminates, unlike a Deployment, which restarts pods indefinitely.

Why this answer

A Kubernetes Job is designed for finite, batch-oriented tasks that run to completion, such as processing a queue and then terminating. Unlike controllers that maintain a desired state (like Deployments or StatefulSets), a Job creates one or more Pods and ensures they successfully exit, making it the correct choice for a one-time batch job.

Exam trap

The trap here is that candidates confuse a Job with a Deployment, assuming that any workload that 'runs' must be a Deployment, but Deployments are designed for long-running services and will restart terminated Pods, whereas a Job is the correct resource for workloads that should run to completion and then stop.

How to eliminate wrong answers

Option B (StatefulSet) is wrong because it is used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (Deployment) is wrong because it manages a set of Pods intended to run continuously (e.g., web servers) and will restart Pods if they exit, which is the opposite of a terminating batch job. Option D (DaemonSet) is wrong because it ensures that a copy of a Pod runs on every node (or a subset of nodes) in the cluster, typically for long-running system services like log collectors or monitoring agents, not for one-time tasks.

Practice this question →

Multi-Selectmedium

Which TWO resources can be used to store configuration data separately from container images?

Select 2 answers

A.Service

B.PersistentVolume

C.Secret

D.Deployment

E.ConfigMap

AnswersC, E

Secret stores sensitive configuration such as passwords, tokens and TLS certificates as base64-encoded key-value data, mounted into pods or exposed as environment variables. It keeps credentials out of container images, complementing ConfigMap for non-confidential settings.

Why this answer

ConfigMap (E) is correct because it is the Kubernetes API object designed to hold non-confidential configuration data as key-value pairs, which pods can consume via environment variables, command-line arguments, or mounted volumes, keeping that data out of the container image. Secret (C) is correct because it serves the analogous purpose for sensitive configuration data such as passwords, tokens, and certificates, storing them base64-encoded and injecting them into pods separately from the image. Both objects decouple configuration from the image, so the same image can be reused across environments with different settings.

Service (A) is incorrect because it provides stable network access and load balancing to a set of pods, not configuration storage. PersistentVolume (B) is incorrect because it supplies durable block or file storage for application data, not configuration key-value data. Deployment (D) is incorrect because it manages the desired state and rollout of replicated pods, not configuration content.

Exam trap

CNCF often tests the distinction between storage for configuration data (ConfigMaps/Secrets) vs. storage for application data (PersistentVolumes), so candidates mistakenly select PersistentVolume thinking it can store config files, but it is intended for stateful workloads like databases, not for decoupling configuration from images.

Practice this question →

MCQmedium

Which Kubernetes command displays the current state of a pod, including its IP address, node, and container statuses?

A.kubectl get pod -o wide

B.kubectl describe pod

C.kubectl logs pod

D.kubectl get pod

AnswerA

The -o wide output flag extends the default pod listing with the pod IP and node name, alongside status and container readiness. Plain kubectl get pod omits those columns, and describe or logs show different detail.

Why this answer

`kubectl get pod -o wide` extends the default output to include additional columns such as the pod's IP address, the node it is scheduled on, and the container statuses (e.g., READY state). This command queries the Kubernetes API server for the pod's current state and formats the response with extra details, making it the most direct way to view the pod's IP and node assignment in a single line.

Exam trap

The trap here is that candidates often assume `kubectl get pod` alone shows all relevant pod details, but Kubernetes tests the specific requirement for the `-o wide` flag to expose the pod IP and node fields, which are hidden in the default output.

How to eliminate wrong answers

Option B is wrong because `kubectl describe pod` provides a detailed, multi-line description of a pod, including its IP address, node, and container statuses, but it is not a single-line display of the current state; it is a verbose output meant for troubleshooting, not a concise summary. Option C is wrong because `kubectl logs pod` retrieves the container logs from the pod's stdout/stderr, not the pod's state, IP address, or node information; it is used for debugging application output, not for inspecting pod metadata. Option D is wrong because `kubectl get pod` (without `-o wide`) displays only the basic columns (NAME, READY, STATUS, RESTARTS, AGE) and omits the pod IP and node fields, which are only added with the `-o wide` output format.

Practice this question →

MCQhard

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

A.The image 'myapp:v2' does not exist.

B.The container exceeds its memory limit.

C.The liveness probe is failing.

D.The application crashes shortly after starting.

AnswerD

BackOff means the kubelet is delaying a restart after a container exit, with the delay growing exponentially. Repeated events after startup indicate the process terminates on its own, typically from a crash or failed health check, rather than an image pull or scheduling failure.

Why this answer

The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Exam trap

The KCNA exam often tests the distinction between 'ImagePullBackOff' (image not found) and 'CrashLoopBackOff' (container crashes after start), so candidates must recognize that 'BackOff' events after the container starts point to a runtime crash, not a pull failure.

How to eliminate wrong answers

Option A is wrong because if the image 'myapp:v2' does not exist, the pod would show 'ErrImagePull' or 'ImagePullBackOff' events, not 'BackOff' after the container starts. Option B is wrong because exceeding the memory limit causes an 'OOMKilled' status and a container restart, but the event would typically be 'OOMKilled' or 'CrashLoopBackOff', not specifically 'BackOff' after a successful start. Option C is wrong because a failing liveness probe results in the container being killed and restarted, but the event would be 'Unhealthy' or 'Liveness probe failed', and the pod would show 'CrashLoopBackOff' rather than 'BackOff' immediately after start.

Practice this question →

MCQmedium

Which of the following is a correct YAML structure for a Service of type ClusterIP?

A.apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - port: 80

B.apiVersion: v1 kind: Pod metadata: name: my-service spec: selector: app: myapp ports: - port: 80

C.apiVersion: apps/v1 kind: Service metadata: name: my-service spec: selector: app: myapp ports: - port: 80

D.apiVersion: v1 kind: Service metadata: name: my-service spec: app: myapp ports: - port: 80

AnswerA

This manifest declares apiVersion v1, kind Service, and a spec containing a label selector plus a ports entry with port 80. Omitting type defaults to ClusterIP, so the structure is a valid ClusterIP Service definition.

Why this answer

It defines a Kubernetes Service of kind Service with apiVersion v1, which is the correct API group for core Service objects. The spec includes a selector to target pods with label app: myapp and a port mapping with port 80, which is the standard structure for a ClusterIP Service (the default type when type is omitted). The selector field is required to route traffic to matching pods, and the ports array correctly specifies the service port.

Exam trap

A common pitfall is confusing the apiVersion for core resources (v1) with that of named API groups (e.g., apps/v1). Candidates often mistakenly use apps/v1 for Services, or confuse the Service spec structure with that of a Pod or Deployment.

How to eliminate wrong answers

Option B is wrong because it uses kind: Pod instead of kind: Service, and Pods do not have a selector or ports field in their spec; these fields are specific to Service objects. Option C is wrong because it uses apiVersion: apps/v1, which is for resources like Deployments and StatefulSets, not Services; Services must use apiVersion: v1. Option D is wrong because it places app: myapp directly under spec instead of using a selector field; the selector is a required subfield of spec for Services to identify target pods, and omitting it means the Service will not route traffic to any pods.

Practice this question →

MCQmedium

A developer wants to deploy a stateless web application that should maintain three running instances at all times. Which Kubernetes resource should they use?

A.Job

B.Deployment

C.StatefulSet

D.DaemonSet

AnswerB

A Deployment manages a ReplicaSet that continuously reconciles the pod count to three, restarting or replacing failed pods automatically. It suits stateless workloads, whereas StatefulSet adds stable identities and storage that this application does not require.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure a specified number of Pod replicas (in this case, three) are running at all times. It supports rolling updates and rollbacks, making it ideal for stateless web applications that require high availability and declarative scaling.

Exam trap

In the Kubernetes exam, candidates often confuse Deployment and StatefulSet. A common trap is selecting StatefulSet for any workload needing stable network identities or persistent storage, but for stateless web applications that simply require a fixed number of replicas and rolling updates, Deployment is the correct choice.

How to eliminate wrong answers

Option A is wrong because a Job is designed to run a finite task to completion (e.g., batch processing) and does not maintain a desired number of running instances. Option C is wrong because a StatefulSet is intended for stateful applications that require stable network identities and persistent storage, not for stateless web apps. Option D is wrong because a DaemonSet ensures that one Pod runs on each node (or a subset of nodes) in the cluster, which does not guarantee exactly three running instances regardless of node count.

Practice this question →

MCQhard

You create a Pod with a liveness probe that uses an HTTP GET on port 8080, path /healthz. The probe fails after the container starts. What will happen to the Pod?

A.The Pod will be marked as Unhealthy and removed from Service endpoints

B.The container will be restarted automatically

C.The Pod will be evicted from the node

D.The Pod will be deleted and recreated on a different node

AnswerB

A failing liveness probe signals the kubelet that the container is unhealthy. The kubelet kills that container and restarts it according to the pod's restartPolicy, rather than deleting the pod. This mechanism satisfies the stem's scenario of an HTTP GET probe failing after startup.

Why this answer

A liveness probe is designed to determine if a container is still running properly. When an HTTP GET liveness probe fails, kubelet considers the container unhealthy and automatically restarts it according to the Pod's restart policy (defaulting to Always). This ensures the container can recover from transient failures without manual intervention.

Exam trap

The trap here is confusing liveness probes with readiness probes: candidates often think a failing liveness probe removes the Pod from Service endpoints, but that is the job of a readiness probe, while liveness probes only trigger container restarts.

How to eliminate wrong answers

Option A is wrong because removing a Pod from Service endpoints is the behavior of a readiness probe, not a liveness probe; liveness probes only trigger container restarts. Option C is wrong because Pod eviction is caused by node-level issues like resource pressure or node failure, not by a failing liveness probe. Option D is wrong because the Pod is not deleted or recreated on a different node; the container is restarted in place on the same node.

Practice this question →

MCQmedium

You have a Deployment that manages 3 replicas of a web application. You want to perform a rolling update with zero downtime. Which kubectl command should you use?

A.kubectl set image deployment/myapp mycontainer=myimage:v2

B.kubectl delete pod myapp-xyz --grace-period=0

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

D.kubectl rollout undo deployment/myapp

AnswerA

`kubectl set image` triggers the Deployment controller to create a new ReplicaSet and roll pods over incrementally, honouring maxUnavailable and maxSurge so capacity never drops to zero. This satisfies the stem's zero-downtime constraint, unlike editing a bare pod or scaling, which bypass the rolling-update mechanism entirely.

Why this answer

`kubectl set image deployment/myapp mycontainer=myimage:v2` triggers a rolling update on the Deployment, which by default creates a new ReplicaSet and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime. The Deployment controller manages the update strategy (default: RollingUpdate) and maintains the desired number of replicas throughout the process.

Exam trap

The trap here is that candidates may confuse a simple pod deletion or scaling operation with a proper rolling update, or think that `rollout undo` is used to apply a new version instead of reverting to a previous one.

How to eliminate wrong answers

Option B is wrong because `kubectl delete pod myapp-xyz --grace-period=0` forcefully deletes a single pod, which does not perform a rolling update and can cause downtime if the pod is not immediately replaced by the ReplicaSet; it also bypasses the Deployment's update strategy. Option C is wrong because `kubectl patch deployment myapp -p '{"spec":{"replicas":5}}'` only scales the Deployment to 5 replicas, which does not update the container image and does not perform a rolling update. Option D is wrong because `kubectl rollout undo deployment/myapp` reverts the Deployment to a previous revision, which is used for rollback, not for performing a new rolling update.

Practice this question →

MCQmedium

A Deployment is created with `replicas: 3`. After applying the manifest, only 2 pods are running and one is in Pending state. What is the most likely reason?

A.The Service selector does not match

B.The Deployment name is misspelled

C.There are insufficient resources on the nodes

D.The container image is invalid

AnswerC

The scheduler leaves a pod Pending when no node has enough allocatable CPU or memory to satisfy its requests. Insufficient cluster resources prevent the third replica from being placed, while the other two run normally.

Why this answer

When a Pod remains in Pending state, it means the scheduler cannot find a node that satisfies the Pod's resource requirements (CPU, memory, or other constraints). Since two Pods are running successfully, the Deployment configuration (image, name, selector) is valid, and the issue is that the cluster lacks sufficient capacity to schedule the third replica. The scheduler continuously evaluates node resources and will leave the Pod pending until resources become available or the request is adjusted.

Exam trap

CNCF often tests the distinction between Pod lifecycle phases (Pending vs. CrashLoopBackOff vs. ImagePullBackOff) to see if candidates confuse scheduling failures with runtime or image errors.

How to eliminate wrong answers

Option A is wrong because a Service selector mismatch would not cause a Pod to be in Pending state; it would affect traffic routing but not Pod scheduling or creation. Option B is wrong because a misspelled Deployment name would cause the manifest to fail at creation time or create a separate resource, not result in a partially running Deployment with two Pods. Option D is wrong because an invalid container image would cause the Pod to enter ImagePullBackOff or ErrImagePull state, not Pending; Pending occurs before the container runtime attempts to pull the image.

Practice this question →

MCQeasy

Which component on a worker node is responsible for enforcing the desired state of pods as defined in the pod specification?

A.kube-scheduler

B.kube-proxy

C.container runtime

D.kubelet

AnswerD

The kubelet runs as an agent on each worker node, watching the API server for PodSpecs bound to its node. It then starts containers via the container runtime and continuously reconciles actual state to the desired state, restarting or stopping pods as needed.

Why this answer

The kubelet is the primary node agent that runs on each worker node and is responsible for ensuring that containers are running in a pod as specified by the pod's manifest (PodSpec). It continuously monitors pod status and takes corrective actions, such as restarting containers or re-creating pods, to match the desired state defined in the Kubernetes API.

Exam trap

The trap here is that candidates often confuse the kubelet's role with the container runtime or kube-scheduler, assuming that running containers automatically enforces the desired state, when in fact the kubelet is the only component that actively reconciles the actual state with the PodSpec.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, but it does not enforce the desired state of pods on a worker node. Option B is wrong because kube-proxy handles network rules and load balancing for services on each node, not pod lifecycle management or state enforcement. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, but it does not interpret the PodSpec or enforce the desired state; that is the kubelet's job.

Practice this question →

MCQhard

A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?

A.Insufficient CPU or memory resources available in the cluster

B.The node selector in the pod spec does not match any node labels

C.The container runtime is not functioning on the node

D.The pod's PVC is not yet bound to a PV

AnswerC

A non-functioning container runtime produces container creation or start failures on an already-scheduled node, typically surfacing as 'ContainerCreating' or 'CrashLoopBackOff', not 'Pending'. Pending specifically indicates the scheduler cannot bind the pod, driven by insufficient resources, unsatisfied node selectors or affinity, or unbound PersistentVolumeClaims.

Why this answer

A non-functioning container runtime on a node typically results in pod states like CrashLoopBackOff or Error, not prolonged 'Pending' state. Pending state occurs when a pod cannot be scheduled. Insufficient resources (A), node selector mismatch (B), and unbound PVCs (D) are common causes of scheduling failures that keep a pod in Pending.

Container runtime issues affect pod execution after scheduling, not the scheduling process itself. Therefore, C is NOT a common cause for a pod to remain Pending.

Exam trap

Candidates often confuse issues that affect pod scheduling with those that affect pod execution. Container runtime problems cause pods to fail after starting, not to remain in Pending state. The question tests understanding of which conditions prevent scheduling vs. those that impact running pods.

How to eliminate wrong answers

Option A is wrong because insufficient CPU or memory resources in the cluster is a common cause for a pod to remain in 'Pending' state, as the scheduler cannot find a node with enough free resources to place the pod. Option C is wrong because a non-functioning container runtime on a node will cause the pod to stay 'Pending' if the node is the only candidate, as the kubelet cannot start containers; however, this is a less common but valid cause. Option D is wrong because an unbound PVC (PersistentVolumeClaim) is a classic reason for a pod to be stuck in 'Pending', as the scheduler waits for the volume to be bound before proceeding with pod placement.

Practice this question →

Multi-Selecthard

Which THREE are valid ways to provide configuration data to a pod in Kubernetes?

Select 3 answers

A.Use an init container to write configuration to a shared volume

B.Mount a ConfigMap as a volume

C.Mount a Secret as a volume

D.Hardcode environment variables in the pod spec that contain sensitive data

E.Use environment variables from a ConfigMap

AnswersB, C, E

ConfigMaps can be mounted as files in a pod.

Why this answer

A ConfigMap is a Kubernetes API object designed to store non-confidential configuration data in key-value pairs. Mounting a ConfigMap as a volume makes its data available as files in the pod's filesystem, allowing applications to read configuration without hardcoding it into the container image or pod spec. This approach decouples configuration from containerized applications, following the principle of immutable infrastructure.

Exam trap

The KCNA exam often tests the misconception that any method of injecting data into a pod is a 'valid' configuration approach, but the KCNA exam expects you to recognize that only native Kubernetes API objects (ConfigMaps and Secrets) are the recommended and valid ways to provide configuration data, rejecting ad-hoc methods like init container scripts or hardcoded values.

Practice this question →

MCQeasy

Which Kubernetes primitive is the smallest and simplest unit in the Kubernetes object model that you can create or deploy?

A.ReplicaSet

B.Pod

C.Deployment

D.Container

AnswerB

A Pod is the atomic scheduling unit: one or more containers sharing a network namespace and storage volumes, always co-located on a single node. It is the smallest deployable object, so it satisfies the stem's constraint of being the simplest creatable unit.

Why this answer

B is correct because a Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in a cluster and can contain one or more containers that share the same network namespace, storage volumes, and lifecycle. You create and deploy Pods directly, while higher-level controllers like ReplicaSets and Deployments manage Pods as their fundamental building block.

Exam trap

The trap here is that candidates often confuse 'Container' as the smallest unit because they think of Docker containers, but Kubernetes abstracts containers into Pods, and you cannot deploy a container directly without a Pod wrapper.

How to eliminate wrong answers

Option A is wrong because a ReplicaSet is a higher-level controller that ensures a specified number of Pod replicas are running at all times; it is not the smallest or simplest unit, as it depends on Pods. Option C is wrong because a Deployment is an even higher-level abstraction that manages ReplicaSets and Pods, providing declarative updates and rollbacks; it is not the smallest deployable unit. Option D is wrong because a Container is not a Kubernetes object; it is a runtime instance of a container image that runs inside a Pod, and Kubernetes does not allow you to create or deploy a Container directly as a standalone object.

Practice this question →

MCQeasy

Which control plane component is responsible for assigning pods to nodes?

A.etcd

B.kube-apiserver

C.kube-scheduler

D.kube-controller-manager

AnswerC

kube-scheduler watches for newly created pods with no assigned node and selects a suitable node based on resource requests, affinity and taints. This satisfies the assignment responsibility, unlike kubelet, which only runs pods already bound to its node.

Why this answer

The kube-scheduler is the control plane component responsible for assigning pods to nodes. It watches for newly created pods that have no node assignment and selects an optimal node for each pod based on resource requirements, constraints, policies, and data locality. The scheduler does not actually run the pod; it updates the pod's `nodeName` field via the API server, which then triggers the kubelet on the chosen node to launch the pod.

Exam trap

A common misconception is that kube-apiserver handles scheduling because it is the central API gateway, but the scheduler is a distinct component that runs the scheduling algorithm and communicates with the API server to bind pods to nodes.

How to eliminate wrong answers

Option A is wrong because etcd is a distributed key-value store that holds the cluster state, not a component that makes scheduling decisions. Option B is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the API and validates requests, but it does not assign pods to nodes. Option D is wrong because kube-controller-manager runs controller processes like the node controller and replication controller, but it does not handle pod-to-node assignment; that is the sole responsibility of the scheduler.

Practice this question →

Multi-Selectmedium

Which THREE of the following are valid use cases for Kubernetes Namespaces? (Select 3)

Select 3 answers

A.To enforce resource quotas and limits on the resources within the namespace

B.To create separate environments like development, staging, and production in the same cluster

C.To isolate cluster-wide resources such as Nodes and PersistentVolumes

D.To improve performance by reducing network latency between Pods

E.To separate resources for different teams or projects within a single cluster

AnswersA, B, E

ResourceQuota and LimitRange objects are scoped to a namespace, so quotas and default limits apply only to workloads inside it. This satisfies the need to cap aggregate CPU, memory and object counts per team or environment.

Why this answer

Option A is correct because Namespaces are the scope at which Kubernetes ResourceQuota and LimitRange objects are applied, letting administrators cap aggregate CPU/memory/storage consumption and enforce per-container defaults for all workloads inside that namespace. Option B is correct because a single cluster can host distinct dev, staging, and production environments as separate Namespaces, each with its own objects, RBAC, and quotas, without provisioning additional clusters. Option E is correct because Namespaces provide logical partitioning so multiple teams or projects can share one cluster while keeping their Pods, Services, ConfigMaps, and Secrets scoped and access-controlled independently.

Option C is incorrect because Nodes and PersistentVolumes are cluster-scoped resources that live outside any Namespace and cannot be isolated by one. Option D is incorrect because Namespaces are purely a logical/API-scoping construct and have no effect on the data plane, so they do not reduce network latency between Pods.

Exam trap

A common trap in the Kubernetes exam is that candidates mistakenly think namespaces can isolate cluster-wide resources like Nodes or PersistentVolumes, but these are not namespaced and cannot be scoped to a namespace.

Practice this question →

MCQmedium

You have two pods in different namespaces that need to communicate using a stable IP address. Which Kubernetes object provides a stable endpoint for a set of pods?

A.ConfigMap

B.Ingress

C.Service

D.Deployment

AnswerC

A Service provides a stable virtual IP and DNS name that load-balances across selected pods, independent of individual pod IPs. This satisfies cross-namespace communication by giving a consistent endpoint, provided the Service is reachable from the other namespace.

Why this answer

A Kubernetes Service provides a stable IP address and DNS name that remains constant regardless of pod restarts or rescheduling, enabling reliable communication between pods in different namespaces. Unlike pods, which have ephemeral IPs, a Service selects a set of pods via label selectors and load-balances traffic to them, ensuring a stable endpoint across namespace boundaries.

Exam trap

A common misconception is that a Deployment itself provides a stable network endpoint, but a Deployment only manages pod lifecycle; the Service object is required to expose those pods with a fixed IP and DNS name.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store configuration data as key-value pairs, not to provide network endpoints or stable IPs for pod communication. Option B is wrong because an Ingress manages external HTTP/HTTPS traffic routing to Services, but it does not itself provide a stable internal IP; it relies on a Service for that purpose. Option D is wrong because a Deployment manages pod replicas and updates, but it does not expose a stable IP; pods managed by a Deployment have dynamic IPs that change on restart, so a Service is needed for a stable endpoint.

Practice this question →

MCQmedium

You have a Pod that is in 'Pending' state. What is the most likely cause?

A.The node is out of CPU or memory resources.

B.The application inside the container crashed.

C.The container image is missing.

D.The Service does not have any endpoints.

AnswerA

The scheduler cannot place a pod when no node has sufficient allocatable CPU or memory. Unschedulable pods remain Pending rather than being assigned to a node, making resource exhaustion the most common cause of this state.

Why this answer

A Pod in 'Pending' state indicates that the scheduler has not yet assigned it to a node. The most common reason is insufficient resources (CPU or memory) on any available node, causing the scheduler to fail to find a suitable node that meets the Pod's resource requests. This is a core scheduling failure in Kubernetes.

Exam trap

CNCF often tests the distinction between Pod lifecycle states, and the trap here is confusing 'Pending' (pre-scheduling) with post-scheduling failures like image pull errors or container crashes, which have distinct states (e.g., ImagePullBackOff, CrashLoopBackOff).

How to eliminate wrong answers

Option B is wrong because a container crash (e.g., application exit code non-zero) results in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option C is wrong because a missing container image causes the Pod to enter 'ImagePullBackOff' or 'ErrImagePull' state after scheduling, not 'Pending'. Option D is wrong because a Service lacking endpoints does not affect Pod scheduling; it is a networking issue that affects service discovery, not the Pod's lifecycle state.

Practice this question →

MCQmedium

A service of type ClusterIP is created but pods cannot reach it using the service name. The pods are in the same namespace. What is a likely cause?

A.The service is not exposed externally

B.CoreDNS is not running or misconfigured

C.The service port does not match the container port

D.The selector does not match any pod labels

AnswerB

CoreDNS resolves cluster-internal service names, so if it is not running or is misconfigured, pods cannot translate the ClusterIP service name into its virtual IP. Since the pods share the namespace, the fault lies in DNS resolution rather than NetworkPolicy or selector mismatch.

Why this answer

When a ClusterIP service cannot be reached by its DNS name from pods in the same namespace, the most common cause is that CoreDNS (the cluster DNS resolver) is not running or is misconfigured. Kubernetes relies on CoreDNS to resolve service names to ClusterIP addresses; if CoreDNS is down or its configuration is incorrect, DNS queries for the service name will fail, even though the service itself and its endpoints are healthy.

Exam trap

The exam tests the distinction between DNS resolution failures and connectivity failures, trapping candidates who confuse a selector mismatch or port mismatch with a DNS issue, even though those would still allow the service name to resolve.

How to eliminate wrong answers

Option A is wrong because ClusterIP services are internal by design and do not need external exposure for pods to reach them via the service name; external exposure is irrelevant to internal DNS resolution. Option C is wrong because a port mismatch would cause connection timeouts or resets at the network layer, but the pod would still be able to resolve the service name via DNS and initiate a connection; the symptom described is that pods cannot reach the service using the name, which points to DNS failure, not port mismatch. Option D is wrong because if the selector does not match any pod labels, the service would have no endpoints and traffic would be dropped, but the service name would still resolve to a ClusterIP via DNS; the issue is that pods cannot reach the service using the name, implying DNS resolution itself is failing.

Practice this question →

MCQeasy

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

A.kube-controller-manager

B.kube-apiserver

C.etcd

D.kube-scheduler

AnswerB

The kube-apiserver exposes the REST API that every administrative tool, including kubectl, and every internal component uses to read or mutate cluster state. It is the only component that communicates directly with etcd, making it the sole 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 exposes the Kubernetes API (over HTTPS), validates and processes RESTful operations (e.g., kubectl commands, pod creation), and serves as the communication gateway between internal components (e.g., etcd, scheduler, controller-manager) and external clients. Without the API server, no administrative action or resource change can be initiated in the cluster.

Exam trap

A common trap is believing that etcd is the primary entry point because it stores all cluster data. However, etcd is a backend storage component and is never accessed directly by users or administrative tools—all reads and writes must pass through the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager is not an entry point for API requests; it runs controller loops (e.g., Node Controller, Replication Controller) that watch the API server for desired state changes and reconcile the current state, but it does not accept external administrative tasks. Option C is wrong because etcd is a distributed key-value store that holds cluster state data, but it is not directly accessible for administrative tasks or API requests—all interactions with etcd must go through the kube-apiserver to ensure consistency and authorization. Option D is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints; it does not serve as an entry point for administrative tasks or API calls, and it only interacts with the API server to read pod specs and write scheduling decisions.

Practice this question →

MCQhard

You have a ConfigMap named 'app-config' and a Secret named 'db-password'. You want to mount them into a pod. Which statement is correct?

A.Secrets can be mounted as volumes, but ConfigMaps cannot

B.Both ConfigMaps and Secrets can be mounted as volumes

C.ConfigMaps can be mounted as volumes, but Secrets cannot

D.ConfigMaps and Secrets can only be exposed as environment variables

AnswerB

Both ConfigMaps and Secrets are API objects whose data can be projected into a pod as files via a volume mount. Each key becomes a file, so either can be mounted alongside the other in the same pod.

Why this answer

Both ConfigMaps and Secrets are Kubernetes API objects designed to decouple configuration data from container images. They can be mounted as volumes into pods, allowing files to be created in the container's filesystem with the data from the ConfigMap or Secret. This is a core feature for managing configuration and sensitive data in Kubernetes.

Exam trap

CNCF often tests the misconception that Secrets and ConfigMaps have different mounting capabilities, when in fact both support volume mounts and environment variable injection, with the key difference being that Secrets are base64-encoded and intended for sensitive data.

How to eliminate wrong answers

Option A is wrong because ConfigMaps can indeed be mounted as volumes, just like Secrets. Option C is wrong because Secrets can be mounted as volumes, just like ConfigMaps. Option D is wrong because both ConfigMaps and Secrets can be exposed as environment variables AND mounted as volumes, not only as environment variables.

Practice this question →

100

MCQeasy

A cluster administrator wants to ensure that a specific Pod always runs on a node with an SSD. The node has the label disktype=ssd. Which Kubernetes feature should the administrator use?

A.Pod affinity

B.Taints and tolerations

C.Resource requests and limits

D.nodeSelector

AnswerD

nodeSelector is a simple field in the Pod spec that specifies a map of key-value pairs. The Pod will only be scheduled on nodes that have all the specified labels. Here, setting nodeSelector: disktype: ssd ensures the Pod lands on an SSD node.

Why this answer

nodeSelector is the simplest way to constrain a Pod to nodes with specific labels. By specifying a label like disktype=ssd, the scheduler only considers nodes that have that label. This directly satisfies the requirement of running on an SSD node.

Exam trap

The trap here is confusing node selection mechanisms, such as using taints and tolerations or affinity when a simple nodeSelector is sufficient.

Practice this question →

101

MCQhard

A cluster administrator needs to ensure that a Deployment named 'frontend' in namespace 'web' is updated with a new image version using a rolling update strategy. The current deployment has 4 replicas. The administrator runs: kubectl set image deployment/frontend frontend=nginx:1.21 -n web. Which of the following describes the expected behavior?

A.The Deployment will create a new ReplicaSet and gradually replace old pods with new ones

B.All existing pods will be deleted immediately and new pods will be created with the new image

C.The command will fail because you cannot update a Deployment using kubectl set image

D.The Deployment's image will be updated, but only the container named 'app' will be affected

AnswerA

Changing the container image updates the pod template, so the Deployment controller creates a new ReplicaSet and scales it up while scaling the old one down, honouring the rolling update strategy and its maxSurge/maxUnavailable settings across the 4 replicas.

Why this answer

`kubectl set image deployment/frontend frontend=nginx:1.21 -n web` updates the container image in the Deployment's pod template, triggering a rolling update. The Deployment controller creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime and maintaining the desired replica count of 4.

Exam trap

The trap here is that candidates may confuse the container name in the command (which must match the container name in the Deployment spec) with a generic name like 'app', leading them to incorrectly assume only a container named 'app' is affected.

How to eliminate wrong answers

Option B is wrong because it describes a 'Recreate' strategy, not the default 'RollingUpdate' strategy; a rolling update does not delete all pods immediately. Option C is wrong because `kubectl set image` is a valid command for updating container images in Deployments, StatefulSets, and other workloads. Option D is wrong because the command explicitly targets the container named 'frontend' (as specified in the command), not a container named 'app'; only the named container's image is updated.

Practice this question →

102

MCQhard

A pod is stuck in the Pending state. The administrator runs 'kubectl describe pod' and sees the event '0/3 nodes are available: 3 Insufficient cpu.' What is the most likely cause?

A.The nodes are cordoned and cannot accept new pods.

B.The pod's CPU limit is set too low, causing it to be rejected.

C.The pod's CPU request is higher than the available CPU on any node.

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

AnswerC

The scheduler reports 'Insufficient cpu' when no node has enough allocatable CPU to satisfy the pod's CPU request. This means the sum of CPU requests of existing pods plus the new pod's request exceeds the node's capacity. The pod remains Pending until resources are freed or the request is lowered. This is the direct cause of the event.

Why this answer

The event 'Insufficient cpu' indicates that the scheduler cannot find a node with enough allocatable CPU to meet the pod's CPU request. This is a resource constraint issue, not related to limits, cordoning, or node selectors. The pod will remain Pending until sufficient CPU is available or the request is reduced.

Exam trap

The trap here is confusing CPU limits with requests; only requests affect scheduling, while limits affect runtime throttling.

Practice this question →

103

MCQmedium

What is the role of etcd in a Kubernetes cluster?

A.It manages network policies

B.It stores the cluster state and configuration

C.It schedules pods onto nodes

D.It provides DNS resolution for services

AnswerB

etcd is the distributed key-value store holding all cluster state and configuration, including object specs, node registrations and Secrets. The API server reads and writes every object through it, so it is the single source of truth for the cluster's desired and observed state.

Why this answer

etcd is a distributed, consistent key-value store that serves as Kubernetes' primary data store. It holds the entire cluster state, including all object definitions (Pods, Services, Deployments, etc.), configuration data, and secrets. The kube-apiserver is the only component that interacts directly with etcd, ensuring that all state changes go through a consistent, transactional backend.

Without etcd, the cluster would have no persistent record of its desired or current state.

Exam trap

A common misconception is that etcd is a general-purpose database or that it directly participates in scheduling or networking decisions, when in fact it is a highly specialized, consistent key-value store that only the API server communicates with, and all other components read/write cluster state through the API server.

How to eliminate wrong answers

Option A is wrong because network policies are managed by a Network Policy controller (e.g., Calico, Cilium) or the kube-controller-manager, not by etcd; etcd only stores the policy objects as data. Option C is wrong because pod scheduling onto nodes is performed by the kube-scheduler, which reads node and pod state from etcd via the API server but does not itself store or manage that state. Option D is wrong because DNS resolution for services is provided by CoreDNS (or kube-dns in older clusters), which runs as a set of Pods and uses the Kubernetes API to watch Services and Endpoints; etcd merely stores the DNS configuration objects.

Practice this question →

104

Multi-Selecthard

Which TWO statements are true about Kubernetes namespaces? (Select 2)

Select 2 answers

A.All Kubernetes resources are namespaced

B.Namespaces provide network isolation by default

C.Resource quotas can be applied to a namespace to limit resource usage

D.Namespaces can be used to separate environments like dev and prod

E.Deleting a namespace automatically deletes all resources in it, including cluster-scoped resources

AnswersC, D

ResourceQuota objects are applied per namespace, capping aggregate CPU, memory, object counts and storage consumed by workloads within that namespace. This enforces multi-tenant limits, confirming the statement that quotas can restrict resource usage at namespace scope.

Why this answer

Option C is correct because ResourceQuota objects are applied at the namespace level to cap aggregate resource consumption (e.g., requests.cpu, limits.memory, pods) for all workloads within that namespace. Option D is correct because namespaces are the standard Kubernetes mechanism for logical multi-tenancy, allowing teams to isolate dev, staging, and prod workloads with separate RBAC, quotas, and naming scopes. Option A is wrong because several resources are cluster-scoped rather than namespaced, such as Node, PersistentVolume, ClusterRole, and Namespace itself.

Option B is wrong because namespaces do not enforce network isolation by default; that requires NetworkPolicy objects (and a CNI plugin that supports them). Option E is wrong because deleting a namespace cascades to its namespaced resources only, not cluster-scoped resources, which persist independently.

Exam trap

A common misconception is that namespaces inherently provide network isolation, but in reality, network policies are required to enforce traffic rules between namespaces.

Practice this question →

105

MCQmedium

A developer wants to expose a set of pods running a web application internally within the cluster using a stable IP address. Which Kubernetes resource should they create?

A.Ingress

B.ConfigMap

C.Deployment

D.Service

AnswerD

A Service provides a stable virtual IP and DNS name that load-balances across a set of pods selected by labels, decoupling clients from individual pod IPs. Creating a Service satisfies the stem's requirement for exposing pods internally with a stable IP address.

Why this answer

A Service of type ClusterIP provides a stable virtual IP address and DNS name that load-balances traffic to a set of pods, making it the correct resource for internal cluster exposure. Unlike other resources, a Service abstracts the pod IPs and ensures connectivity even if pods are rescheduled or scaled.

Exam trap

The trap here is that candidates often confuse a Deployment's ability to manage pods with network exposure, forgetting that a Deployment alone does not provide a stable IP or load-balanced endpoint — a Service is always required for that purpose.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to services, typically routing traffic from outside the cluster, not providing a stable internal IP. Option B is wrong because a ConfigMap is used to store non-confidential configuration data in key-value pairs and does not expose pods or provide network connectivity. Option C is wrong because a Deployment manages the desired state of replica sets and pods (e.g., rolling updates), but it does not create a stable network endpoint; a separate Service is required for that.

Practice this question →

106

MCQhard

A developer creates a Pod with a container that writes logs to a file in an emptyDir volume. The Pod is then deleted, and a new Pod is created with the same emptyDir volume definition. What happens to the data in the emptyDir volume?

A.The data is preserved because emptyDir volumes persist across Pod deletions.

B.The data is lost because emptyDir volumes are deleted when the Pod is deleted.

C.The data is preserved if the emptyDir volume is mounted with a persistentVolumeClaim.

D.The data is preserved if the new Pod is scheduled to the same node.

AnswerB

emptyDir volumes are created when a Pod is assigned to a node and exist as long as that Pod is running on that node. When the Pod is deleted, the emptyDir volume is deleted, and its data is permanently lost. A new Pod with a new emptyDir volume starts with an empty directory. This is the correct behavior for emptyDir volumes.

Why this answer

emptyDir volumes are ephemeral and are deleted when the Pod is deleted. They are designed for temporary storage that is shared among containers in a Pod or used as a scratch space. When the Pod is removed, the data is lost, and a new Pod will have a fresh emptyDir volume.

This behavior is consistent regardless of whether the new Pod is scheduled to the same node or not.

Exam trap

The trap here is assuming that emptyDir data persists if the Pod is rescheduled to the same node, confusing it with hostPath or persistent volumes.

Practice this question →

107

MCQhard

You create a Deployment with 'replicas: 3' and update the pod template without changing the selector. After the update, you notice that only the new Pods are running, but old Pods have been terminated. What is the default update strategy?

A.OnDelete

B.BlueGreen

C.RollingUpdate

D.Recreate

AnswerC

RollingUpdate is the Deployment default, incrementally replacing old Pods with new ones via a new ReplicaSet while honouring maxUnavailable and maxSurge. This matches the observed behaviour: new Pods running and old Pods terminated, without the full downtime of Recreate.

Why this answer

The default update strategy for a Deployment in Kubernetes is RollingUpdate. When you update the pod template (e.g., changing the container image), the Deployment controller creates new ReplicaSets with the updated template and gradually scales down the old ReplicaSet while scaling up the new one, ensuring zero downtime. Since only new Pods are running and old Pods have been terminated, this confirms the default behavior of a rolling update, which replaces Pods incrementally without manual intervention.

Exam trap

A common trap is assuming the default update strategy is Recreate because it seems simpler, but the actual default is RollingUpdate, which performs gradual, zero-downtime updates.

How to eliminate wrong answers

Option A is wrong because OnDelete is a DaemonSet update strategy, not a Deployment strategy; it requires manual deletion of Pods to trigger updates. Option B is wrong because BlueGreen is not a native Kubernetes Deployment strategy; it is a deployment pattern implemented manually or via tools like Istio, not a default or built-in strategy. Option D is wrong because Recreate is a Deployment strategy that terminates all old Pods before creating new ones, but it is not the default; the default is RollingUpdate, and Recreate would cause downtime, which is not described in the scenario.

Practice this question →

108

MCQmedium

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

A.Secret

B.Annotation

C.Volume

D.ConfigMap

AnswerD

ConfigMap stores non-sensitive configuration as key-value pairs, decoupling settings from pod images. It satisfies the stem's constraint of non-sensitive data, unlike Secret, which handles sensitive values such as credentials. Pods consume ConfigMaps via environment variables, command-line arguments, or mounted volumes, enabling configuration changes without rebuilding images.

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 as plain text with no encoding or encryption, and are designed for configuration that does not require confidentiality.

Exam trap

The CNCF exam often tests the distinction between ConfigMap and Secret by presenting a scenario with 'configuration data' and expecting candidates to recognize that Secret is only for sensitive data, while ConfigMap is the correct choice for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed for sensitive data (e.g., passwords, tokens, SSH keys) and stores values as base64-encoded strings, with optional encryption at rest, not for non-sensitive configuration. Option B is wrong because Annotations are metadata key-value pairs attached to objects for non-identifying information (e.g., build info, contact details) and cannot be directly consumed by pods as configuration data. Option C is wrong because Volume is an abstraction for storage (e.g., emptyDir, hostPath, PVC) that can mount data into pods, but it is not a Kubernetes object for storing configuration data itself; ConfigMaps or Secrets are mounted via Volumes.

Practice this question →

109

MCQhard

A Deployment is configured with 'strategy.type: RollingUpdate' and 'strategy.rollingUpdate.maxUnavailable: 0'. What is the effect during a rolling update?

A.The update will fail because maxUnavailable must be at least 1

B.The update will not proceed until at least one new pod is ready

C.The update will proceed without any downtime

D.No pod will be terminated until a new pod is ready

AnswerD

Setting maxUnavailable to 0 forces the Deployment controller to keep every existing pod running until each replacement pod passes its readiness probe. Surge capacity is used instead, so availability never dips during the rollout — satisfying the zero-downtime constraint implied by the stem.

Why this answer

Setting `maxUnavailable: 0` means the Deployment controller will not terminate any existing pod until a new pod is fully ready. This ensures zero disruption to the application during the rolling update, as the controller waits for the new pod to pass its readiness probe before scaling down the old ReplicaSet.

Exam trap

The trap here is that candidates often assume `maxUnavailable: 0` is invalid or causes the update to fail, when in fact it is a valid configuration that enforces a 'zero-downtime' update by preventing pod termination until new pods are ready.

How to eliminate wrong answers

Option A is wrong because `maxUnavailable` can be set to 0; it is a valid integer value that instructs the controller to allow no unavailable pods during the update. Option B is wrong because the update will proceed—the controller will create new pods—but it will not terminate old pods until the new ones are ready, not that the update halts entirely. Option C is wrong because while the update aims to avoid downtime, it does not guarantee zero downtime in all cases; for example, if the new pod fails its readiness probe, the update can stall, and there is still a brief period where old pods are running and new pods are starting, but no termination occurs until readiness is confirmed.

Practice this question →

110

MCQmedium

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

A.Deployment

B.Node

C.Container

D.Pod

AnswerD

A pod wraps one or more containers sharing a network namespace and storage volumes, making it the atomic scheduling unit the scheduler places onto nodes. Containers alone cannot be scheduled; controllers such as Deployments manage pods, not individual containers.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster and encapsulates one or more containers, shared storage, and a unique network IP. While containers are the runtime units, Kubernetes does not manage containers directly; it manages Pods, which are the atomic deployable and schedulable entities.

Exam trap

A common mistake is to assume a Container is the smallest deployable unit because containers are the runtime entities, but Kubernetes manages Pods, which are the smallest deployable and schedulable objects.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods; it is not the smallest deployable unit. Option B is wrong because a Node is a worker machine (physical or virtual) in the cluster, not a deployable unit — Pods are scheduled onto Nodes. Option C is wrong because a Container is the runtime process, but Kubernetes cannot create or manage a container directly without wrapping it in a Pod; the Pod is the smallest unit that Kubernetes can schedule and manage.

Practice this question →

111

MCQeasy

What is the primary purpose of a Namespace in Kubernetes?

A.To set resource quotas for the entire cluster

B.To define network policies for pods

C.To manage node affinity rules

D.To isolate resources and provide a scope for names

AnswerD

Namespaces partition a single cluster into virtual scopes, letting teams isolate resources and reuse identical names across namespaces. This provides the name scoping and resource separation the question asks for, without creating separate physical clusters.

Why this answer

Namespaces in Kubernetes provide a mechanism for isolating groups of resources within a single cluster. They create separate scopes for resource names, meaning that resource names (like Pods or Services) only need to be unique within a Namespace, not across the entire cluster. This allows multiple teams or projects to share a cluster without naming conflicts, and it also enables cluster administrators to apply policies (like ResourceQuotas) and network policies at the Namespace level.

Exam trap

The trap here is that candidates confuse Namespaces with other cluster-level constructs like ResourceQuotas or NetworkPolicies, assuming Namespaces directly enforce limits or rules, when in fact Namespaces only provide the scope for names and isolation, while other objects (like ResourceQuotas, NetworkPolicies, and RBAC) are applied to that scope.

How to eliminate wrong answers

Option A is wrong because setting resource quotas for the entire cluster is not the primary purpose of a Namespace; ResourceQuotas are a separate Kubernetes object that can be applied to a Namespace to limit aggregate resource consumption, but Namespaces themselves do not enforce quotas. Option B is wrong because defining network policies for pods is the job of NetworkPolicy objects, which can be scoped to a Namespace, but the Namespace itself does not define network policies. Option C is wrong because managing node affinity rules is a function of PodSpec fields like nodeSelector and nodeAffinity, which are independent of Namespaces; Namespaces do not control which nodes Pods are scheduled on.

Practice this question →

112

Multi-Selectmedium

A developer is troubleshooting a Pod that is stuck in the Pending state. They want to gather information to determine why the Pod has not been scheduled. Which two commands or outputs are most directly useful for this diagnosis? (Choose two.)

Select 2 answers

A.Run `kubectl top pod <pod-name>` to check the Pod's CPU and memory usage against requests.

B.Run `kubectl logs <pod-name>` to read the application logs for scheduling errors.

C.Run `kubectl describe pod <pod-name>` and inspect the Events section at the bottom.

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

E.Run `kubectl exec -it <pod-name> -- /bin/sh` to inspect the container's environment.

AnswersC, D

The Events section from `kubectl describe pod` shows scheduler messages such as `FailedScheduling` with reasons like insufficient CPU, node affinity mismatch, or untolerated taints. It also shows image pull and volume errors after scheduling. For a Pending Pod, these events are the fastest way to see why the scheduler rejected candidate nodes, making this a primary diagnostic step.

Why this answer

For a Pending Pod, the scheduler's reasoning is exposed through events. `kubectl describe pod` surfaces FailedScheduling events with specific reasons, and `kubectl get events` with a field selector provides a filtered event timeline. Logs, exec, and top all require a running container, which does not exist before scheduling, so they cannot diagnose a Pending state. The two event-based approaches are the correct diagnostic tools.

Exam trap

The trap here is reaching for logs or exec on a Pending Pod, when those commands require a running container and the real information is in scheduler events.

Practice this question →

113

MCQeasy

Which component runs on each worker node and ensures that containers are running as specified in the Pod spec?

A.kubelet

B.kube-proxy

C.kube-scheduler

D.kube-controller-manager

AnswerA

The kubelet is the node agent that watches the API server for PodSpecs bound to its node and drives the container runtime to start, stop and restart containers so actual state matches the spec. It satisfies the per-worker-node constraint, unlike control-plane components such as the scheduler or controller manager.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives PodSpec definitions (via the API server or a file) and ensures that the containers described in those PodSpecs 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, and it reports the node and pod status back to the control plane.

Exam trap

A common trap is confusing the kubelet (a node-level agent that runs on each worker and directly manages containers) with control-plane components like the kube-scheduler or kube-controller-manager, which run on the master node and handle cluster-level decisions.

How to eliminate wrong answers

Option B (kube-proxy) is wrong because it is a network proxy that runs on each node, handling service-to-pod routing and load balancing (e.g., via iptables or IPVS), not container lifecycle management. Option C (kube-scheduler) is wrong because it runs on the control plane and is responsible for assigning pods to nodes based on resource availability and constraints, not for running containers on a node. Option D (kube-controller-manager) is wrong because it runs on the control plane and manages controllers (e.g., ReplicaSet, Node Controller) that maintain desired cluster state, but it does not directly interact with containers on worker nodes.

Practice this question →

114

MCQeasy

A Pod is in the 'Pending' state. What is the most likely cause?

A.The Pod is still being scheduled because no Node has enough resources

B.The container image is missing

C.The Service referencing the Pod does not exist

D.The application inside the container has crashed

AnswerA

A Pod remains in 'Pending' when the scheduler cannot find a Node that satisfies its resource requests, such as CPU or memory limits. The kube-scheduler evaluates each Node’s allocatable capacity against the Pod’s specified requests; if no Node has sufficient unallocated resources, the Pod is unschedulable and stays Pending. This directly satisfies the constraint of insufficient Node capacity.

Why this answer

A Pod in 'Pending' state means the Pod has been accepted by the API server but is not yet running. The most common reason is that the scheduler cannot find a Node with sufficient CPU, memory, or other resources to place the Pod. This triggers the scheduler to continuously attempt to bind the Pod to a suitable Node, leaving it in Pending until resources become available or the Pod is deleted.

Exam trap

A common pitfall is confusing Pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) with error states like CrashLoopBackOff or ImagePullBackOff. Candidates often wrongly attribute 'Pending' to application-level failures instead of scheduling issues.

How to eliminate wrong answers

Option B is wrong because a missing container image causes the Pod to enter 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending'. Option C is wrong because a missing Service does not affect Pod scheduling; Services are decoupled from Pod lifecycle and only affect network routing after the Pod is running. Option D is wrong because an application crash inside the container results in 'CrashLoopBackOff' or 'Error' state, not 'Pending'.

Practice this question →

115

MCQhard

A Service of type ClusterIP is not resolving DNS names for pods. The pods are running and can communicate with each other via IP addresses. Which component should be checked first?

A.The kubelet on the node where the pod is running

B.The Service's endpoint slices

C.kube-proxy on the nodes

D.CoreDNS pods in the kube-system namespace

AnswerD

CoreDNS provides cluster DNS resolution for Services, so its pods in kube-system are the first thing to verify. Since pod-to-pod IP communication already works, the CNI and kube-proxy are functioning; the failure is isolated to name resolution, which CoreDNS handles directly.

Why this answer

DNS name resolution for Services in Kubernetes is handled by CoreDNS, which runs as pods in the kube-system namespace. When a ClusterIP Service fails to resolve DNS names but pods can communicate via IP addresses, the issue is almost certainly with the DNS resolver itself, not with network connectivity or Service endpoints. CoreDNS must be checked first to ensure it is running, has correct configuration, and can query the Kubernetes API for Service records.

Exam trap

A common misconception is that DNS failures are caused by kube-proxy or network proxy issues, when in fact DNS resolution is a separate layer handled by CoreDNS, and candidates should first verify the DNS pods themselves.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for managing pod lifecycle and container runtime, not for DNS resolution or Service name resolution. Option B is wrong because endpoint slices define the actual pod IPs backing a Service, but DNS resolution depends on CoreDNS querying the API server, not on the endpoints themselves; if DNS fails, endpoint slices are irrelevant. Option C is wrong because kube-proxy handles network proxy rules for Service traffic (e.g., iptables or IPVS), but DNS name resolution is a separate function performed by CoreDNS; kube-proxy does not resolve DNS names.

Practice this question →

116

MCQmedium

You are writing a Pod manifest and need to ensure the container always pulls the newest image from the registry, even if an image with the same tag already exists on the node. Which imagePullPolicy should you set?

A.Latest

B.Never

C.Always

D.IfNotPresent

AnswerC

Setting imagePullPolicy to Always forces the kubelet to contact the container registry and pull the image every time a container is started, regardless of whether an image with that tag is already cached on the node. This guarantees you get the most recent image content behind a mutable tag such as latest, which is exactly the requirement in this scenario.

Why this answer

The imagePullPolicy field controls whether the kubelet consults the node's local image cache or the registry. Always is the only policy that unconditionally pulls on every container start, which is what guarantees fresh content when a mutable tag is reused. IfNotPresent and Never both allow a stale cached image to run, and Latest is not a recognized policy value.

Exam trap

The trap here is confusing the image tag latest with the imagePullPolicy value Always, since a tag named latest does not by itself force a registry pull.

Practice this question →

117

MCQmedium

You are reviewing the manifest for a Pod that must only run on nodes with the label `disktype=ssd`. The manifest includes the following snippet: ```yaml nodeSelector: disktype: ssd ``` After applying the manifest, the Pod remains in Pending state indefinitely. `kubectl get nodes --show-labels` shows no node has the `disktype=ssd` label. Which action will allow the Pod to be scheduled without modifying the Pod's nodeSelector?

A.Add an annotation `disktype=ssd` to a node with `kubectl annotate nodes <node-name> disktype=ssd`.

B.Edit the Pod's nodeSelector to an empty map so it matches any node, then reapply the manifest.

C.Create a taint on a node with `kubectl taint nodes <node-name> disktype=ssd:NoSchedule` so the scheduler treats it as matching.

D.Add the label `disktype=ssd` to at least one node using `kubectl label nodes <node-name> disktype=ssd`.

AnswerD

The scheduler filters nodes using the Pod's nodeSelector, and no node currently carries the `disktype=ssd` label, so the Pod stays Pending. Labeling a suitable node with that exact key and value makes it eligible, and the scheduler will bind the Pod there without editing the Pod spec. This is the intended way to satisfy a nodeSelector requirement.

Why this answer

A Pod with nodeSelector only lands on nodes whose labels match every specified key-value pair. Because no node currently has `disktype=ssd`, the scheduler cannot find a feasible node and the Pod stays Pending. Labeling an appropriate node with that exact pair makes it feasible, allowing scheduling without altering the Pod manifest.

The other actions either use the wrong metadata type or change the Pod spec.

Exam trap

The trap here is confusing taints, annotations, or empty selectors with labels, when nodeSelector strictly matches node labels.

Practice this question →

118

Multi-Selectmedium

Which TWO statements correctly describe the purpose of etcd in a Kubernetes cluster?

Select 2 answers

A.It stores the cluster state, including all Kubernetes objects.

B.It manages network rules for Pod-to-Pod communication.

C.It schedules Pods onto nodes based on resource availability.

D.It exposes the Kubernetes API for external access.

E.It is a distributed key-value store that provides high availability and consistency.

AnswersA, E

etcd is the cluster's sole source of truth, persisting the entire state of every Kubernetes object — Pods, Services, Deployments, ConfigMaps and more. The API server reads and writes all object data exclusively through etcd, making this storage role fundamental.

Why this answer

Option A is correct because etcd is the backing store for all Kubernetes cluster data: every API object (Pods, Services, ConfigMaps, Secrets, etc.) is serialized and persisted in etcd, making it the single source of truth for cluster state. Option E is correct because etcd is fundamentally a distributed key-value store built on the Raft consensus algorithm, which replicates data across members to deliver high availability and strong consistency (linearizable reads/writes). Option B is wrong because Pod-to-Pod network rules are implemented by the CNI plugin and kube-proxy (iptables/IPVS or eBPF), not etcd.

Option C is wrong because Pod scheduling is the job of kube-scheduler, which watches the API server and binds Pods to nodes. Option D is wrong because the Kubernetes API is exposed by kube-apiserver; etcd only serves as its storage backend and is not itself an API endpoint for clients.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the components that use that state (scheduler, controller manager, API server), so the trap here is confusing etcd's role as a passive data store with the active management functions of other control plane components.

Practice this question →

119

Drag & Dropmedium

Drag and drop the steps to create a Kubernetes Namespace and deploy an application into it into the correct order.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

First create namespace, then deploy resources specifying that namespace, and verify.

Practice this question →

120

MCQmedium

A pod is stuck in Pending state. You run 'kubectl describe pod' and see the event '0/3 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 2 node(s) had insufficient memory.'. What is the most likely cause?

A.The pod does not have tolerations for the node's taints and memory is insufficient on other nodes

B.The kube-scheduler is not running

C.The container runtime is not installed on any node

D.The pod's resource requests exceed available resources on all nodes

AnswerA

The scheduler event shows two distinct blockers: one node rejected the pod due to an untolerated taint, and the other two lacked sufficient memory. No node therefore satisfies both taint tolerations and resource requests, leaving the pod unscheduled.

Why this answer

The event '0/3 nodes are available: 1 node(s) had taint(s) that the pod didn't tolerate, 2 node(s) had insufficient memory' directly indicates that the pod failed scheduling because it lacks required tolerations for a tainted node, and the remaining nodes do not have enough memory to satisfy the pod's resource requests. This matches option A, as the pod's tolerations are missing for the tainted node, and memory is insufficient on the other two nodes.

Exam trap

The CNCF exam often tests the distinction between scheduling failures (like taints and resource insufficiency) and runtime failures (like missing container runtime or scheduler), tricking candidates into picking a generic cause like 'kube-scheduler not running' when the detailed event clearly shows the scheduler is working.

How to eliminate wrong answers

Option B is wrong because if the kube-scheduler were not running, the pod would remain in Pending state but no scheduling events would appear at all; the specific event about taints and insufficient memory proves the scheduler is actively evaluating nodes. Option C is wrong because a missing container runtime would cause the pod to fail at the kubelet level with a different event (e.g., 'failed to create container'), not a scheduling event about taints and memory. Option D is wrong because while insufficient memory is part of the issue, the event explicitly mentions a taint that the pod didn't tolerate, which is a separate scheduling constraint not covered by resource requests alone.

Practice this question →

121

MCQmedium

A platform engineer applies a Pod manifest that includes the field `spec.nodeName: k8s-worker-07`. The scheduler is running normally. What is the most accurate description of what happens to this Pod?

A.The API server rejects the manifest because nodeName cannot be set by users; it is only written by kube-scheduler.

B.The Pod is placed on k8s-worker-07 without kube-scheduler involvement, and the kubelet there attempts to run it regardless of taints or resource fit.

C.The kube-scheduler evaluates node affinity and taints before binding the Pod to k8s-worker-07.

D.The Pod is bound directly to k8s-worker-07 by the kubelet on that node, skipping the scheduler's binding step.

AnswerB

Pre-setting spec.nodeName is a manual scheduling shortcut: kube-scheduler never sees the Pod as unscheduled, so no filtering predicates, taints, or resource-fit checks are applied. The kubelet on the named node observes the Pod and tries to start it, but if the node is tainted with NoExecute or lacks capacity, the kubelet may reject or evict it. This is why nodeName is discouraged for production scheduling.

Why this answer

Populating spec.nodeName directly is the classic manual-scheduling pattern: kube-scheduler only considers Pods with an empty nodeName, so a Pod that already names a node skips the entire scheduling framework, including taint and affinity checks. The kubelet on the named node then takes over, and any resource or taint mismatch surfaces as a kubelet-level failure rather than a Pending Pod event.

Exam trap

The trap here is assuming kube-scheduler always validates placement, when a pre-set nodeName makes the Pod invisible to the scheduler entirely.

Practice this question →

122

MCQmedium

A cluster administrator needs to run a node-level log collector that must read files from /var/log on every node in the cluster, including nodes added later. The collector does not need to run on control plane nodes. Which Kubernetes resource should be used?

A.DaemonSet

B.Job with parallelism set to the node count

C.StatefulSet with podAntiAffinity

D.Deployment with replicas equal to the number of nodes

AnswerA

A DaemonSet ensures that a copy of a Pod runs on every eligible node, including nodes added after the DaemonSet is created. The collector can mount hostPath /var/log and apply a nodeSelector or affinity to exclude control plane nodes, satisfying the requirement without manual scheduling.

Why this answer

A DaemonSet is the correct resource because it schedules exactly one Pod on each node that matches its node selector or affinity rules, and it automatically adds Pods to new nodes as they join the cluster. This makes it ideal for node-level agents such as log collectors, monitoring daemons, and network plugins that must run everywhere.

Exam trap

The trap here is assuming a Deployment with replica count matching node count provides per-node coverage, when only a DaemonSet guarantees one Pod per eligible node and handles new nodes automatically.

Practice this question →

123

MCQmedium

Which component runs on every Kubernetes node and ensures that the containers in a pod are running?

A.kube-proxy

B.kube-scheduler

C.kubelet

D.container runtime

AnswerC

The kubelet is the node agent that watches the API server for pod assignments and directly manages container lifecycles via the container runtime, restarting failed containers to maintain the desired state. This satisfies the stem's requirement for a per-node component guaranteeing that a pod's containers keep running.

Why this answer

The kubelet is the primary node agent that runs on every Kubernetes node. It receives PodSpec definitions from the API server and ensures that the containers described in those PodSpecs are running and healthy. It continuously monitors container status and takes corrective actions, such as restarting containers that have failed, making it the correct answer.

Exam trap

The trap here is that candidates often confuse the container runtime (which physically runs containers) with the kubelet (which orchestrates and monitors them), leading them to select 'container runtime' instead of 'kubelet'.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic to pods; it does not manage container lifecycle. Option B is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints; it does not run on worker nodes and does not ensure containers are running. Option D is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is the kubelet that interacts with the container runtime via the Container Runtime Interface (CRI) to enforce the desired state; the runtime alone does not perform health monitoring or reconciliation.

Practice this question →

124

MCQmedium

What is the purpose of a liveness probe in a Kubernetes pod?

A.To check if the pod is scheduled on a node

B.To check if the container has started successfully

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

D.To check if the application is still running; if not, restart the container

AnswerD

A liveness probe periodically tests the container; on failure kubelet restarts it according to the pod's restartPolicy. This recovers hung or deadlocked processes that are still running but unresponsive, unlike a readiness probe, which only removes the pod from Service endpoints.

Why this answer

A liveness probe in Kubernetes is used to determine if a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it based on the pod's restart policy. This ensures that applications that have entered a deadlock or hung state are automatically recovered without manual intervention.

Exam trap

The trap here is that candidates often confuse liveness probes with readiness probes, mistakenly thinking liveness determines traffic readiness, but liveness is solely about container health and automatic restarts, not service connectivity.

How to eliminate wrong answers

Option A is wrong because checking if a pod is scheduled on a node is the role of the Kubernetes scheduler and is reflected in the pod's status, not a liveness probe. Option B is wrong because checking if a container has started successfully is the purpose of a startup probe, which runs before other probes to allow slow-starting applications time to initialize. Option C is wrong because checking if the application is ready to serve traffic is the purpose of a readiness probe, which controls whether the pod receives traffic from Services, not whether it should be restarted.

Practice this question →

125

MCQmedium

A team wants to run a batch job that must complete successfully exactly once and then stop. The job processes a queue and should not be restarted after successful completion. Which Kubernetes resource is most appropriate for this requirement?

A.DaemonSet

B.Job

C.StatefulSet

D.Deployment

AnswerB

A Job creates one or more Pods and ensures that a specified number complete successfully. With a default completions and parallelism of 1, it runs a single Pod to completion and does not restart it after success. This matches the requirement for a one-time batch task that terminates when finished, unlike long-running workload controllers.

Why this answer

Job is the controller designed for run-to-completion workloads. It tracks successful Pod completions and stops creating new Pods once the required count is reached. Deployments, DaemonSets, and StatefulSets all maintain long-running Pods and would not naturally terminate after a single successful execution, making them inappropriate for this batch processing requirement.

Exam trap

The trap here is assuming any workload controller can run a one-off task, when only Job and CronJob are built around completion rather than continuous availability.

Practice this question →

126

Multi-Selectmedium

A team is designing a Kubernetes architecture for a new application. They need to understand which components are part of the control plane and which run on worker nodes. Which TWO of the following components run on every worker node in a standard Kubernetes cluster? (Choose two.)

Select 2 answers

A.kube-proxy

B.kube-controller-manager

C.kube-scheduler

D.kubelet

E.etcd

AnswersA, D

kube-proxy runs on every worker node and maintains network rules that allow communication to Pods from inside or outside the cluster. It implements Service abstraction by programming iptables or IPVS rules, enabling load balancing across Pod endpoints.

Why this answer

kubelet and kube-proxy are the two components that run on every worker node. kubelet manages Pods on the node, and kube-proxy handles Service networking. The scheduler, etcd, and controller manager are control plane components.

Exam trap

The trap here is mixing control plane components with node components, especially assuming kube-scheduler or kube-controller-manager run on workers because they manage workloads.

Practice this question →

127

Multi-Selecthard

An administrator wants to perform a rolling update of a Deployment. Which TWO actions will achieve this?

Select 2 answers

A.Run 'kubectl set image deployment/myapp myapp=myapp:v2'

B.Run 'kubectl scale deployment myapp --replicas=0' then 'kubectl scale deployment myapp --replicas=5'

C.Run 'kubectl delete deployment' and then 'kubectl create deployment' with the new image

D.Run 'kubectl rollout undo deployment/myapp'

E.Edit the Deployment YAML to change the image version and run 'kubectl apply -f deployment.yaml'

AnswersA, E

kubectl set image patches the Deployment's pod template with the new image tag, which triggers the controller to create a new ReplicaSet and roll pods over gradually. This achieves the rolling update without editing YAML manually.

Why this answer

Option A is correct because 'kubectl set image deployment/myapp myapp=myapp:v2' updates the container image in the Deployment's Pod template, which triggers the Deployment controller to perform a rolling update by creating a new ReplicaSet and gradually replacing old Pods while maintaining availability. Option E is also correct because editing the Deployment YAML to change the image version and running 'kubectl apply -f deployment.yaml' updates the Pod template spec, causing the same rolling update behavior managed by the Deployment controller. Option B is incorrect because scaling to zero replicas causes downtime and does not perform a rolling update; scaling back up simply creates new Pods without the controlled surge/unavailable semantics of a rollout.

Option C is incorrect because deleting and recreating the Deployment destroys the existing rollout history and causes an outage rather than a rolling update. Option D is incorrect because 'kubectl rollout undo' reverts to a previous revision, which is a rollback, not a rolling update to a new image version.

Exam trap

The trap here is that candidates may confuse scaling (Option B) or deleting/recreating (Option C) with a rolling update, or think that 'rollout undo' (Option D) is a way to update to a new image, when it is actually for reverting to a previous version.

Practice this question →

128

Multi-Selectmedium

Which THREE of the following are valid Kubernetes resource types?

Select 3 answers

A.DockerImage

B.Deployment

C.ConfigMap

D.VirtualMachine

E.Service

AnswersB, C, E

Deployment is a built-in apps/v1 resource that manages ReplicaSets to provide declarative rolling updates and rollbacks for stateless Pods. It is a genuine Kubernetes API resource type, unlike abstractions such as PodSpec fields or labels.

Why this answer

Deployment (B) is a valid Kubernetes resource type, an apps/v1 workload controller that manages ReplicaSets and provides declarative rolling updates and rollbacks for stateless Pods. ConfigMap (C) is a valid core/v1 resource used to store non-confidential configuration data as key-value pairs that Pods can consume via environment variables, command-line arguments, or mounted volumes. Service (E) is a valid core/v1 resource that provides a stable virtual IP and DNS name to load-balance traffic to a set of Pods selected by labels.

DockerImage (A) is not a Kubernetes API resource; container images are referenced in a Pod spec's image field but are not themselves objects managed by the API server. VirtualMachine (D) is not a built-in Kubernetes resource type; VM lifecycle is handled by separate projects such as KubeVirt, which introduces its own CRDs like VirtualMachineInstance.

Exam trap

The KCNA exam often tests whether candidates confuse container image references (like Docker images) with actual Kubernetes API resource types, leading them to incorrectly select DockerImage as a valid resource.

Practice this question →

129

Multi-Selectmedium

Which two components are part of the Kubernetes worker node? (Select TWO)

Select 2 answers

A.kubelet

B.kube-controller-manager

C.etcd

D.kube-scheduler

E.container runtime

AnswersA, E

kubelet is the node agent that registers the node with the control plane, watches for assigned PodSpecs, and ensures containers run and report health. It is a core worker node component, distinct from control plane services like the scheduler.

Why this answer

The kubelet (A) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and ensuring containers described in PodSpecs are running and healthy. The container runtime (E) is correct because the worker node needs a CRI-compliant runtime such as containerd or CRI-O to actually pull images and run containers. The kube-controller-manager (B), etcd (C), and kube-scheduler (D) are all control plane components that typically run on master nodes, not on worker nodes, so they are not part of the worker node.

Exam trap

The CNCF exam often tests the distinction between control plane and worker node components; the trap here is that candidates confuse the kubelet (worker node agent) with the kube-controller-manager or kube-scheduler, which are control-plane-only services, or mistakenly think etcd runs on every node.

Practice this question →

130

MCQmedium

A DevOps engineer has created a ConfigMap named 'app-config' with some configuration data. They want to make that data available as environment variables in a pod. Which field in the pod spec should they use to achieve this?

A.spec.volumes

B.spec.containers[].volumeMounts

C.spec.containers[].envFrom

D.spec.containers[].env

AnswerC

envFrom bulk-imports every key-value pair from the referenced ConfigMap as environment variables, satisfying the requirement without enumerating each key individually. The alternative, env with valueFrom, exposes only one key per entry, so envFrom is the correct field.

Why this answer

The `envFrom` field in the container spec allows you to inject all key-value pairs from a ConfigMap (or Secret) as environment variables into the container. This is the most direct and efficient way to expose ConfigMap data as environment variables without needing to specify each key individually.

Exam trap

The trap here is that candidates often confuse `envFrom` with `env` or `volumeMounts`, thinking that mounting a ConfigMap as a volume or using individual `env` entries is the only way to expose its data, but `envFrom` is the specific field designed for bulk injection of ConfigMap keys as environment variables.

How to eliminate wrong answers

Option A is wrong because `spec.volumes` defines volumes at the pod level, not environment variables; it is used for mounting data as files. Option B is wrong because `spec.containers[].volumeMounts` mounts a volume into a container's filesystem, not into environment variables. Option D is wrong because `spec.containers[].env` is used to set individual environment variables explicitly, but it does not automatically pull all data from a ConfigMap; it requires manual mapping of each key using `valueFrom`.

Practice this question →

131

MCQmedium

A platform team wants to run a batch job that must complete successfully exactly once per day on a schedule. They need Kubernetes to create a Job object automatically at the specified times, and they want to keep a history of the last three successful and one failed Job for debugging. Which resource should they create?

A.A Job with a cron schedule annotation and a restartPolicy of OnFailure.

B.A DaemonSet that runs a Pod on every node and executes the batch script once per day.

C.A StatefulSet with an initContainer that sleeps until the next scheduled time.

D.A CronJob with a schedule, successfulJobsHistoryLimit: 3, and failedJobsHistoryLimit: 1.

AnswerD

A CronJob creates Job objects on a cron schedule. The fields `successfulJobsHistoryLimit` and `failedJobsHistoryLimit` control how many completed and failed Jobs are retained for inspection. Setting them to 3 and 1 matches the requirement to keep a short history while allowing the CronJob to create a new Job each day. The Job then runs the Pod to completion.

Why this answer

The requirement is a scheduled, one-off task with retention of past runs. A CronJob is the only resource that natively creates Jobs on a cron schedule and exposes history limits for successful and failed Jobs. The Job it creates handles completion and retries.

Other workload controllers either run continuously or lack scheduling and history features, so they cannot fulfill the scenario.

Exam trap

The trap here is confusing a Job, which runs a task once, with a CronJob, which creates Jobs on a schedule and manages their history.

Practice this question →

132

MCQmedium

Which Kubernetes controller ensures that a specified number of pod replicas are running at all times?

A.ReplicaSet

B.Job

C.ReplicationController

D.DaemonSet

AnswerA

A ReplicaSet's reconciliation loop continuously compares the desired replica count in its specification against observed pod counts, creating or deleting pods to match. This directly satisfies the stem's requirement for maintaining a specified number of pod replicas at all times, unlike Deployments (which manage ReplicaSets) or DaemonSets (one pod per node).

Why this answer

A ReplicaSet is the Kubernetes controller that ensures a specified number of pod replicas are running at all times. It uses a label selector to match pods and maintains the desired replica count by creating or deleting pods as needed. ReplicaSet is the successor to ReplicationController and is primarily used by Deployments to manage pod scaling and self-healing.

Exam trap

CNCF often tests the distinction between ReplicaSet and ReplicationController, trapping candidates who think ReplicationController is still the primary controller for replica management, when in fact ReplicaSet is the modern, recommended controller.

How to eliminate wrong answers

Option B is wrong because a Job controller is designed to run a specified number of pods to completion, not to maintain a continuous replica count. Option C is wrong because ReplicationController is the older, deprecated controller that also ensures a specified number of pod replicas, but it has been superseded by ReplicaSet with more flexible label selectors; however, the question asks for the current correct answer, and ReplicaSet is the standard. Option D is wrong because a DaemonSet ensures that a copy of a pod runs on every node (or a subset of nodes), not a specified number of replicas cluster-wide.

Practice this question →

133

Multi-Selectmedium

Which two of the following are valid ways to expose a Pod's container port to other resources? (Select two.)

Select 2 answers

A.Create a Service of type ClusterIP pointing to the Pod's port

B.Add a containerPort field in the Pod spec

C.Set the pod's hostNetwork to true

D.Create an Ingress that routes to the Service

E.Use kubectl port-forward

AnswersA, D

A ClusterIP Service provides a stable virtual IP and DNS name that load-balances to the pod's target port, letting other in-cluster resources reach the container. It satisfies internal exposure without requiring node-level or external access.

Why this answer

Option A is correct because a Service of type ClusterIP provides a stable virtual IP and DNS name that load-balances traffic to the Pod's target port, making the container port reachable by other resources inside the cluster. Option D is correct because an Ingress routes external HTTP/HTTPS traffic to a Service (which then forwards to the Pod's container port), thereby exposing the port to resources outside the cluster. Option B is not a valid exposure method by itself: containerPort is purely informational metadata in the Pod spec and does not publish or open the port.

Option C is incorrect because hostNetwork: true makes the Pod share the node's network namespace, but it does not expose a specific container port to other resources as a Kubernetes networking construct. Option E is incorrect because kubectl port-forward is a temporary debugging tunnel from a local machine to a Pod, not a way to expose a container port to other cluster resources.

Exam trap

A common mistake is assuming that setting a containerPort in the Pod spec alone exposes the port to other resources; it only documents the port. Similarly, hostNetwork exposes the Pod's ports on the node's network but is not a standard Kubernetes service discovery method. The correct production approach is to create a Service (ClusterIP) to expose the Pod, and optionally an Ingress for HTTP-based routing.

Practice this question →

134

MCQmedium

When creating a Deployment, you want to ensure that only a certain number of pods run at a time across all nodes. Which field in the Deployment spec controls this?

A.spec.replicas

B.spec.selector

C.spec.minReadySeconds

D.spec.template

AnswerA

`spec.replicas` declares the desired number of identical pod replicas the ReplicaSet maintains cluster-wide, so the Deployment controller continuously reconciles actual pod count towards it across all nodes. This directly satisfies the stem's constraint of limiting how many pods run concurrently, independent of node placement.

Why this answer

The `spec.replicas` field in a Deployment spec defines the desired number of identical Pod replicas that should be running at any given time. This field directly controls the count of Pods across all nodes in the cluster, ensuring that exactly that many Pods are maintained by the ReplicaSet controller. Option A is correct because it is the only field that sets the target Pod count.

Exam trap

The trap here is that candidates confuse `spec.replicas` with `spec.selector`, thinking the selector controls the number of Pods, but the selector only determines which Pods are managed, not how many.

How to eliminate wrong answers

Option B is wrong because `spec.selector` defines a label query used to identify which Pods the Deployment manages, not the number of Pods. Option C is wrong because `spec.minReadySeconds` controls the minimum time a Pod must be ready before it is considered available, not the number of Pods. Option D is wrong because `spec.template` defines the Pod template (containers, volumes, etc.) used to create new Pods, not the desired count.

Practice this question →

135

MCQmedium

A developer has created a Deployment with 3 replicas. The application should be reachable from other Pods within the same cluster. Which Kubernetes resource should be used to provide a stable network endpoint?

A.Ingress

B.Service

C.PersistentVolumeClaim

D.ConfigMap

AnswerB

A Service supplies a stable virtual IP and DNS name that load-balances across the Deployment's three Pods, satisfying the requirement for reachability from other Pods inside the cluster. Because Pod IPs are ephemeral, only a Service provides the consistent endpoint ClusterIP access demands.

Why this answer

A Service provides a stable network endpoint (ClusterIP) that load-balances traffic across the Pod replicas, abstracting away Pod IP changes due to restarts or scaling. This allows other Pods within the cluster to reach the application reliably using the Service's DNS name, without needing to track individual Pod IPs.

Exam trap

CNCF often tests the misconception that an Ingress is required for any network access, but the trap here is that Ingress is only for external (north-south) traffic, while internal Pod-to-Pod communication uses a Service.

How to eliminate wrong answers

Option A is wrong because an Ingress is an API object that manages external HTTP/HTTPS access to Services, not internal cluster communication; it requires a Service to route traffic to Pods. Option C is wrong because a PersistentVolumeClaim is used to request storage resources, not to provide a network endpoint for Pod-to-Pod communication. Option D is wrong because a ConfigMap is used to inject configuration data (e.g., environment variables, files) into Pods, not to expose a stable network address.

Practice this question →

136

MCQmedium

You need to store a sensitive database password in Kubernetes. Which resource should you use?

A.PersistentVolume

B.ConfigMap

C.ServiceAccount

D.Secret

AnswerD

Secrets store base64-encoded data separately from pod specs and images, satisfying the need to keep credentials out of container definitions. They can be mounted as volumes or injected as environment variables, and access is restricted via RBAC and encryption at rest.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the data in base64 and is designed to be consumed securely by pods, with access controlled via RBAC. Unlike ConfigMaps, Secrets are not intended for non-sensitive configuration and provide a layer of separation for confidential information.

Exam trap

The most common mistake is selecting ConfigMap instead of Secret, because both can hold key-value data, but Secret is designed for sensitive information and provides base64 encoding as a basic security measure, while ConfigMap is for non-sensitive configuration.

How to eliminate wrong answers

Option A is wrong because a PersistentVolume is a storage abstraction for persistent data (e.g., files) and is not designed to store small, sensitive configuration values like passwords. Option B is wrong because a ConfigMap stores non-sensitive configuration data in plain text (or base64 if manually encoded) and lacks the security context and RBAC controls that Secrets provide for sensitive information. Option C is wrong because a ServiceAccount is an identity for pods to authenticate to the Kubernetes API server, not a resource for storing secrets or passwords.

Practice this question →

137

MCQmedium

A pod is experiencing high memory usage. The administrator wants to enforce that the pod is terminated if it exceeds a memory limit and restarted automatically, but also wants to guarantee a minimum amount of memory for the pod. Which resource specification should be used in the container definition?

A.spec.containers[].resources.requests.memory only

B.spec.containers[].resources.limits.memory and requests.cpu

C.spec.containers[].resources.limits.memory only

D.spec.containers[].resources.requests.memory and limits.memory

AnswerD

Requests reserve guaranteed memory for scheduling, while limits set the ceiling the kubelet enforces; exceeding the limit triggers an OOM kill and the container restarts per its restartPolicy. Together they satisfy both the guarantee and termination requirements.

Why this answer

Setting both `requests.memory` and `limits.memory` guarantees a minimum memory allocation (the request) while enforcing a hard cap (the limit). If the pod exceeds the memory limit, it is terminated (OOMKilled) and, if part of a Deployment or StatefulSet, the controller automatically restarts it. This satisfies the requirement for both guaranteed minimum and enforced maximum with automatic restart.

Exam trap

CNCF often tests the misconception that setting only `limits.memory` is sufficient for both guarantee and enforcement, but without `requests.memory` the pod has no guaranteed minimum and may be evicted under node pressure, failing the 'guarantee a minimum' requirement.

How to eliminate wrong answers

Option A is wrong because `requests.memory` only sets the minimum guaranteed memory but does not enforce any upper limit; the pod could consume unlimited memory and cause node instability. Option B is wrong because `limits.memory` and `requests.cpu` do not address memory limits at all — `requests.cpu` only guarantees CPU, not memory, so the pod could still exceed memory without being terminated. Option C is wrong because `limits.memory` alone enforces a hard cap but does not guarantee a minimum memory allocation; the pod could be starved or evicted if the node is under pressure, failing the 'guarantee a minimum amount of memory' requirement.

Practice this question →

138

MCQmedium

A developer creates a Deployment with 3 replicas. The developer runs 'kubectl get pods' immediately after creation and sees that only 1 pod is in Running state, and the other 2 are Pending. What is the most likely reason for this?

A.The cluster does not have enough resources (CPU/memory) to schedule the additional pods

B.The Deployment's YAML has a syntax error

C.The container image is not available on the worker nodes

D.The kubelet on the node is not running

AnswerA

Pending means the scheduler cannot bind the pod to a node. With 3 replicas requested, insufficient allocatable CPU or memory across nodes leaves the extra pods unschedulable, so they remain Pending rather than failing or restarting.

Why this answer

When a Pod remains in Pending state, it indicates that the scheduler cannot find a suitable node to place it. The most common cause is insufficient cluster resources (CPU or memory) to accommodate the additional Pods, as the scheduler checks node allocatable resources against Pod resource requests. With 2 out of 3 Pods pending, the cluster likely has enough resources for only one replica, leaving the others unscheduled.

Exam trap

CNCF often tests the distinction between Pod lifecycle phases — Pending means scheduling failure, not image or runtime issues — so candidates mistakenly associate Pending with image pull errors or node problems rather than resource insufficiency.

How to eliminate wrong answers

Option B is wrong because a syntax error in the Deployment YAML would cause the API server to reject the resource creation entirely, resulting in no Pods being created at all, not a mix of Running and Pending Pods. Option C is wrong because if the container image were unavailable, the Pods would transition to ImagePullBackOff or ErrImagePull state, not remain Pending — Pending means scheduling hasn't occurred yet. Option D is wrong because if the kubelet were not running on a node, that node would be marked as NotReady, but the scheduler would still attempt to schedule Pods to other nodes; the issue here is that no node has enough resources, not that a node is offline.

Practice this question →

139

Multi-Selectmedium

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

Select 2 answers

A.etcd

B.kube-proxy

C.kube-apiserver

D.kubelet

E.container runtime

AnswersA, C

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. The API server reads and writes exclusively to it, making etcd a core control plane component rather than a node-level one.

Why this answer

etcd (A) is correct because it is the control plane's distributed key-value store that persists all cluster state and configuration data, and kube-apiserver (C) is correct because it is the control plane component that exposes the Kubernetes API and serves as the front end through which all other components communicate. The other options are node-level components, not control plane components: kube-proxy (B) maintains network rules for Service traffic on each node, kubelet (D) runs on each node to manage Pods and containers, and the container runtime (E) is the software on each node that actually runs containers.

Exam trap

A common trap is confusing control plane components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) with node-level components like kubelet, kube-proxy, and the container runtime. Candidates often select kube-proxy or kubelet, which run on every node, instead of the centralized control plane services.

Practice this question →

140

MCQhard

A pod has resource requests: cpu: 250m, memory: 512Mi and limits: cpu: 500m, memory: 1Gi. If the container tries to use 600m CPU and 700Mi memory, what will happen?

A.The container will be allowed to use the extra resources because limits are only soft constraints

B.The container will be throttled for CPU and may be terminated if it continues to exceed the limit

C.The container will be throttled for CPU, but will not be killed because memory is within limits

D.The container will be killed immediately because it exceeded its CPU limit

AnswerC

CPU is a compressible resource, so exceeding the 500m limit triggers CFS throttling rather than termination. Memory is incompressible, but 700Mi stays below the 1Gi limit, so no OOM kill occurs. The constraint satisfied is that only memory overage causes container termination.

Why this answer

CPU is a compressible resource: exceeding the CPU limit (500m) causes throttling, not termination. Memory is a non-compressible resource, and since the container's memory usage (700Mi) is below its limit (1Gi), it will not be killed. The container will be CPU-throttled but allowed to continue running.

Exam trap

The trap here is that candidates often confuse compressible (CPU) and non-compressible (memory) resources, incorrectly assuming that exceeding any limit leads to termination, whereas CPU only causes throttling and memory causes termination.

How to eliminate wrong answers

Option A is wrong because Kubernetes limits are hard constraints enforced by the kubelet and container runtime, not soft constraints; exceeding CPU limits causes throttling, and exceeding memory limits can cause termination. Option B is wrong because while the container will be throttled for CPU, it will not be terminated solely for exceeding the CPU limit; termination only occurs for memory limit violations or other OOM scenarios. Option D is wrong because CPU limits do not cause immediate termination; the container is throttled at the cgroup level, and only memory limit violations lead to OOM kills.

Practice this question →

141

MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 Insufficient memory'. What is the most likely cause?

A.All nodes have taints that the pod cannot tolerate

B.The pod's liveness probe is failing

C.The container image is not found

D.The pod requires more memory than any node can allocate

AnswerD

The scheduler's memory predicate compares the pod's memory request against each node's allocatable memory. All four nodes fail this filter, leaving no feasible node, so the pod remains Pending until requests are lowered or capacity added.

Why this answer

The error message '0/4 nodes are available: 4 Insufficient memory' directly indicates that the pod's memory request exceeds the allocatable memory on every node in the cluster. The Kubernetes scheduler evaluates resource requests (spec.containers[].resources.requests.memory) against node capacity, and if no node can satisfy the request, the pod remains in Pending state.

Exam trap

Kubernetes certification exams often test the distinction between scheduling failures (Pending) and runtime errors (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or probe issues with Pending state instead of recognizing the scheduler's resource check.

How to eliminate wrong answers

Option A is wrong because taints and tolerations produce a different error message, such as '0/4 nodes are available: 4 node(s) had taint {key:value} that the pod didn't tolerate', not 'Insufficient memory'. Option B is wrong because a failing liveness probe would cause the pod to be restarted or become CrashLoopBackOff, not stuck in Pending; Pending occurs before the pod is scheduled to a node. Option C is wrong because an image-not-found error results in ErrImagePull or ImagePullBackOff after scheduling, not a Pending state with a scheduling failure message.

Practice this question →

142

MCQmedium

Which resource provides stable network endpoints to a set of pods, regardless of pod IP changes?

A.ConfigMap

B.Service

C.Deployment

D.Ingress

AnswerB

A Service assigns a stable virtual IP and DNS name, load-balancing traffic to backing pods selected by labels. This satisfies the stable-endpoint requirement, since pod IPs change on recreation, whereas the Service's ClusterIP persists for the Service's lifetime.

Why this answer

A Service provides a stable virtual IP and DNS name that remains constant even as pods are created, destroyed, or rescheduled. It uses label selectors to dynamically route traffic to the backing pods, abstracting away their individual IP changes. This is the core mechanism for reliable network endpoints in Kubernetes.

Exam trap

A common trap is confusing a Service's stable network endpoint role with a Deployment's pod lifecycle management role, leading candidates to incorrectly choose Deployment.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to provide network endpoints. Option C is wrong because a Deployment manages the desired state of replica sets and pods, but does not expose a stable network endpoint; pods managed by a Deployment still have ephemeral IPs. Option D is wrong because an Ingress is a layer 7 resource that routes external HTTP/HTTPS traffic to Services, not directly to pods, and it depends on a Service for stable endpoints.

Practice this question →

143

MCQhard

A pod is running but you need to view the contents of a file '/var/log/app.log' inside the container to debug an issue. Which kubectl command allows you to do this without modifying the pod?

A.kubectl logs pod-name -c container-name --tail=100

B.kubectl cp pod-name:/var/log/app.log -

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

D.kubectl attach pod-name

AnswerC

`kubectl exec` opens a stream into the already-running container's namespace, so `cat` reads `/var/log/app.log` from the container's own filesystem without restarting or altering the pod. This satisfies the stem's constraint of inspecting a live container's file contents non-destructively, unlike `logs`, `cp`, or `describe`.

Why this answer

`kubectl exec pod-name -- cat /var/log/app.log` runs the `cat` command inside the container without modifying the pod or its state. This allows you to view the file contents directly from the container's filesystem, which is essential for debugging when the application logs are not written to stdout/stderr and thus not accessible via `kubectl logs`.

Exam trap

The trap here is that candidates often confuse `kubectl logs` with reading arbitrary files, assuming it can retrieve any log file, when in fact it only captures container stdout/stderr streams, while `kubectl exec` is the correct tool for accessing files inside a container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` only retrieves logs written to the container's stdout/stderr streams, not arbitrary files like `/var/log/app.log`. Option B is wrong because `kubectl cp` is used to copy files between a pod and the local machine, but the syntax shown (`kubectl cp pod-name:/var/log/app.log -`) is incomplete and would fail; the correct usage requires a local destination path, and even then it modifies the pod's filesystem only if copying into the pod, but here it attempts to copy out, which does not modify the pod but the command as given is invalid. Option D is wrong because `kubectl attach` attaches to the container's main process (usually PID 1) and streams its stdout/stderr, which does not allow you to read an arbitrary file and typically interferes with the running process.

Practice this question →

144

MCQmedium

A Deployment named 'web' has 3 replicas. You run 'kubectl scale deployment web --replicas=5'. What will happen?

A.Two additional Pods are created to reach a total of 5 replicas.

B.An error occurs because scaling a Deployment is not allowed.

C.The Deployment is updated and all Pods are restarted.

D.The existing Pods are deleted and 5 new Pods are created.

AnswerA

Scaling the Deployment updates its desired replica count to 5, so the ReplicaSet controller creates two additional Pods to reconcile actual state with desired state. The existing three Pods remain untouched, satisfying the stem's requirement of reaching a total of 5 replicas without recreating running workloads.

Why this answer

The `kubectl scale` command adjusts the replica count of a Deployment to the desired number. Since the Deployment currently has 3 replicas and the command sets `--replicas=5`, the ReplicaSet controller creates 2 additional Pods to match the desired state. No existing Pods are deleted or restarted unless the Pod template changes.

Exam trap

The trap here is confusing scaling with a rolling update — candidates often think changing the replica count restarts all Pods, but scaling only adjusts the number of Pods without modifying their configuration.

How to eliminate wrong answers

Option B is wrong because scaling a Deployment is a fundamental and allowed operation in Kubernetes; the `scale` subcommand is explicitly designed for this purpose. Option C is wrong because scaling does not update the Pod template (e.g., container image or environment variables), so no rolling update or restart of existing Pods occurs. Option D is wrong because scaling only adds or removes Pods to reach the target count; existing Pods are not deleted unless the replica count is reduced.

Practice this question →

145

Multi-Selecthard

Which three components are part of the Kubernetes control plane? (Select THREE)

Select 3 answers

A.etcd

B.kube-apiserver

C.kube-proxy

D.kube-controller-manager

E.kubelet

AnswersA, B, D

etcd is the control plane's distributed key-value store, persisting all cluster state and configuration. It is one of the three core control plane components named in the KCNA syllabus, alongside the kube-apiserver and kube-controller-manager, so it satisfies the question's requirement for a control plane member.

Why this answer

etcd (A) is correct because it is the control plane's distributed key-value store that persists all cluster state and object data. kube-apiserver (B) is correct because it is the central control plane component that exposes the Kubernetes API and is the front end through which all other components communicate. kube-controller-manager (D) is correct because it runs the built-in controller loops that reconcile cluster state toward the desired state. kube-proxy (C) is not part of the control plane; it runs on each node to implement Service networking via iptables/IPVS rules. kubelet (E) is also not part of the control plane; it is the node agent that manages Pods and containers on each worker node.

Exam trap

CNCF often tests the distinction between control plane and worker node components, and the trap here is that candidates confuse kube-proxy or kubelet as control plane components because they are essential to cluster operation, but they actually run on every node and are not part of the control plane.

Practice this question →

146

MCQeasy

Which Kubernetes control plane component is responsible for maintaining the desired state of the cluster, such as ensuring the correct number of pods are running?

A.kube-controller-manager

B.kube-apiserver

C.kube-scheduler

D.etcd

AnswerA

The kube-controller-manager runs reconciliation loops that continuously compare observed cluster state against the declared desired state, spawning or deleting pods to match a ReplicaSet's replica count. This satisfies the stem's requirement to maintain desired state and correct pod numbers, a duty distinct from the API server's storage role or the scheduler's one-off placement decisions.

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, including the Replication Controller, which is responsible for ensuring that the desired number of pod replicas are running at all times. It continuously watches the state of the cluster via the kube-apiserver and makes adjustments to reconcile the current state with the desired state defined in the cluster's configuration.

Exam trap

CNCF often tests the distinction between the component that stores state (etcd) and the component that actively reconciles state (kube-controller-manager), leading candidates to mistakenly choose etcd because it holds the desired state data.

How to eliminate wrong answers

Option B is wrong because the kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handling authentication, authorization, and API requests, but it does not directly manage the desired state of pods or other resources. Option C is wrong because the kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability and constraints, not for maintaining the desired number of running pods. Option D is wrong because etcd is a distributed key-value store that holds the cluster's configuration and state data, but it is a data store, not a controller that actively reconciles desired state.

Practice this question →

147

MCQeasy

What is the primary purpose of the Kubernetes control plane component 'kube-apiserver'?

A.Run container runtime operations on nodes

B.Schedule pods onto nodes

C.Store cluster state and configuration

D.Expose the Kubernetes REST API and act as the entry point for all administrative tasks

AnswerD

kube-apiserver exposes the Kubernetes REST API, making it the sole entry point for administrative tasks: every kubectl command, controller and scheduler request flows through it for authentication, authorisation and admission before persisting state to etcd. This satisfies the stem's requirement for the control plane's central API gateway role.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes REST API. It validates and processes all administrative requests (e.g., creating pods, scaling deployments) and is the only component that directly interacts with the etcd datastore. This makes it the central entry point for all cluster management tasks, aligning with option D.

Other options are incorrect: A describes the kubelet, B describes the kube-scheduler, and C describes etcd.

Exam trap

A common misconception is that the kube-apiserver stores cluster state, when in fact it only mediates access to etcd, which is the actual persistent store.

How to eliminate wrong answers

Option A is wrong because running container runtime operations on nodes is the responsibility of the kubelet, not the kube-apiserver. Option B is wrong because scheduling pods onto nodes is performed by the kube-scheduler, which watches for unscheduled pods and assigns them to nodes based on resource availability and constraints. Option C is wrong because storing cluster state and configuration is the role of etcd, a distributed key-value store; the kube-apiserver reads from and writes to etcd but does not itself store the data.

Practice this question →

148

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane?

Select 2 answers

A.kube-proxy

B.kubelet

C.etcd

D.kube-apiserver

E.container runtime

AnswersC, D

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. It satisfies the control plane membership criterion because it runs on control plane nodes alongside the API server, scheduler and controller manager, rather than on worker nodes with kubelet and kube-proxy.

Why this answer

etcd (C) is correct because it is the control plane's distributed key-value store that persistently holds all cluster state and configuration data, which the API server reads and writes. kube-apiserver (D) is correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the front end through which all other components communicate. The other options are node-level components, not control plane components: kube-proxy (A) implements Service networking rules on each node, kubelet (B) runs on each node and manages Pods/containers via the container runtime, and the container runtime (E) is the node software (e.g., containerd, CRI-O) that actually runs containers.

Exam trap

The KCNA exam often tests the misconception that kubelet or kube-proxy are control plane components because they are essential for cluster operation, but they actually run on every node as part of the data plane.

Practice this question →

149

Multi-Selecthard

Which THREE of the following are valid apiVersions for Kubernetes resources?

Select 3 answers

A.batch/v1

B.v1

C.apps/v1

D.extensions/v1beta1

E.v1beta1

AnswersA, B, C

batch/v1 is a genuine, stable Kubernetes API group/version, used by the Job and CronJob resources. It satisfies the stem's requirement for a valid apiVersion, since Kubernetes apiVersions follow the group/version format and batch/v1 remains actively served by current clusters.

Why this answer

The three valid apiVersions here are batch/v1 (A), v1 (B), and apps/v1 (C). batch/v1 is the stable API group/version used for workload resources such as Job and CronJob, so it is a legitimate apiVersion value. v1 is the core (legacy) API group version used for resources like Pod, Service, ConfigMap, and Secret, and it is valid without a group prefix. apps/v1 is the stable API group/version for workloads such as Deployment, StatefulSet, DaemonSet, and ReplicaSet, making it valid as well. The unmarked options do not belong because extensions/v1beta1 (D) is a removed/deprecated API group version no longer served in modern Kubernetes clusters, and v1beta1 (E) is not a complete apiVersion by itself since a beta version must be qualified by its API group (for example, apps/v1beta1 or batch/v1beta1).

Exam trap

The KCNA exam often tests the distinction between core group versions (just 'v1') and named group versions (e.g., 'apps/v1'), and the trap here is that candidates may think 'v1beta1' is valid as a standalone version, not realizing it requires a group prefix, or they may mistakenly consider deprecated versions like extensions/v1beta1 as still valid.

Practice this question →

150

MCQmedium

You need to run a batch job that processes data and then exits. Which Kubernetes resource type is most appropriate for this workload?

A.Deployment

B.DaemonSet

C.Job

D.StatefulSet

AnswerC

A Job creates Pods that run to completion and tracks successful termination, which suits batch processing that exits after finishing. Deployments and ReplicaSets instead maintain continuously running replicas, so they restart or replace Pods rather than allowing them to exit cleanly.

Why this answer

A Kubernetes Job is designed for workloads that run to completion and then exit, such as batch processing, data transformation, or one-off tasks. Unlike controllers that maintain a desired number of running Pods (like Deployments), Jobs ensure that a specified number of Pods successfully terminate, making them the correct choice for this scenario.

Exam trap

A common misconception is that any workload requiring Pods must use a Deployment, but the key differentiator is whether the workload is long-running or batch/terminating, which is exactly what the Job resource is designed for.

How to eliminate wrong answers

Option A is wrong because a Deployment is intended for long-running, stateless services that must maintain a specified number of replicas continuously; it will restart Pods if they exit, which is not appropriate for a batch job that should terminate. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, typically for daemon processes like logging or monitoring, not for one-off batch tasks. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage, such as databases, and is not designed for ephemeral batch processing that exits after completion.

Practice this question →