CCNA Kubernetes Fundamentals Questions — Page 4 of 5

226

MCQmedium

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

A.Container runtime

B.kubelet

C.kube-proxy

D.kube-scheduler

AnswerB

The kubelet ensures that containers in a Pod are running according to the PodSpec.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

227

MCQmedium

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

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

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

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

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

AnswerD

Correct command.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

228

MCQhard

A pod in a ReplicaSet is failing with 'CrashLoopBackOff'. 'kubectl logs pod' shows 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

A.The readiness probe is misconfigured.

B.The container image is missing the application binary.

C.The container's process is not terminating quickly enough on SIGTERM, causing a port conflict on restart.

D.The pod is using hostPort and two pods on the same node conflict.

AnswerC

Old process still holds the port.

Why this answer

The error 'address already in use' on port 8080 indicates that when the container restarts, the previous process is still holding the port. This typically happens when the application does not handle SIGTERM properly and does not shut down within the terminationGracePeriodSeconds (default 30s), so the old process lingers while the new one tries to bind to the same port, causing a CrashLoopBackOff.

Exam trap

CNCF often tests the distinction between pod startup failures caused by resource constraints or probe misconfiguration versus application-level port conflicts that arise from improper signal handling during restarts.

How to eliminate wrong answers

Option A is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready, but it would not produce a 'bind: address already in use' error in the logs. Option B is wrong because if the container image were missing the application binary, the error would be something like 'executable file not found' or 'no such file or directory', not a port binding error. Option D is wrong because hostPort is used for port mapping to the node, but the error is about a port conflict inside the same container on restart, not between two different pods on the same node.

Practice this question →

229

MCQeasy

What is the primary purpose of a Kubernetes Service object?

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

B.To manage rolling updates and rollbacks for Pods

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

D.To persist data beyond the lifecycle of a Pod

AnswerC

Services create a durable endpoint that abstracts the underlying Pod IPs, supporting load balancing and service discovery.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

230

Multi-Selectmedium

Which TWO of the following are Kubernetes control plane components?

Select 2 answers

A.kube-apiserver

B.container runtime

C.etcd

D.kube-proxy

E.kubelet

AnswersA, C

The API server is a core control plane component.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane, exposing the Kubernetes API. It validates and processes RESTful requests (using JSON/YAML over HTTP/HTTPS) that create, update, or delete cluster resources, and it is the only component that communicates directly with etcd. Without the API server, no control plane operations can be performed.

Exam trap

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

Practice this question →

231

MCQhard

A pod is stuck in Terminating state for several minutes. What is the most likely cause?

A.The node is unreachable or the kubelet is not responding

B.The deployment is configured with a grace period

C.The pod has a liveness probe that is failing

D.The pod's container runtime is paused

AnswerA

If the kubelet cannot be contacted, the pod cannot be terminated.

Why this answer

When a pod is stuck in Terminating state, the most likely cause is that the node where the pod was running is unreachable or the kubelet is not responding. The kubelet is responsible for executing the pod's termination lifecycle, including sending SIGTERM and, after the grace period, SIGKILL. If the kubelet cannot communicate with the API server (e.g., due to node failure, network partition, or kubelet crash), the pod's finalizer cannot be removed, leaving it stuck in Terminating.

Exam trap

CNCF often tests the misconception that a failing liveness probe or a misconfigured grace period causes a pod to be stuck in Terminating, when in fact the root cause is almost always a node or kubelet communication issue.

How to eliminate wrong answers

Option B is wrong because a deployment configured with a grace period (terminationGracePeriodSeconds) is normal and does not cause a pod to be stuck; the pod will be forcefully terminated after the grace period expires. Option C is wrong because a failing liveness probe causes the pod to be restarted or recreated, not stuck in Terminating; liveness probes affect running pods, not termination. Option D is wrong because a paused container runtime would prevent the pod from starting or running, but it does not prevent the kubelet from completing the termination process; the kubelet can still force-kill the container.

Practice this question →

232

Multi-Selectmedium

Which TWO statements about Namespaces are correct?

Select 2 answers

A.Namespaces provide a way to divide cluster resources among multiple users

B.Namespaces act as a strong security boundary by default

C.Namespaces help organize objects in a cluster

D.Every resource must be created in a namespace

E.Resources in different namespaces cannot communicate with each other

AnswersA, C

Namespaces enable resource quotas and access control scoping.

Why this answer

Namespaces in Kubernetes provide a mechanism for partitioning a single cluster into multiple virtual clusters, enabling resource quota management and access control for different users or teams. This allows administrators to divide cluster resources (like CPU, memory, and storage) among multiple users via ResourceQuotas and LimitRanges, without requiring separate physical clusters.

Exam trap

CNCF often tests the misconception that Namespaces provide strong security isolation by default, when in reality they only offer logical separation and require explicit NetworkPolicies and RBAC for security.

Practice this question →

233

MCQeasy

What is the primary purpose of a Kubernetes Service?

A.To manage container image versions

B.To store configuration data as key-value pairs

C.To provide a stable endpoint for accessing a set of pods

D.To schedule pods onto nodes

AnswerC

A Service exposes a logical set of pods with a stable IP and DNS name, enabling reliable communication.

Why this answer

A Kubernetes Service provides a stable, virtual IP address and DNS name that acts as a consistent endpoint for accessing a set of pods, regardless of pod IP changes due to scaling, restarts, or scheduling. It decouples frontend clients from backend pods by using label selectors to route traffic, ensuring high availability and load balancing across the pod group.

Exam trap

The trap here is that candidates confuse a Service with a Deployment or ReplicaSet, thinking its purpose is to manage pod lifecycle or scaling, rather than understanding it is purely a networking abstraction for stable pod access.

How to eliminate wrong answers

Option A is wrong because managing container image versions is the responsibility of container registries and image tags, not a Service; this is handled by tools like Docker Hub or Kubernetes image pull policies. Option B is wrong because storing configuration data as key-value pairs is the purpose of a ConfigMap or Secret, not a Service; Services handle network abstraction, not configuration storage. Option D is wrong because scheduling pods onto nodes is the job of the Kubernetes Scheduler, which uses resource requests and constraints, not a Service; a Service only routes traffic to already-scheduled pods.

Practice this question →

234

Multi-Selecteasy

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

Select 2 answers

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

B.Storing cluster state

C.Exposing the Kubernetes API

D.Monitoring node health and responding to node failures

E.Assigning pods to nodes

AnswersA, D

The replication controller ensures the correct number of pod replicas.

Why this answer

The kube-controller-manager runs controller processes that regulate the state of the cluster. The replication controller (part of the controller manager) ensures that the actual number of pod replicas matches the desired count specified in a ReplicaSet or ReplicationController, automatically creating or terminating pods as needed. Additionally, the node controller within the kube-controller-manager periodically checks node health via the Node Lifecycle Controller, which monitors heartbeats (NodeStatus updates) and responds to node failures by tainting the node and evicting pods after a configurable timeout (default 5 minutes).

Exam trap

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

Practice this question →

235

MCQmedium

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

A.The pod's container has crashed

B.The pod's service endpoint is misconfigured

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

D.The container image is invalid

AnswerC

If no node meets the pod's requirements, the pod remains unscheduled.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

236

MCQeasy

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

A.Container

B.Pod

C.Service

D.Deployment

AnswerB

Why this answer

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

Exam trap

The trap here is that candidates confuse containers (the runtime process) with Pods (the Kubernetes API object), leading them to pick 'Container' because they think of Docker-style units, but Kubernetes always wraps containers inside Pods as the smallest deployable and manageable entity.

How to eliminate wrong answers

Option A is wrong because a container is not a Kubernetes API object; it is a runtime abstraction managed by the container runtime (e.g., containerd), and Kubernetes schedules and manages Pods, not individual containers. Option C is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them; it is not a deployable unit but a networking resource that sits above Pods. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest unit but a management layer over Pods.

Practice this question →

237

MCQmedium

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

A.StatefulSet

B.DaemonSet

C.Job

D.Deployment

AnswerC

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

238

Multi-Selecthard

Which TWO of the following statements about Kubernetes namespaces are true?

Select 2 answers

A.Services in different namespaces cannot communicate with each other

B.Every Kubernetes object must be created in a namespace

C.Deleting a namespace will delete all objects in it

D.Namespaces can be used to implement resource quotas

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

AnswersC, D

Correct. Deleting a namespace deletes all objects inside it.

Why this answer

Deleting a namespace triggers cascading deletion of all objects within it. Option D is correct because resource quotas can be applied per namespace to limit aggregate resource consumption. Option E is not entirely accurate: namespaces provide logical isolation, but dividing cluster resources among multiple users requires additional mechanisms like RBAC and resource quotas.

Without those, namespaces alone do not enforce resource division.

Exam trap

The trap is that many candidates think namespaces provide network isolation by default, but in reality, Kubernetes does not enforce inter-namespace network restrictions unless NetworkPolicies are explicitly applied.

Practice this question →

239

MCQhard

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

A.kubectl create -f manifest.yaml

B.kubectl patch -f manifest.yaml

C.kubectl replace -f manifest.yaml

D.kubectl apply -f manifest.yaml

AnswerD

Apply is the recommended declarative approach.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

240

MCQmedium

A Deployment named 'nginx' is failing to update. You run 'kubectl rollout status deployment nginx' and see 'Waiting for deployment "nginx" rollout to finish: 0 out of 3 new replicas have been updated...'. The pod template has an image that does not exist. What is the most likely cause?

A.The cluster is out of memory

B.The deployment has exceeded the revision history limit

C.The deployment is paused

D.The new image tag is incorrect or does not exist in the registry

AnswerD

Non-existent image leads to ImagePullBackOff, preventing new replicas from becoming ready.

Why this answer

The rollout status shows that no new replicas have been created, which is a classic symptom of a container image pull failure. When the image tag specified in the pod template does not exist in the registry, the kubelet cannot pull the image, so the ReplicaSet controller cannot start new pods. This prevents the rollout from progressing past 0 out of 3 new replicas.

Exam trap

The trap here is that candidates may confuse a stuck rollout with resource constraints (memory/CPU) or assume the deployment is paused, but the specific status message '0 out of 3 new replicas have been updated' directly points to an image pull failure, not a scheduling or pause issue.

How to eliminate wrong answers

Option A is wrong because a cluster out-of-memory condition would typically cause pods to be in a Pending state with 'Insufficient memory' events, not a stuck rollout with 0 new replicas; the scheduler would fail to place pods, but the image pull issue is unrelated to memory. Option B is wrong because exceeding the revision history limit (default 10) only affects the number of old ReplicaSets retained, not the ability to create new replicas; the rollout would still proceed and create new pods. Option C is wrong because a paused deployment would show a different status message, such as 'deployment "nginx" paused', and the rollout status command would not report 'Waiting for deployment... rollout to finish'; paused deployments do not attempt to create new replicas at all.

Practice this question →

241

MCQmedium

You create a Pod with the following YAML. What will happen when you apply it?

A.The Pod will fail to create because memory and CPU are in the wrong unit

B.The Pod will be created with memory limit of 128Mi and CPU limit of 500m

C.The Pod will be created without resource limits because the syntax is incorrect

D.The Pod will be created but requests and limits will be ignored because they are not valid for Pods

AnswerB

The YAML correctly specifies limits and requests.

Why this answer

The YAML defines resource limits and requests using standard Kubernetes units: '128Mi' for memory (mebibytes) and '500m' for CPU (millicores). These are valid and will be applied to the container, creating the Pod with the specified limits.

Exam trap

CNCF often tests the misconception that resource units like '128Mi' or '500m' are invalid or that resource limits are not applicable to Pods, when in fact they are standard and correctly applied to containers.

How to eliminate wrong answers

Option A is wrong because '128Mi' and '500m' are correct Kubernetes resource units (Mi = mebibytes, m = millicores), not invalid. Option C is wrong because the syntax is correct; resource limits are defined under 'resources.limits' and will be applied. Option D is wrong because resource limits and requests are valid for containers within a Pod, and they are not ignored; they are enforced by the kubelet.

Practice this question →

242

MCQhard

You have a multi-container pod with containers 'app' and 'sidecar'. You need to execute a shell command inside the 'sidecar' container. Which kubectl command should you use?

A.kubectl exec -it mypod -- /bin/sh

B.kubectl exec -it sidecar --container mypod -- /bin/sh

C.kubectl exec -it mypod --container sidecar -- /bin/sh

D.kubectl exec -it mypod -c sidecar -- /bin/sh

AnswerD

The -c flag specifies the container to exec into.

Why this answer

`kubectl exec` uses the `-c` flag (or `--container`) to specify a target container within a multi-container pod. The syntax `kubectl exec -it mypod -c sidecar -- /bin/sh` opens an interactive shell in the 'sidecar' container of the pod named 'mypod'. Without the `-c` flag, the command defaults to the first container in the pod's spec, which would be 'app'.

Exam trap

CNCF often tests the misconception that `kubectl exec` defaults to the first container or that the container flag is optional, leading candidates to pick option A, which would execute in the wrong container.

How to eliminate wrong answers

Option A is wrong because it omits the `-c` flag, so the shell executes in the first container (typically 'app') rather than 'sidecar'. Option B is wrong because it incorrectly places `--container mypod` as a value for the container flag; the flag expects a container name, not a pod name, and the pod name should follow `exec`. Option C is wrong because it uses `--container sidecar` after the pod name, which is syntactically valid but not the standard short form; however, the primary issue is that the order of arguments is non-standard and could cause confusion, but the real trap is that `--container` is a valid alternative to `-c`, so this option is actually correct in function but not the preferred or most common syntax; however, for the KCNA exam, the `-c` flag is the standard and expected answer, and option C uses the long form `--container` which is also acceptable but less concise.

The question asks 'Which kubectl command should you use?' and D is the most direct and standard form.

Practice this question →

243

MCQeasy

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

A.Deployment

B.ConfigMap

C.Service

D.Pod

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

244

Multi-Selecthard

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

Select 3 answers

A.You only need a single instance of the application

B.You need stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules

C.You need each pod to have its own persistent storage that is not shared

D.You need to deploy a stateless web application with multiple replicas

E.You need ordered, graceful deployment and scaling (e.g., pod-0 starts before pod-1)

AnswersB, C, E

StatefulSets provide stable network identities (e.g., pod-0, pod-1) that are maintained across rescheduling.

Why this answer

StatefulSets provide stable, unique network identifiers (e.g., pod hostnames) that persist across reschedules because each pod gets a fixed ordinal index (e.g., pod-0, pod-1) and a corresponding DNS name (e.g., pod-0.statefulset.namespace.svc.cluster.local). This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent peer discovery and identity, which Deployments cannot guarantee since they assign random pod names and IPs.

Exam trap

CNCF often tests the misconception that StatefulSets are only for persistent storage, but the trap here is that candidates overlook the requirement for stable network identities and ordered operations, which are equally critical and distinct from storage needs.

Practice this question →

245

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Deployment

B.Pod

C.Container

D.Node

AnswerB

A Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. This satisfies the constraint of atomic scheduling: a Pod is the indivisible object that the scheduler places onto a single node, and it cannot be split across nodes. Containers alone are not directly scheduled; they must be wrapped inside a Pod to run.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it represents a single instance of a running process in the cluster and encapsulates one or more containers with shared storage and network resources. While containers are the runtime units, Kubernetes schedules and manages Pods, not individual containers, making the Pod the atomic building block for deployment.

Exam trap

CNCF often tests the misconception that a container is the smallest deployable unit because containers are the runtime entities, but Kubernetes abstracts them into Pods for scheduling and resource sharing, so candidates who confuse 'runtime unit' with 'deployable unit' will incorrectly select Container.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level abstraction that manages ReplicaSets and Pods, not the smallest deployable unit itself. Option C is wrong because a Container is the runtime process inside a Pod, but Kubernetes cannot schedule or manage a container directly without a Pod wrapper. Option D is wrong because a Node is a worker machine in the cluster that hosts Pods, not a deployable unit — you deploy Pods onto Nodes, not Nodes themselves.

Practice this question →

246

MCQmedium

A team wants to minimize downtime during a Deployment rollout. Which strategy ensures that new pods are created before old pods are terminated?

A.Set strategy type to 'Recreate'.

B.Set strategy type to 'RollingUpdate' with maxSurge=0, maxUnavailable=1.

C.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=0.

D.Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=1.

AnswerC

New pods are created first, ensuring zero downtime.

Why this answer

Setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.

Exam trap

The trap here is that candidates often confuse `maxSurge` and `maxUnavailable` values, mistakenly thinking that allowing both a surge and an unavailable pod (option D) is safer, when in fact it can still cause a temporary capacity drop if the new pod is not ready before the old one is terminated.

How to eliminate wrong answers

Option A is wrong because the 'Recreate' strategy terminates all old pods before creating new ones, causing downtime. Option B is wrong because `maxSurge=0, maxUnavailable=1` terminates one old pod before creating a new one, which can cause a temporary capacity deficit and potential downtime. Option D is wrong because `maxSurge=1, maxUnavailable=1` allows both a new pod to be created and an old pod to be terminated simultaneously, which may still result in a brief capacity drop if the new pod is not ready before the old one is removed.

Practice this question →

247

Multi-Selectmedium

Which three of the following are valid methods to create or update resources in Kubernetes? (Choose three.)

Select 3 answers

A.kubectl apply -f manifest.yaml

B.kubectl update -f manifest.yaml

C.kubectl replace -f manifest.yaml

D.kubectl create -f manifest.yaml

E.Using the Kubernetes REST API directly

AnswersA, D, E

`kubectl apply -f manifest.yaml` is a declarative command that creates or updates resources, making it a valid method.

Why this answer

`kubectl apply -f manifest.yaml` is correct because it uses a declarative approach to create or update resources by applying a configuration file, performing a three-way merge between the local file, the current live object, and the last-applied annotation. `kubectl create -f manifest.yaml` is also correct because it creates resources from a file or stdin, though it will fail if the resource already exists. Using the Kubernetes REST API directly (via HTTP requests like POST for create and PUT for update) is another valid method. `kubectl update` is not a valid kubectl command; the correct imperative commands for updates are `kubectl edit` or `kubectl patch`. `kubectl replace -f manifest.yaml` is an imperative command that will fail if the resource does not exist and is not recommended for general resource management.

Exam trap

The trap here is that candidates often confuse `kubectl replace` as a valid update method because it sounds similar to 'update', but it is an imperative command that fails on non-existent resources and does not support declarative management like `apply`.

Practice this question →

248

MCQhard

An application running in a Kubernetes cluster needs to securely access a third-party API. The API key must be stored in the cluster and mounted into the Pod as an environment variable. Which is the best practice?

A.Create a Secret with the API key and use envFrom or valueFrom in the Pod spec.

B.Store the API key in a ConfigMap and reference it in the Pod spec.

C.Embed the API key directly in the container image.

D.Store the API key in a Pod annotation and read it with kubectl.

AnswerA

Secrets are designed for confidential data and can be injected as environment variables.

Why this answer

Kubernetes Secrets are specifically designed to store sensitive data like API keys, and using `envFrom` or `valueFrom` in the Pod spec injects the Secret value as an environment variable without exposing it in the Pod definition. This approach follows the principle of least privilege and avoids hardcoding secrets in images or plaintext ConfigMaps.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are equally secure for sensitive data, but Kubernetes tests the understanding that ConfigMaps store data in plaintext and are not encrypted, making them unsuitable for secrets like API keys.

How to eliminate wrong answers

Option B is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets; using a ConfigMap for an API key would expose it in etcd and logs. Option C is wrong because embedding the API key directly in the container image violates security best practices, as the key would be baked into the image layers and accessible to anyone with image pull access. Option D is wrong because Pod annotations are metadata fields not designed for secret storage, and reading them with kubectl would expose the key in the API server and command output.

Practice this question →

249

Multi-Selecthard

Which THREE of the following are true about Kubernetes labels and selectors?

Select 3 answers

A.Labels are encrypted at rest by default

B.Set-based selectors support operators like 'In' and 'NotIn'

C.Selectors can be used by Services to identify which pods to route traffic to

D.Labels are immutable after creation

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

AnswersB, C, E

Set-based selectors support 'In', 'NotIn', 'Exists', and 'DoesNotExist'.

Why this answer

Kubernetes set-based selectors support operators like 'In', 'NotIn', 'Exists', and 'DoesNotExist', allowing more flexible matching than equality-based selectors. This is defined in the Kubernetes API specification for label selectors, enabling complex filtering of resources.

Exam trap

CNCF often tests the misconception that labels are immutable like certain other Kubernetes fields, but labels are explicitly designed to be mutable for dynamic resource management.

Practice this question →

250

MCQmedium

Which Kubernetes object provides a stable IP address and DNS name to access a set of pods, and can perform load balancing?

A.Service

B.Ingress

C.Deployment

D.Pod

AnswerA

Services provide stable IP and DNS, and load balance traffic to selected pods.

Why this answer

A Service is the correct Kubernetes object because it provides a stable virtual IP (ClusterIP) and a DNS name (via CoreDNS) that remains constant even as pods are created or destroyed. It performs layer 4 (TCP/UDP) load balancing across the set of pods selected by its label selector, using iptables or IPVS rules to distribute traffic.

Exam trap

A common misconception is that Ingress itself performs load balancing, but Ingress is only a routing rule set; the actual load balancing is done by the Service or the Ingress controller's underlying proxy.

How to eliminate wrong answers

Option B (Ingress) is wrong because Ingress is not a load balancer itself; it is an API object that manages external HTTP/HTTPS access to Services, typically relying on a controller (e.g., NGINX) to route traffic, and it does not provide a stable IP or DNS name directly to pods. Option C (Deployment) is wrong because a Deployment manages the desired state of replica sets and pod rollouts, but it does not expose a network endpoint or perform load balancing. Option D (Pod) is wrong because a Pod has a dynamic IP address that changes on restart, and it cannot provide stable DNS or load balancing across multiple pods.

Practice this question →

251

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Node

B.Container

C.Deployment

D.Pod

AnswerD

A Pod is the atomic unit of scheduling in Kubernetes.

Why this answer

The Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto nodes; instead, Kubernetes always wraps them into Pods, which are the atomic unit of scheduling and execution. This design ensures that co-located containers (e.g., a sidecar and its main app) can communicate via localhost and share resources without additional orchestration.

Exam trap

A common misconception is that a Container is the smallest unit because it is the runtime entity, but Kubernetes abstracts containers into Pods to enforce co-location and shared networking, making the Pod the fundamental scheduling and deployment atom.

How to eliminate wrong answers

Option A is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, but it is not the smallest deployable unit; nodes are infrastructure components that run Pods. Option B is wrong because a Container is the runtime instance of an image, but Kubernetes does not deploy containers directly—containers are always placed inside a Pod, which provides the execution environment and resource boundaries. Option C is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and scaling; it is not the smallest unit of deployment but rather a management abstraction over Pods.

Practice this question →

252

MCQmedium

A team notices that a pod remains in 'CrashLoopBackOff' state after deployment. The application logs show 'Error: unable to bind to port 8080'. What is the most likely cause?

A.The pod's resource limits are too low.

B.An environment variable has a typo in the Deployment spec.

C.The readiness probe is misconfigured.

D.The container's port is already in use on the host node.

AnswerD

Correct; port conflict prevents binding, causing container to exit.

Why this answer

The error 'unable to bind to port 8080' indicates that the container process cannot open port 8080 for listening. The most likely cause is that another process on the host node is already using port 8080, preventing the container from binding to it. This is a classic port conflict scenario, where the host's network namespace has a port already allocated, and the container (even with its own network namespace) may be using host networking or the port is mapped from the host.

Exam trap

The KCNA exam often tests the misconception that a 'CrashLoopBackOff' with a port bind error is caused by resource limits or probe misconfiguration, when in reality it points to a network-level port conflict on the host node.

How to eliminate wrong answers

Option A is wrong because resource limits being too low would cause the pod to be OOMKilled or throttled, not a bind error on a specific port. Option B is wrong because a typo in an environment variable would cause the application to misread configuration, but the error message explicitly states a port binding failure, not a missing or incorrect variable. Option C is wrong because a misconfigured readiness probe would cause the pod to be marked as not ready and removed from service endpoints, but the pod would still start and run; the error here occurs at container startup before any probe can fail.

Practice this question →

253

MCQeasy

What is the smallest deployable unit in Kubernetes?

A.Pod

B.Node

C.Container

D.Deployment

AnswerA

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

Why this answer

A Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. While containers are the runtime processes, Kubernetes schedules and manages Pods as atomic units, meaning you cannot deploy a container directly without a Pod wrapper.

Exam trap

The trap here is that candidates confuse 'container' as the smallest unit because Docker popularized container-centric thinking, but Kubernetes abstracts containers into Pods as the fundamental scheduling and deployment boundary.

How to eliminate wrong answers

Option B is wrong because a Node is a worker machine (physical or virtual) that hosts Pods, not a deployable unit itself; you deploy Pods onto Nodes. Option C is wrong because a Container is the runtime process inside a Pod, but Kubernetes does not schedule containers individually—they must be part of a Pod. Option D is wrong because a Deployment is a higher-level controller that manages the desired state of ReplicaSets and Pods, but the smallest unit it directly operates on is still the Pod.

Practice this question →

254

Matchingmedium

Match each Kubernetes scheduler concept to its description.

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

Concepts

Matches

Constraints that attract pods to nodes based on node labels

Mechanism to repel pods from nodes unless they tolerate the taint

Minimum amount of CPU/memory guaranteed to a container

Maximum amount of CPU/memory a container can use

Indicates importance of a pod relative to others for preemption

Why these pairings

NodeAffinity and NodeSelector both use node labels but differ in expressiveness. PodAffinity schedules relative to other pods. Taints/Tolerations control which pods can be placed on nodes.

Common confusion: swapping NodeAffinity with PodAffinity or Taints/Tolerations.

Practice this question →

255

MCQhard

You need to ensure that a pod runs on a node with SSD storage. How can you achieve this?

A.Use nodeSelector with a label that matches nodes having SSDs

B.Use a taint on nodes without SSDs and a toleration on the pod

C.Use pod anti-affinity to avoid nodes without SSDs

D.Use node affinity with requiredDuringSchedulingIgnoredDuringExecution

AnswerD

Node affinity allows you to specify hard or soft constraints. Using requiredDuringSchedulingIgnoredDuringExecution ensures the pod is only scheduled on nodes with the specified label.

Why this answer

Node affinity with `requiredDuringSchedulingIgnoredDuringExecution` is the correct approach because it allows you to specify a hard constraint that the pod must be scheduled on a node with a specific label (e.g., `disk=ssd`). This ensures the pod runs only on nodes that have SSD storage, as the scheduler enforces this rule during pod placement.

Exam trap

Kubernetes often tests the distinction between node affinity (which attracts pods to nodes with specific labels) and taints/tolerations (which repel pods from nodes), leading candidates to incorrectly choose taints/tolerations when the goal is to ensure a pod runs on a node with a specific feature.

How to eliminate wrong answers

Option A is wrong because `nodeSelector` is a simpler, legacy mechanism that only supports exact match of a single label key-value pair, but it does not provide the flexibility of node affinity (e.g., multiple expressions, `In`, `NotIn` operators) and is less expressive for complex scheduling requirements. Option B is wrong because taints and tolerations are used to repel pods from nodes (unless tolerated), not to attract pods to specific node features; they prevent scheduling on tainted nodes but do not actively ensure a pod lands on a node with SSDs. Option C is wrong because pod anti-affinity is used to avoid co-locating pods with other pods (e.g., spread across nodes), not to select nodes based on hardware characteristics like SSD storage.

Practice this question →

256

MCQeasy

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

A.All nodes have disk pressure.

B.All nodes are unreachable or have been cordoned.

C.The pod has a toleration that matches the taint.

D.The nodes do not have enough CPU or memory.

AnswerB

The taint indicates nodes are unreachable.

Why this answer

The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).

Exam trap

The KCNA exam often tests the distinction between taint types — candidates confuse `unreachable` with resource-based taints like `disk-pressure` or `insufficient-memory`, or assume a toleration would solve the issue when the problem is that no toleration exists.

How to eliminate wrong answers

Option A is wrong because disk pressure is indicated by the taint `node.kubernetes.io/disk-pressure`, not `node.kubernetes.io/unreachable`. Option C is wrong because if the pod had a toleration matching the taint, it would be scheduled despite the taint, but the error explicitly states the pod didn't tolerate it. Option D is wrong because insufficient CPU or memory would show taints like `node.kubernetes.io/insufficient-cpu` or `node.kubernetes.io/insufficient-memory`, not the `unreachable` taint.

Practice this question →

257

MCQmedium

Which Kubernetes object should you use to store non-sensitive configuration data that can be consumed by Pods as environment variables or mounted files?

A.Secret

B.PersistentVolume

C.ConfigMap

D.Service

AnswerC

ConfigMap is used to store non-confidential configuration data in key-value pairs.

Why this answer

ConfigMap is the correct Kubernetes object for storing non-sensitive configuration data, such as key-value pairs or configuration files. It is designed to decouple configuration artifacts from container images, allowing Pods to consume this data as environment variables, command-line arguments, or mounted files in a volume. Unlike Secrets, ConfigMaps do not provide encryption or base64 encoding by default, making them suitable only for non-sensitive information.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both are interchangeable for configuration, but the KCNA exam tests the distinction that Secrets are for sensitive data and ConfigMaps are for non-sensitive data, and that PersistentVolume is for storage, not configuration.

How to eliminate wrong answers

Option A is wrong because Secret is specifically designed for storing sensitive data (e.g., passwords, tokens, SSH keys) and uses base64 encoding with optional encryption at rest, not for non-sensitive configuration. Option B is wrong because PersistentVolume is an abstraction for storage resources (e.g., NFS, iSCSI) that provides persistent storage volumes to Pods, not for storing configuration data as environment variables or files. Option D is wrong because Service is a networking abstraction that exposes a set of Pods as a network service (e.g., ClusterIP, NodePort), and it cannot store or provide configuration data to Pods.

Practice this question →

258

MCQmedium

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

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

B.The container image is invalid

C.Insufficient CPU or memory resources on any available node

D.The pod's liveness probe failed

AnswerC

If no node can satisfy the pod's resource requests, the scheduler leaves it Pending.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

259

MCQmedium

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

A.StatefulSet

B.DaemonSet

C.Job

D.ReplicaSet

AnswerD

Deployment manages ReplicaSets, which in turn manage pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

260

MCQeasy

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

A.kubectl attach <pod-name>

B.kubectl logs <pod-name>

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

D.kubectl describe pod <pod-name>

AnswerB

Correct command.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

261

MCQhard

A developer reports that a Pod cannot reach another Service in the same namespace via its DNS name. The Service name is 'api'. What is the correct DNS query for a Pod to resolve this Service?

A.api.svc.cluster.local

B.api.namespace.svc.cluster.local

C.api

D.api.default.svc.cluster.local

AnswerC

Within the same namespace, the short name works.

Why this answer

When a Pod and a Service are in the same namespace, Kubernetes DNS resolves the Service using just the Service name (e.g., 'api'). The DNS search domain configured in the Pod's resolv.conf (e.g., <namespace>.svc.cluster.local) appends the namespace and cluster suffix automatically, so a short query like 'api' resolves correctly without needing the full FQDN.

Exam trap

The trap here is that candidates often assume the full FQDN (e.g., 'api.svc.cluster.local') is always required, forgetting that DNS search domains in the Pod's resolv.conf enable short-name resolution within the same namespace.

How to eliminate wrong answers

Option A is wrong because 'api.svc.cluster.local' omits the namespace, which is required in the full DNS name; the correct FQDN for a cross-namespace query would be 'api.<namespace>.svc.cluster.local'. Option B is wrong because it includes 'namespace' as a literal string instead of the actual namespace name (e.g., 'default'), making it invalid unless the namespace is literally named 'namespace'. Option D is wrong because it assumes the namespace is 'default', which is not guaranteed; the Pod and Service could be in any namespace, and the short name 'api' works only within the same namespace.

Practice this question →

262

MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Namespaces can be nested

B.Namespaces are required for all resources

C.Namespaces provide network isolation by default

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

AnswerD

Namespaces provide a scope for names and can be used for resource quotas.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

263

MCQhard

Refer to the exhibit. The nginx Pod is created, but the Pod never becomes Ready. The container starts and runs. What is the most likely reason?

A.The nginx:latest image does not exist.

B.The containerPort is not matching the actual port nginx listens on.

C.The liveness probe is failing because /healthz endpoint does not exist, causing the container to restart.

D.The readiness probe is failing because the root path is not returning 200.

AnswerC

The liveness probe expects /healthz to return 200, but nginx does not serve that path by default, so the probe fails and the container is restarted. This prevents the readiness probe from ever succeeding.

Why this answer

The liveness probe is configured to check the /healthz endpoint, but the default nginx container does not serve a /healthz endpoint. This causes the liveness probe to fail, and Kubernetes restarts the container according to the probe's failure threshold. Since the container keeps restarting, it never reaches the Ready state, even though the container starts and runs initially.

Exam trap

The KCNA exam often tests the distinction between liveness and readiness probes, and the trap here is that candidates assume a failing liveness probe only affects health checks, not the Pod's Ready status, when in fact repeated restarts prevent the Pod from ever becoming Ready.

How to eliminate wrong answers

Option A is wrong because if the nginx:latest image did not exist, the Pod would fail to pull the image and remain in ImagePullBackOff or ErrImagePull state, not start and run. Option B is wrong because the containerPort is a declaration for documentation and network policy; nginx listens on port 80 by default, and even if the port mismatched, the container would still start and become Ready as long as the probes pass. Option D is wrong because the readiness probe is checking the root path (/) which nginx serves by default with a 200 status, so it would pass; the issue is the liveness probe hitting a non-existent /healthz endpoint.

Practice this question →

264

MCQeasy

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

A.Annotations

B.Selectors

C.Namespaces

D.Labels

AnswerC

Namespaces partition resources within a cluster.

Why this answer

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

Practice this question →

265

MCQmedium

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

A.DaemonSet

B.Deployment

C.ReplicaSet

D.StatefulSet

AnswerB

Deployments manage ReplicaSets and provide rolling updates, rollbacks, and declarative updates for stateless applications.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

266

Multi-Selecthard

Which TWO statements about Namespaces are correct?

Select 2 answers

A.Resource names must be unique within a namespace

B.Namespaces provide network isolation by default

C.All Kubernetes resources are namespaced

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

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

AnswersA, D

Uniqueness is enforced within a namespace.

Why this answer

Kubernetes enforces that resource names must be unique within a namespace. This is a fundamental constraint: within a given namespace, you cannot have two resources of the same type (e.g., two Pods) with the same name. This uniqueness allows the API server to resolve resource references unambiguously when using namespaced resources.

Exam trap

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

Practice this question →

267

Multi-Selecthard

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

Select 2 answers

A.Deployments support rolling updates and rollbacks

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

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

D.Deployments manage the lifecycle of ReplicaSets

E.Deployments provide stable network identities for Pods

AnswersA, D

Deployments provide a declarative update strategy that supports rolling updates and rollbacks.

Why this answer

A is correct because Deployments provide a declarative update mechanism that supports rolling updates, where Pods are gradually replaced with new ones, and rollbacks, which revert the Deployment to a previous revision. This is achieved through the Deployment controller managing ReplicaSets, allowing seamless transitions between versions without downtime.

Exam trap

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

Practice this question →

268

Multi-Selectmedium

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

Select 2 answers

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

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

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

D.To improve application performance by reducing latency.

E.To store environment variables for containers.

AnswersA, C

NetworkPolicies can be scoped to Namespaces to control traffic flow.

Why this answer

Kubernetes NetworkPolicies are namespace-scoped resources that can restrict ingress and egress traffic between Pods in different Namespaces. By default, all Pods can communicate across Namespaces, but applying a NetworkPolicy with a podSelector and namespaceSelector allows you to enforce isolation. Option C is correct because Namespaces provide a logical boundary for resource names, preventing naming collisions when multiple teams or projects deploy objects with the same name within the same cluster.

Exam trap

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

Practice this question →

269

MCQhard

A pod named 'db' in the 'default' namespace cannot connect to another pod named 'cache' in the 'prod' namespace via DNS. The service 'cache-svc' exists in the 'prod' namespace. What DNS name should the 'db' pod use to reach the 'cache-svc' service?

A.cache-svc.default

B.cache-svc.prod

C.cache-svc.prod.svc.cluster.local

D.cache-svc.default.svc.cluster.local

AnswerC

The correct DNS format for a service in another namespace is <svc>.<ns>.svc.cluster.local.

Why this answer

Kubernetes DNS resolves services across namespaces using the format <service>.<namespace>.svc.cluster.local. Since the 'cache-svc' service is in the 'prod' namespace, the 'db' pod in the 'default' namespace must use 'cache-svc.prod.svc.cluster.local' to reach it. The default cluster domain is 'cluster.local', and the 'svc' subdomain is part of the standard DNS schema for services.

Exam trap

CNCF often tests the misconception that the namespace alone (e.g., 'cache-svc.prod') is sufficient for cross-namespace DNS resolution, but the full 'svc.cluster.local' suffix is mandatory for the cluster DNS to resolve the service correctly.

How to eliminate wrong answers

Option A is wrong because 'cache-svc.default' implies the service is in the 'default' namespace, but the service is actually in 'prod', and it omits the required 'svc.cluster.local' suffix. Option B is wrong because 'cache-svc.prod' is incomplete—it lacks the 'svc.cluster.local' suffix, so it would not be resolved by the cluster DNS server (CoreDNS/kube-dns). Option D is wrong because it places the service in the 'default' namespace (using 'default' instead of 'prod'), which does not match the actual namespace of the service.

Practice this question →

270

MCQmedium

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

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

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

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

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

AnswerD

This creates a ConfigMap with the file contents.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

271

MCQeasy

What is the primary purpose of Kubernetes?

A.To orchestrate containers across a cluster of machines

B.To provide a graphical user interface for managing containers

C.To replace Docker as a container runtime

D.To provide a virtual machine management platform

AnswerA

Kubernetes automates container deployment, scaling, and operations.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

272

MCQhard

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

A.The image registry credentials are missing

B.The liveness probe is misconfigured and killing the container

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

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

AnswerD

The exec error shows the binary is missing, likely due to a typo or wrong image.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

273

Multi-Selectmedium

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

Select 2 answers

A.Serving the Kubernetes API

B.Implementing network rules for Services

C.Scheduling pods to nodes

D.Running the node controller to monitor node health

E.Managing ReplicaSets to ensure the desired number of pods are running

AnswersD, E

The node controller periodically checks node status and responds to node failures.

Why this answer

The kube-controller-manager is a core control plane component that runs controller processes, including the node controller, which monitors node health by checking the NodeStatus and NodeLease objects. If a node becomes unreachable (e.g., the node controller fails to receive a heartbeat within the --node-monitor-grace-period, default 40 seconds), it marks the node as Unhealthy and eventually taints it to trigger pod eviction. This makes option D correct because the node controller is a built-in controller within the kube-controller-manager.

Exam trap

CNCF often tests the distinction between control plane components by listing overlapping responsibilities, so the trap here is confusing the kube-controller-manager's role in managing controllers (like the node controller and ReplicaSet controller) with the kube-scheduler's scheduling function or kube-proxy's network rule implementation.

Practice this question →

274

Multi-Selecthard

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

Select 2 answers

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

B.Check that the container runtime is working

C.Check the kube-apiserver status

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

E.Restart all nodes in the cluster

AnswersA, D

kube-proxy is responsible for implementing the Service abstraction via iptables or IPVS.

Why this answer

Kube-proxy is the component responsible for implementing the ClusterIP Service abstraction by managing iptables or IPVS rules on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the backend pods, making the Service unreachable from within the cluster.

Exam trap

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

Practice this question →

275

MCQmedium

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

A.kubectl get pods -n team-a

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

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

D.kubectl get pods --all-namespaces

AnswerA

This command lists all pods in the specified namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

276

MCQhard

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

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

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

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

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

AnswerC

The Deployment controller updates the ReplicaSet's .spec.replicas, and the ReplicaSet controller creates the pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

277

MCQeasy

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

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerD

The API server exposes the Kubernetes API and handles all administrative requests.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

278

MCQmedium

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

A.ConfigMap

B.Secret

C.ServiceAccount

D.PersistentVolume

AnswerA

ConfigMap is correct for non-sensitive configuration data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

279

MCQmedium

Which command creates a Deployment named 'nginx-deployment' from the image 'nginx:1.25' and exposes it on port 80?

A.kubectl create deployment nginx-deployment --image=nginx:1.25 --port=80

B.kubectl run nginx-deployment --image=nginx:1.25 --port=80

C.kubectl apply -f nginx-deployment.yaml

D.kubectl expose deployment nginx-deployment --type=ClusterIP

AnswerA

This creates a Deployment with the specified image and port exposure.

Why this answer

The `kubectl create deployment` command is the standard way to create a Deployment resource in Kubernetes. The `--image=nginx:1.25` flag specifies the container image, and the `--port=80` flag sets the container port in the pod template spec, which allows the Deployment to expose the container on port 80.

Exam trap

The trap here is that candidates confuse `kubectl run` with `kubectl create deployment`, as `kubectl run` can create a pod but not a Deployment in modern Kubernetes, and they may think the `--port` flag works with `kubectl run` when it does not.

How to eliminate wrong answers

Option B is wrong because `kubectl run` creates a Pod (or a Deployment only in older versions with specific flags), not a Deployment; it does not create a Deployment resource by default, and the `--port` flag is not a standard flag for `kubectl run` in current Kubernetes versions. Option C is wrong because `kubectl apply -f nginx-deployment.yaml` assumes a YAML manifest file already exists, but the question asks to create the Deployment from the image directly, not from a file. Option D is wrong because `kubectl expose deployment` creates a Service to expose an existing Deployment, but it does not create the Deployment itself; the Deployment must already exist.

Practice this question →

280

Multi-Selecthard

Which THREE statements about Kubernetes Services are correct?

Select 3 answers

A.A Service provides a stable IP address and DNS name for a set of Pods.

B.Services use label selectors to identify the target Pods.

C.A Service of type LoadBalancer can be used to expose an application externally.

D.A Service can only route traffic to Pods within the same namespace.

E.The default Service type is NodePort.

AnswersA, B, C

Services provide stable endpoints that decouple clients from individual Pod IPs.

Why this answer

A is correct because a Kubernetes Service provides a stable virtual IP address and a DNS name (via CoreDNS) that remains constant even as the underlying Pods are created, destroyed, or scaled. This decouples clients from the ephemeral nature of Pod IPs, ensuring reliable connectivity.

Exam trap

A common mistake is to assume that a Service can select Pods from any namespace, but in Kubernetes, a Service's label selector only matches Pods within the same namespace. Additionally, the default Service type is ClusterIP, not NodePort.

Practice this question →

281

MCQeasy

What is the purpose of a Service in Kubernetes?

A.To provide persistent storage volumes

B.To manage rolling updates of pods

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

D.To store configuration data as key-value pairs

AnswerC

This is the primary purpose of a Service.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

282

Multi-Selectmedium

Which two statements correctly describe etcd in a Kubernetes cluster?

Select 2 answers

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

B.It runs on every worker node

C.It manages network rules for Services

D.It implements the Kubernetes API

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

AnswersA, E

Correct.

Why this answer

etcd is a distributed, consistent key-value store used by Kubernetes to persist all cluster data, including configuration, state, and metadata. It is the single source of truth for the cluster, and the API server reads from and writes to it exclusively. Without etcd, the cluster cannot recover or maintain its desired state, making it a critical component.

Exam trap

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

Practice this question →

283

MCQhard

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

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

B.Use ConfigMap for both

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

D.Use Secret for both

AnswerA

Separating concerns: ConfigMap for non-sensitive, Secret for sensitive.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

284

MCQeasy

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

A.Service

B.Container

C.Pod

D.Node

AnswerC

A pod is the smallest deployable unit.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

285

MCQmedium

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

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta2

AnswerC

apps/v1 is the correct stable API version for Deployment.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

286

MCQmedium

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

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

B.The pod's image pull is failing.

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

D.The pod was evicted due to resource pressure.

AnswerC

Correct; insufficient memory prevents scheduling.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

287

MCQeasy

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

A.To create or update resources from a manifest

B.To view resource details

C.To delete resources

D.To execute commands inside a container

AnswerA

`kubectl apply` creates or updates resources declaratively.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

288

MCQhard

You have a Pod that is running but not receiving traffic. You suspect the associated Service's selector does not match the Pod labels. Which kubectl command would you use to check the Service's selector?

A.kubectl get endpoints <service-name>

B.kubectl describe service <service-name>

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

D.kubectl logs <pod-name>

AnswerB

This shows detailed information including the selector field.

Why this answer

`kubectl describe service <service-name>` displays the service's selector field under the 'Selector' section, allowing you to directly compare it with the Pod's labels. This is the most straightforward way to verify if the selector matches the Pod labels, which is essential for traffic routing.

Exam trap

CNCF often tests the distinction between checking the selector definition versus checking the resulting endpoints, so candidates may mistakenly choose `kubectl get endpoints` because it shows the current routing status, but it does not reveal the selector itself.

How to eliminate wrong answers

Option A is wrong because `kubectl get endpoints <service-name>` shows the current endpoints (Pod IPs) that the service is routing to, but it does not show the service's selector; it only reveals the result of the selector matching, not the selector itself. Option C is wrong because `kubectl get service <service-name> -o yaml` outputs the full service definition including the selector, but it is more verbose and less direct than `kubectl describe` for quickly checking the selector; however, it is not incorrect per se, but the question asks for the command to check the selector, and `describe` is the standard, concise method. Option D is wrong because `kubectl logs <pod-name>` retrieves the logs from the Pod's containers, which provides application-level output but no information about the service's selector or label matching.

Practice this question →

289

MCQhard

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

A.Use a resource request for SSD storage capacity

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

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

D.Add a toleration for a taint on SSD nodes

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

290

Multi-Selecteasy

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

Select 2 answers

A.Ensuring the desired number of pod replicas are running

B.Implementing service networking rules

C.Storing the cluster state

D.Detecting node failures and reacting

E.Scheduling pods onto nodes

AnswersA, D

The Replication Controller ensures the correct replica count.

Why this answer

The kube-controller-manager is responsible for running controller processes that regulate the state of the cluster. Option A is correct because the ReplicaSet controller, which runs inside the kube-controller-manager, continuously monitors the number of running pods and ensures it matches the desired replica count defined in the ReplicaSet or Deployment object. If a pod fails or is deleted, the controller creates a replacement to maintain the desired state.

Exam trap

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

Practice this question →

291

MCQmedium

You need to store a database password securely and make it available to a Pod as an environment variable. Which Kubernetes resource should you create?

A.Secret

B.PersistentVolume

C.ConfigMap

D.ServiceAccount

AnswerA

Secrets store sensitive data like passwords, tokens, and keys.

Why this answer

Secrets are designed to store sensitive data, such as passwords, and can be exposed to Pods via environment variables or volumes.

Practice this question →

292

MCQeasy

Which kubectl command would you use to view detailed information about a pod named 'web-pod' in the 'default' namespace?

A.kubectl describe pod web-pod

B.kubectl get pod web-pod

C.kubectl logs web-pod

D.kubectl exec web-pod -- env

AnswerA

This provides detailed status, events, and configuration.

Why this answer

The `kubectl describe pod web-pod` command retrieves detailed information about the specified pod, including its current status, events, container details, resource limits, and labels. This is the correct command for viewing comprehensive metadata and state information beyond the basic summary provided by `kubectl get`.

Exam trap

The trap here is that candidates confuse `kubectl get` with `kubectl describe`, assuming that `get` provides all details, when in fact `get` only shows a terse summary and `describe` is required for the full object dump and event history.

How to eliminate wrong answers

Option B is wrong because `kubectl get pod web-pod` only returns a concise summary of the pod's name, status, restarts, and age, not the detailed information requested. Option C is wrong because `kubectl logs web-pod` fetches the container's stdout/stderr logs, not the pod's configuration or status details. Option D is wrong because `kubectl exec web-pod -- env` runs the `env` command inside the pod's container to list environment variables, which is unrelated to viewing the pod's detailed metadata.

Practice this question →

293

MCQmedium

A pod is stuck in Pending state. Which of the following is the MOST likely reason?

A.There are insufficient resources on any available node

B.The pod is still being initialized

C.The container image is missing

D.The pod has crashed and is restarting

AnswerA

The scheduler cannot find a node with enough CPU/memory/ports.

Why this answer

Pending means the pod has not been scheduled to a node, often due to insufficient resources or node constraints.

Practice this question →

294

MCQeasy

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

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerC

Why this answer

The kube-controller-manager is the control plane component that runs controller processes, which are control loops that watch the shared state of the cluster through the kube-apiserver and make changes to bring the current state closer to the desired state. It bundles together multiple controllers (e.g., Node Controller, Replication Controller, Endpoint Controller, Service Account Controller) that each handle a specific aspect of cluster management, ensuring the cluster's actual state matches the user-defined desired state.

Exam trap

A common misconception is that etcd is responsible for maintaining the desired state because it stores the desired state. However, etcd is only a passive data store, while the kube-controller-manager is the active component that performs the actual reconciliation to enforce that state.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning newly created pods to nodes based on resource availability, policies, and constraints, not for maintaining the desired state via controllers. Option B is wrong because etcd is a distributed key-value store that serves as the cluster's backing store for all cluster data, but it does not run controllers or actively reconcile state; it only stores and retrieves the desired and current state. Option D is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the Kubernetes API, handles authentication, authorization, and validation of API requests, but it does not run the controller loops that enforce desired state.

Practice this question →

295

MCQmedium

Which of the following is a way to provide configuration data to a pod without baking it into the container image?

A.Using a ConfigMap

B.Using an annotation

C.Using a Secret

D.Using a PersistentVolume

AnswerA

ConfigMaps store configuration data that can be consumed by pods as environment variables or files.

Why this answer

A ConfigMap is a Kubernetes API object used to decouple configuration artifacts from container images, allowing you to inject configuration data (e.g., environment variables, command-line arguments, or configuration files) into pods without rebuilding the image. This is the standard way to provide non-sensitive configuration data to pods at runtime, as defined in the Kubernetes documentation.

Exam trap

Candidates often select Secret because they think all configuration data should be secure, but ConfigMap is intended for non-sensitive data.

How to eliminate wrong answers

Option B is wrong because an annotation is metadata attached to a Kubernetes object (like a pod) for non-identifying information, such as tooling hints or build details; it is not designed to be consumed as configuration data by the pod's containers. Option C is wrong because while a Secret can provide configuration data (e.g., passwords, tokens), it is specifically intended for sensitive information and is not the general-purpose mechanism for non-sensitive configuration; the question asks for a way to provide configuration data without baking it into the image, and both ConfigMap and Secret can do that, but ConfigMap is the correct answer for non-sensitive data. Option D is wrong because a PersistentVolume is a storage resource that provides persistent storage to pods via a PersistentVolumeClaim, not a mechanism for injecting configuration data like environment variables or files.

Practice this question →

296

MCQhard

A user reports that they cannot connect to a Service from within the cluster. The Service is of type ClusterIP. Running 'kubectl get endpoints service-name' shows no endpoints. What is the most likely cause?

A.The Service is not associated with a namespace

B.The Service is exposed on the wrong port

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

D.The Service's pod selector does not match any running pods

AnswerD

Endpoints are created by matching pods with the selector; if none match, endpoints are empty.

Why this answer

If endpoints are empty, the Service selector does not match any pods, or the pods are not ready.

Practice this question →

297

MCQmedium

You need to store a database password securely and expose it to a Pod as an environment variable. Which Kubernetes resource should you use?

A.Service

B.PersistentVolumeClaim

C.Secret

D.ConfigMap

AnswerC

Secrets store sensitive data, such as passwords, and can be injected into Pods as environment variables or volumes.

Why this answer

A Secret is the correct Kubernetes resource for storing sensitive data like database passwords because it encodes the value in base64 and can be injected into a Pod as an environment variable. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when etcd is configured accordingly.

Exam trap

Many candidates mistakenly assume that ConfigMaps are suitable for all configuration data, including passwords. However, Secrets are specifically designed for sensitive information and support optional encryption at rest, whereas ConfigMaps store data in plain text.

How to eliminate wrong answers

Option A is wrong because a Service is a network abstraction that exposes a set of Pods as a stable endpoint, not a storage mechanism for sensitive data. Option B is wrong because a PersistentVolumeClaim is used to request persistent storage volumes for Pods, not for storing small secret values like passwords. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plain text and is not intended for secrets; using it for a password would expose the value in clear text.

Practice this question →

298

MCQmedium

A developer needs to deploy a stateless application with three replicas and ensure that updates are rolled out with zero downtime. Which Kubernetes resource is most appropriate?

A.Deployment

B.StatefulSet

C.Job

D.DaemonSet

AnswerA

Deployment manages ReplicaSets and supports rolling updates.

Why this answer

A Deployment is the correct resource because it manages a ReplicaSet to ensure the desired number of pod replicas (three) are running, and it supports rolling updates with configurable strategies (e.g., maxSurge and maxUnavailable) to achieve zero-downtime updates. Stateless applications are ideal for Deployments since pods are interchangeable and can be replaced without data loss.

Exam trap

The trap here is that candidates might choose StatefulSet because they associate 'replicas' with stateful workloads, but the question explicitly states 'stateless application,' making Deployment the correct choice for rolling updates with zero downtime.

How to eliminate wrong answers

Option B is wrong because StatefulSet is designed for stateful applications requiring stable, unique network identities and persistent storage, not for stateless apps, and its rolling update behavior is more conservative (e.g., pod ordinal ordering) but still can achieve zero downtime; however, it is not the most appropriate for a stateless app. Option C is wrong because a Job is intended for batch or one-time tasks that run to completion, not for continuously running stateless applications with multiple replicas or rolling updates. Option D is wrong because a DaemonSet ensures one pod per node (or a subset) for cluster-wide services like logging or monitoring, not for deploying a specific number of replicas (three) across the cluster.

Practice this question →

299

MCQeasy

Which kubectl command would you use to view the detailed state of a pod named 'web-pod' in the 'default' namespace?

A.kubectl logs web-pod

B.kubectl get pod web-pod

C.kubectl describe pod web-pod

D.kubectl exec web-pod -- /bin/sh

AnswerC

Correct. 'kubectl describe' gives detailed information including events.

Why this answer

`kubectl describe pod web-pod` retrieves a detailed, multi-section view of the pod's current state, including events, conditions, container statuses, and resource usage. This command is specifically designed for deep inspection of a Kubernetes resource, unlike `kubectl get` which shows a summary, or `kubectl logs` which shows container output.

Exam trap

The trap here is that candidates confuse `kubectl get` (which shows a summary) with `kubectl describe` (which shows detailed state), especially when the question asks for 'detailed state' — CNCF often tests this distinction by making the summary command look plausible at first glance.

How to eliminate wrong answers

Option A is wrong because `kubectl logs web-pod` fetches the stdout/stderr logs from the pod's containers, not the pod's detailed state or configuration. Option B is wrong because `kubectl get pod web-pod` outputs a concise, one-line summary of the pod (name, ready status, restarts, age) without the detailed events, conditions, or container-level information. Option D is wrong because `kubectl exec web-pod -- /bin/sh` opens an interactive shell inside the pod's primary container, which is used for debugging or running commands inside the container, not for viewing the pod's state.

Practice this question →

300

MCQeasy

A developer creates a pod that needs to securely access a database password stored in the cluster. Which Kubernetes resource should be used to inject the password as an environment variable?

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolumeClaim

AnswerA

Correct; Secrets store sensitive data like passwords.

Why this answer

A Secret is the correct Kubernetes resource for injecting sensitive data like a database password into a Pod as an environment variable. Secrets store base64-encoded data and are designed specifically for confidential information, unlike ConfigMaps which store non-sensitive configuration. When mounted as environment variables, Secrets ensure the password is not exposed in plaintext in the Pod specification or image layers.

Exam trap

CNCF often tests the distinction between ConfigMaps and Secrets, trapping candidates who assume ConfigMaps can handle sensitive data because both resources can inject environment variables, but Secrets are the only secure choice for passwords.

How to eliminate wrong answers

Option B (ServiceAccount) is wrong because a ServiceAccount provides an identity for Pods to authenticate to the Kubernetes API server, not a mechanism to store or inject sensitive data like passwords. Option C (ConfigMap) is wrong because ConfigMaps are intended for non-sensitive configuration data; storing a password in a ConfigMap would violate security best practices and expose the secret in plaintext. Option D (PersistentVolumeClaim) is wrong because a PVC is used to request storage resources from a PersistentVolume, not to inject environment variables or store secrets.

Practice this question →