CCNA Kcna Kubernetes Fundamentals Questions — Page 2 of 5

MCQhard

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

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

B.The container will be restarted automatically

C.The Pod will be evicted from the node

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

AnswerB

Liveness probe failure triggers container restart.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.The Service selector does not match

B.The Deployment name is misspelled

C.There are insufficient resources on the nodes

D.The container image is invalid

AnswerC

Pending often indicates insufficient CPU or memory to schedule the pod.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kube-scheduler

B.kube-proxy

C.container runtime

D.kubelet

AnswerD

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

A.Insufficient CPU or memory resources available in the cluster

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

C.The container runtime is not functioning on the node

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

AnswerC

A non-functioning container runtime does not prevent scheduling; it affects pod execution after scheduling. Therefore, it is NOT a common cause of prolonged Pending state.

Why this answer

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

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

Which of the following is a correct way to assign a pod to a specific node using a nodeSelector?

A.spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: ...

B.spec: nodeName: "node1"

C.spec: nodeSelector: [disktype: ssd]

D.spec: nodeSelector: disktype: ssd

AnswerD

This is the correct syntax for nodeSelector.

Why this answer

`nodeSelector` is a simple pod scheduling constraint that uses a key-value pair in the `spec.nodeSelector` field to match node labels. The correct YAML syntax is `spec: nodeSelector: disktype: ssd`, where `disktype` is the label key and `ssd` is the value, ensuring the pod is scheduled only on nodes with that exact label.

Exam trap

The trap here is that candidates confuse the YAML syntax for `nodeSelector` (a map) with that of `nodeAffinity` or `nodeName`, or incorrectly use an array format like `[disktype: ssd]` instead of the correct key-value pair.

How to eliminate wrong answers

Option A is wrong because it describes `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution`, which is a more advanced scheduling feature using `nodeSelectorTerms`, not the simpler `nodeSelector` field. Option B is wrong because `spec.nodeName` directly assigns a pod to a specific node by name, bypassing the scheduler entirely, which is not the same as using a `nodeSelector` to match labels. Option C is wrong because `nodeSelector` expects a map (key-value pair), not a list; the syntax `[disktype: ssd]` is an array format, which is invalid for `nodeSelector`.

Practice this question →

Multi-Selecthard

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

Select 3 answers

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

B.Mount a ConfigMap as a volume

C.Mount a Secret as a volume

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

E.Use environment variables from a ConfigMap

AnswersB, C, E

ConfigMaps can be mounted as files in a pod.

Why this answer

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

Exam trap

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

Practice this question →

MCQeasy

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

A.etcd

B.kube-apiserver

C.kube-scheduler

D.kube-controller-manager

AnswerC

The kube-scheduler watches for newly created pods and assigns them to nodes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

Which THREE fields are required in a Kubernetes manifest YAML file?

Select 3 answers

A.kind

B.metadata

C.status

D.spec

E.apiVersion

AnswersA, B, E

Defines the type of Kubernetes resource.

Why this answer

The 'kind' field is required because it tells Kubernetes which type of object to create (e.g., Pod, Deployment, Service). Without it, the API server cannot route the manifest to the correct resource handler. It must be a valid Kubernetes resource kind from the core API or a custom resource definition.

Exam trap

CNCF often tests the misconception that 'spec' is always required, but the KCNA exam expects you to know that status is never user-supplied and that spec is optional for certain built-in resources like Namespace or LimitRange.

Practice this question →

MCQmedium

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

A.ConfigMap

B.Ingress

C.Service

D.Deployment

AnswerC

Services provide stable networking endpoints for pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

A Deployment is rolling out a new version. The rollout has stalled, and 'kubectl rollout status deployment/myapp' shows 'Waiting for deployment rollout to finish: 2 out of 5 new replicas have been updated...'. The Deployment's spec.strategy.rollingUpdate.maxUnavailable is set to 25% and maxSurge is 25%. What is the maximum number of Pods that could be unavailable during this rollout?

A.1

B.3

C.2

D.0

AnswerC

maxUnavailable=25% of 5 = 1.25, so up to 2 Pods can be unavailable.

Why this answer

With maxUnavailable=25% and maxSurge=25%, the maximum number of unavailable Pods during a rolling update is calculated as the ceiling of 25% of the desired replicas (5), which is 2. This means up to 2 Pods can be unavailable at any time, ensuring the rollout can proceed while maintaining availability.

Exam trap

The trap here is that candidates often forget that maxUnavailable is calculated as a percentage of the desired replicas and rounded up, leading them to incorrectly calculate 25% of 5 as 1.25 and round down to 1, or they misinterpret the rollout status as showing only 2 Pods are updated, assuming that is the maximum unavailable, when in fact the maximum is determined by the strategy, not the current state.

How to eliminate wrong answers

Option A is wrong because 1 is less than the calculated maximum of 2 (ceiling of 25% of 5), and the rollout status shows 2 new replicas are updated, indicating at least 2 Pods are unavailable. Option B is wrong because 3 exceeds the maximum allowed by the rolling update strategy; maxUnavailable=25% limits unavailable Pods to 2, and having 3 unavailable would violate the Deployment's availability guarantee. Option D is wrong because 0 is not possible during a rollout; the rollout status explicitly shows 2 out of 5 new replicas are updated, meaning at least 2 old Pods are being terminated and are unavailable.

Practice this question →

MCQmedium

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

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

B.The application inside the container crashed.

C.The container image is missing.

D.The Service does not have any endpoints.

AnswerA

If no node has sufficient resources to satisfy the Pod's requests, the scheduler cannot place it, leaving it Pending.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod?

Select 2 answers

A.volumes and volumeMounts

B.env.value

C.env.valueFrom.secretKeyRef

D.env.valueFrom.configMapKeyRef

E.envFrom

AnswersD, E

Correct. env.valueFrom.configMapKeyRef allows referencing a specific key from a ConfigMap and exposing it as an environment variable.

Why this answer

Environment variables from a ConfigMap can be exposed to a pod using envFrom to inject all key-value pairs as environment variables, or using env.valueFrom.configMapKeyRef to inject a specific key as an environment variable. Using volumes and volumeMounts mounts the ConfigMap as files in the filesystem, not as environment variables. Option B (env.value) is for static values, not references.

Option C (secretKeyRef) is for Secrets, not ConfigMaps.

Exam trap

CNCF often tests the distinction between `configMapKeyRef` and `secretKeyRef`, expecting candidates to know that `secretKeyRef` is for Secrets only, not ConfigMaps, and that `env.value` is for static values, not dynamic references.

Practice this question →

MCQmedium

You need to provide an application with configuration data that does not change often and should not be baked into the container image. Which Kubernetes resource should you use?

A.Secret

B.PersistentVolumeClaim

C.ConfigMap

D.ServiceAccount

AnswerC

Why this answer

ConfigMap is the correct Kubernetes resource for providing configuration data that does not change often and should not be baked into the container image. It decouples configuration artifacts from image content, allowing you to update configuration without rebuilding images, and supports injection via environment variables, command-line arguments, or volume mounts.

Exam trap

The trap here is that candidates confuse ConfigMap with Secret, assuming all configuration must be secret, or they mistakenly think PersistentVolumeClaim can store configuration files, when in fact ConfigMap is the correct resource for non-sensitive, frequently updated configuration data.

How to eliminate wrong answers

Option A is wrong because Secrets are specifically designed for sensitive data (e.g., passwords, tokens, SSH keys) and are base64-encoded, not for general configuration data that does not change often. Option B is wrong because PersistentVolumeClaim is used to request persistent storage volumes for stateful workloads, not for injecting configuration data into containers. Option D is wrong because ServiceAccount provides an identity for Pods to authenticate with the Kubernetes API server, not for storing or delivering configuration data.

Practice this question →

MCQeasy

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

A.kube-controller-manager

B.kube-apiserver

C.etcd

D.kube-scheduler

AnswerB

The API server is the entry point for all REST API calls.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative tasks and API requests. It exposes the Kubernetes API (over HTTPS), validates and processes RESTful operations (e.g., kubectl commands, pod creation), and serves as the communication gateway between internal components (e.g., etcd, scheduler, controller-manager) and external clients. Without the API server, no administrative action or resource change can be initiated in the cluster.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

B.Both ConfigMaps and Secrets can be mounted as volumes

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

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

AnswerB

Both resource types support volume mounting and environment variable injection.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

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

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

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

AnswerA

This is the default rolling update behavior: a new ReplicaSet is created, and pods are gradually transitioned.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.Service

B.Deployment

C.ConfigMap

D.Pod

AnswerA

Services provide stable IPs and DNS names with load balancing across pods.

Why this answer

A Service is the correct Kubernetes object because it provides a stable virtual IP (ClusterIP) and DNS name that remains constant even as pods are created or destroyed. It automatically load-balances traffic across the set of pods matching its label selector using iptables or IPVS rules, ensuring reliable network endpoints for clients.

Exam trap

The trap here is that candidates often confuse a Deployment's ability to manage replicas with providing network access, forgetting that only a Service creates a stable, load-balanced network abstraction over pods.

How to eliminate wrong answers

Option B (Deployment) is wrong because a Deployment manages pod replicas and rolling updates, but it does not expose a stable network endpoint or perform load balancing; it relies on a Service for that. Option C (ConfigMap) is wrong because it is used to inject configuration data (key-value pairs) into pods as environment variables or files, not to provide network endpoints or load balancing. Option D (Pod) is wrong because a Pod has a dynamic IP that changes on restart, and it cannot provide stable endpoints or load balancing across multiple pods; a Service abstracts over pods to solve this.

Practice this question →

Multi-Selecthard

Which THREE of the following are required for a Kubernetes pod to be considered healthy and ready to serve traffic?

Select 3 answers

A.The startup probe has succeeded.

B.The container is in the Running state.

C.The pod has at least one endpoint in its Service's endpoints list.

D.The readiness probe has succeeded.

E.The liveness probe has succeeded.

AnswersA, B, D

Startup probe indicates the application has started.

Why this answer

A startup probe must succeed before the kubelet considers the container started. Until the startup probe succeeds, the readiness and liveness probes are not active, so the pod cannot be marked healthy or ready. This is defined in the Kubernetes API for startup probes, which delay the start of other probes until the application has initialized.

Exam trap

The KCNA exam often tests the distinction between liveness and readiness probes, and the trap here is that candidates confuse a successful liveness probe (which only indicates the container is alive) with the readiness probe (which specifically controls traffic routing), leading them to incorrectly select option E.

Practice this question →

MCQhard

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

A.OnDelete

B.BlueGreen

C.RollingUpdate

D.Recreate

AnswerC

RollingUpdate gradually replaces Pods; old ones are terminated as new ones become ready.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQmedium

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

A.Deployment

B.Node

C.Container

D.Pod

AnswerD

Pod is the smallest deployable unit.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

Which of the following kubectl commands would you use to update a Deployment's image to 'nginx:1.21' and record the change in the rollout history?

A.kubectl edit deployment nginx --image=nginx:1.21

B.kubectl set image deployment/nginx nginx=nginx:1.21

C.kubectl set image deployment/nginx nginx=nginx:1.21 --record

D.kubectl patch deployment nginx -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.21"}]}}}}' --record

AnswerC

This updates the image and records the change in the rollout history.

Why this answer

`kubectl set image deployment/nginx nginx=nginx:1.21 --record` updates the container image of the specified deployment and, with the `--record` flag, annotates the change in the rollout history (stored in the `kubernetes.io/change-cause` annotation). This allows you to later inspect the change with `kubectl rollout history deployment/nginx`.

Exam trap

CNCF often tests the `--record` flag as a subtle requirement; candidates may pick option B because it correctly updates the image but forget that the question explicitly asks to record the change in the rollout history.

How to eliminate wrong answers

Option A is wrong because `kubectl edit deployment nginx --image=nginx:1.21` is invalid syntax; `kubectl edit` opens an editor for the resource and does not accept an `--image` flag. Option B is wrong because `kubectl set image deployment/nginx nginx=nginx:1.21` updates the image but does not include the `--record` flag, so the change will not be recorded in the rollout history. Option D is wrong because while `kubectl patch` with the correct JSON patch can update the image and `--record` records it, the question specifically asks for a command to update the image and record the change; option C is the most direct and standard command for this purpose, and option D is unnecessarily complex and less idiomatic for a simple image update.

Practice this question →

MCQeasy

What is the primary purpose of a Namespace in Kubernetes?

A.To set resource quotas for the entire cluster

B.To define network policies for pods

C.To manage node affinity rules

D.To isolate resources and provide a scope for names

AnswerD

Namespaces partition resources into logically named groups.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQeasy

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

A.kubelet

B.kube-proxy

C.kube-scheduler

D.kube-controller-manager

AnswerA

The kubelet runs on each node and ensures containers are healthy.

Why this answer

The kubelet is the primary node agent that runs on every worker node in a Kubernetes cluster. It receives PodSpec definitions (via the API server or a file) and ensures that the containers described in those PodSpecs are running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) to start, stop, and monitor containers, and it reports the node and pod status back to the control plane.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

MCQhard

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

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

B.The Service's endpoint slices

C.kube-proxy on the nodes

D.CoreDNS pods in the kube-system namespace

AnswerD

CoreDNS provides DNS resolution for cluster services.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

100

Multi-Selectmedium

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

Select 2 answers

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

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

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

D.It exposes the Kubernetes API for external access.

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

AnswersA, E

etcd is the backing store for all cluster data.

Why this answer

Etcd is the primary data store for all Kubernetes cluster state, including the configuration and status of every Kubernetes object (Pods, Services, Deployments, etc.). It stores this information as key-value pairs, and the Kubernetes API server is the only component that reads from and writes to etcd directly. Without etcd, the cluster would have no persistent record of its desired or current state.

Exam trap

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

Practice this question →

101

Multi-Selectmedium

Which THREE of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Select 3 answers

A.ClusterIP

B.NodePort

C.LoadBalancer

D.Ingress

E.ExternalName

AnswersA, B, C

ClusterIP exposes the service on a cluster-internal IP; it is the default type.

Why this answer

A ClusterIP service exposes the set of pods on a cluster-internal IP address, making it reachable only from within the cluster. This is the default service type in Kubernetes and is valid for internal communication between workloads. It does not provide external access, but it is a core method for exposing pods as a network service.

Exam trap

CNCF often tests the distinction between service types (ClusterIP, NodePort, LoadBalancer) and other networking objects like Ingress or ExternalName, trapping candidates who think Ingress is a service type or that ExternalName exposes pods.

Practice this question →

102

Drag & Dropmedium

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

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

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

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

Practice this question →

103

MCQmedium

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

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

B.The kube-scheduler is not running

C.The container runtime is not installed on any node

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

AnswerA

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

104

MCQmedium

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

A.kube-proxy

B.kube-scheduler

C.kubelet

D.container runtime

AnswerC

The kubelet is the node agent that manages pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

105

MCQmedium

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

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

B.To check if the container has started successfully

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

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

AnswerD

Liveness probes indicate whether the container is alive.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

106

MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Objects in different namespaces cannot communicate with each other

B.Namespaces allow you to divide cluster resources between multiple users

C.Namespaces are global across all clusters

D.Namespaces provide network isolation by default

AnswerB

Namespaces enable resource quotas and RBAC to separate teams.

Why this answer

Kubernetes Namespaces 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 (e.g., CPU, memory, storage) among multiple users via ResourceQuotas and Role-Based Access Control (RBAC), ensuring isolation of resource usage without requiring separate physical clusters.

Exam trap

A common misconception is that namespaces provide automatic network isolation; however, network isolation requires explicit NetworkPolicy objects, and namespaces only offer logical resource partitioning.

How to eliminate wrong answers

Option A is wrong because objects in different namespaces can communicate with each other by default via DNS (e.g., <service>.<namespace>.svc.cluster.local) or direct IP, unless explicitly restricted by NetworkPolicies. Option C is wrong because namespaces are scoped to a single Kubernetes cluster; they are not global across clusters, and each cluster has its own independent set of namespaces. Option D is wrong because namespaces do not provide network isolation by default; network isolation requires explicit NetworkPolicy resources that define ingress/egress rules, and without them, pods in different namespaces can communicate freely.

Practice this question →

107

Multi-Selecthard

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

Select 2 answers

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

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

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

D.Run 'kubectl rollout undo deployment/myapp'

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

AnswersA, E

This command updates the container image and triggers a rolling update.

Why this answer

'kubectl set image deployment/myapp myapp=myapp:v2' directly updates the container image in the Deployment's pod template, which triggers a rolling update by default. The Deployment controller then creates a new ReplicaSet with the updated image and gradually scales it up while scaling down the old ReplicaSet, ensuring zero downtime.

Exam trap

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

Practice this question →

108

Multi-Selectmedium

Which THREE of the following are valid Kubernetes resource types?

Select 3 answers

A.DockerImage

B.Deployment

C.ConfigMap

D.VirtualMachine

E.Service

AnswersB, C, E

A Deployment is a standard resource.

Why this answer

Deployment is a core Kubernetes resource that manages the lifecycle of Pods and ReplicaSets, providing declarative updates, scaling, and rollback capabilities. It is one of the most commonly used workload resources in Kubernetes, making option B correct.

Exam trap

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

Practice this question →

109

MCQmedium

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

A.spec.volumes

B.spec.containers[].volumeMounts

C.spec.containers[].envFrom

D.spec.containers[].env

AnswerC

envFrom takes a list of configMapRef or secretRef to populate environment variables.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

110

MCQmedium

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

A.ReplicaSet

B.Job

C.ReplicationController

D.DaemonSet

AnswerA

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

111

MCQmedium

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

A.spec.replicas

B.spec.selector

C.spec.minReadySeconds

D.spec.template

AnswerA

spec.replicas sets the desired number of pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

112

MCQmedium

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

A.Ingress

B.Service

C.PersistentVolumeClaim

D.ConfigMap

AnswerB

Services provide stable endpoints for Pod communication.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

113

MCQmedium

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

A.PersistentVolume

B.ConfigMap

C.ServiceAccount

D.Secret

AnswerD

Secret is intended for sensitive data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

114

MCQmedium

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

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

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

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

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

AnswerD

Requests guarantee the minimum; limits cap the maximum. If memory exceeds limits, the pod is OOMKilled and restarted.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

115

MCQmedium

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

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

B.The Deployment's YAML has a syntax error

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

D.The kubelet on the node is not running

AnswerA

If nodes lack sufficient resources, new pods remain Pending until resources become available or are released.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

116

Multi-Selectmedium

Which two of the following are valid ways to expose a Deployment externally to the internet? (Select TWO)

Select 2 answers

A.Create a Service of type ClusterIP

B.Create an Ingress resource

C.Create a Service of type LoadBalancer

D.Create a Headless Service

E.Create a Service of type NodePort

AnswersC, E

LoadBalancer provisions an external load balancer and assigns a public IP.

Why this answer

A Service of type LoadBalancer provisions an external load balancer (e.g., in cloud environments like AWS, GCP, or Azure) that assigns a public IP or DNS name, making the Deployment directly accessible from the internet. This is a standard method for exposing services externally in Kubernetes.

Exam trap

The trap here is that candidates often confuse Ingress as a standalone external exposure method, forgetting that Ingress requires a backing Service (typically NodePort or LoadBalancer) to actually route traffic from the internet.

Practice this question →

117

MCQhard

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

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

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

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

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

AnswerC

CPU above limit -> throttled; memory below limit -> no OOM kill.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

118

MCQhard

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

A.All nodes have taints that the pod cannot tolerate

B.The pod's liveness probe is failing

C.The container image is not found

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

AnswerD

The error indicates no node has enough available memory.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

119

MCQhard

A DevOps engineer wants to ensure that a critical application pod is rescheduled on a different node if its current node fails. The pod should be scheduled with a preference for nodes in a specific availability zone but can run elsewhere if needed. Which scheduling mechanism should be used?

A.Use a StatefulSet with podAntiAffinity.

B.Use a Deployment with a preferred nodeAffinity rule.

C.Run a static pod defined in the kubelet configuration.

D.Create a DaemonSet with a nodeSelector for the zone.

AnswerB

Correct; Deployment ensures rescheduling via ReplicaSet, nodeAffinity provides preference.

Why this answer

A Deployment with a preferred nodeAffinity rule is correct because it allows the pod to be rescheduled on a different node if the current node fails, while expressing a preference for nodes in a specific availability zone. The 'preferred' (soft) rule ensures scheduling flexibility—the pod can run elsewhere if no zone-matching nodes are available—which aligns with the requirement for high availability without strict zone constraints.

Exam trap

The trap here is that candidates confuse 'preferred' (soft) nodeAffinity with 'required' (hard) nodeAffinity, or mistakenly think DaemonSets or StatefulSets are needed for node failure recovery, when a simple Deployment with a soft scheduling preference is the correct mechanism for zone-aware rescheduling.

How to eliminate wrong answers

Option A is wrong because a StatefulSet with podAntiAffinity controls pod placement relative to other pods (e.g., spreading replicas across nodes), not rescheduling behavior after node failure, and does not express zone preference. Option C is wrong because a static pod is managed directly by the kubelet on a specific node and cannot be rescheduled to a different node if that node fails—it is tied to the node's lifecycle. Option D is wrong because a DaemonSet runs exactly one pod per node by default, which is not suitable for a single critical application pod, and nodeSelector enforces a hard constraint (not a preference) that would prevent scheduling if no zone-matching nodes exist.

Practice this question →

120

MCQhard

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

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

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

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

D.kubectl attach pod-name

AnswerC

Executes 'cat' inside the container to display the file.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

121

Multi-Selecthard

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

Select 3 answers

A.etcd

B.kube-apiserver

C.kube-proxy

D.kube-controller-manager

E.kubelet

AnswersA, B, D

etcd stores cluster state.

Why this answer

etcd is a consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. It stores the entire cluster state, including configuration, secrets, and metadata, and is a core component of the control plane because the API server reads from and writes to it to maintain cluster integrity.

Exam trap

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

Practice this question →

122

MCQeasy

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

A.kube-controller-manager

B.kube-apiserver

C.kube-scheduler

D.etcd

AnswerA

The controller manager runs controllers (e.g., replication controller) to ensure the current state matches the desired state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

123

MCQhard

An application requires a unique identifier per replica, stored in an environment variable. Which Kubernetes resource should be used to inject this identifier into each pod without manual updates?

A.Deployment with pod anti-affinity to schedule each pod on a different node.

B.StatefulSet with an environment variable derived from the pod name.

C.DaemonSet with a node name environment variable.

D.Job with a completion index environment variable.

AnswerB

StatefulSet pods have stable, unique names (e.g., myapp-0).

Why this answer

A StatefulSet provides stable, unique network identities and ordered pod naming (e.g., pod-0, pod-1). The pod name can be exposed as an environment variable using the Downward API or Kubernetes hostname field, giving each replica a unique identifier without manual updates. Deployments create identical pods with no ordering, DaemonSets run one pod per node, and Jobs are for batch processing, so only a StatefulSet meets the requirement.

Practice this question →

124

Multi-Selectmedium

Which TWO components are part of the Kubernetes control plane?

Select 2 answers

A.kube-proxy

B.kubelet

C.etcd

D.kube-apiserver

E.container runtime

AnswersC, D

etcd is the control plane's key-value store.

Why this answer

C (etcd) is correct because it is the distributed key-value store that holds all cluster data, including configuration, state, and metadata. D (kube-apiserver) is correct because it is the front-end for the control plane, exposing the Kubernetes API and handling all RESTful requests for cluster operations.

Exam trap

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

Practice this question →

125

MCQmedium

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

A.No node meets the requested CPU or memory resources

B.The application crashed due to a bug

C.The container image is missing

D.The Pod has been deleted

AnswerA

Insufficient resources on any node can cause Pending state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

126

Multi-Selectmedium

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

Select 2 answers

A.Support for stateful workloads

B.Declarative scaling

C.Direct access to pod IP addresses

D.Automatic rolling updates and rollbacks

E.Ability to run a pod on every node

AnswersB, D

Deployments allow you to declaratively set replica count.

Why this answer

Deployments provide a higher-level abstraction that manages ReplicaSets, enabling declarative scaling by simply updating the `replicas` field in the Deployment manifest. This allows Kubernetes to automatically adjust the number of pods without manual ReplicaSet edits, ensuring the desired state is maintained.

Exam trap

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

Practice this question →

127

MCQeasy

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

A.To check resource usage like CPU and memory

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

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

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

AnswerB

Correct. Liveness probes restart containers that become unresponsive.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

128

MCQhard

A StatefulSet named 'web' with 3 replicas is deployed in the 'production' namespace. The first two pods are running, but the third pod 'web-2' is pending with the error shown. What is the most likely cause?

A.The StatefulSet requires a headless Service that does not exist

B.The pod anti-affinity rule prevents more than one pod per node, and there are only 3 nodes

C.The pod has a resource request that cannot be satisfied by any node

D.There are not enough nodes in the cluster to schedule the third pod

AnswerB

The scheduler cannot place web-2 because all nodes already have a pod from the same set.

Why this answer

The error indicates that the third pod 'web-2' is pending due to a scheduling conflict. Pod anti-affinity rules, when configured with a 'requiredDuringSchedulingIgnoredDuringExecution' policy, prevent more than one pod from the same StatefulSet from being scheduled on the same node. With only 3 nodes available and the first two pods already occupying distinct nodes, the third pod cannot be placed, causing it to remain pending.

Exam trap

The KCNA exam often tests the distinction between resource constraints and scheduling constraints (like anti-affinity), leading candidates to mistakenly choose 'not enough nodes' when the real issue is a rule that prevents using all available nodes.

How to eliminate wrong answers

Option A is wrong because a headless Service is required for stable network identities in a StatefulSet, but its absence would cause DNS resolution failures, not a scheduling/pending error. Option C is wrong because resource requests that cannot be satisfied would produce an 'Insufficient cpu' or 'Insufficient memory' event, not a generic pending error tied to node count. Option D is wrong because the cluster has exactly 3 nodes, which matches the replica count; the issue is not the number of nodes but the anti-affinity rule preventing co-location on the same node.

Practice this question →

129

MCQmedium

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

A.StatefulSet

B.Job

C.Deployment

D.DaemonSet

AnswerB

Jobs run Pods that perform a task and then terminate.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

130

MCQeasy

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

A.StatefulSet with a headless Service

B.Ingress resource without a Service

C.Service of type ClusterIP

D.Service of type LoadBalancer

AnswerD

LoadBalancer exposes the service externally and provides load balancing.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

131

MCQmedium

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

A.kubectl get pods

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

C.kubectl describe pod <pod-name>

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

AnswerB

Shows logs from the previous container instance, useful for crash logs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

132

MCQhard

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

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

B.Use a ConfigMap mounted as a volume without subPath

C.Use a PersistentVolumeClaim to store the configuration

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

AnswerB

When mounted as a volume without subPath, the files are updated via symlinks, and the application can read the new content if it watches for changes.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

133

MCQeasy

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

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerC

Correct. It runs controller processes like node controller, replication controller, etc.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

134

MCQeasy

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

A.Deployment

B.Service

C.Container

D.Pod

AnswerD

A Pod encapsulates one or more containers, storage, and network.

Why this answer

The Pod is the smallest and simplest unit in the Kubernetes object model, representing a single instance of a running process in the cluster. A Pod encapsulates one or more containers, shared storage, and a unique cluster IP, and it is the atomic unit of scheduling, scaling, and management. Deployments and Services are higher-level abstractions that manage Pods, not the smallest deployable unit themselves.

Exam trap

A common misconception in Kubernetes is that a container is the smallest unit due to Docker's influence, but Kubernetes abstracts containers into Pods as the atomic scheduling and management unit.

How to eliminate wrong answers

Option A is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods, providing declarative updates and rollback capabilities; it is not the smallest deployable unit. Option B is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them, typically via a stable IP and DNS name; it is a networking abstraction, not a deployable workload unit. Option C is wrong because a Container is a runtime instance of a container image, but in Kubernetes, containers always run inside a Pod; a container cannot be created or managed directly by the Kubernetes API — the Pod is the smallest unit that can be scheduled and managed.

Practice this question →

135

MCQeasy

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

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

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

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

D.kubectl apply -f nginx-deployment.yaml

AnswerB

This creates a Deployment named nginx with the specified image.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

136

Multi-Selectmedium

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

Select 2 answers

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

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

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

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

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

AnswersB, D

Limits cap resource usage.

Why this answer

'resources.limits.memory' is the valid Kubernetes field to set the maximum amount of memory a container can use. When a container exceeds this limit, it may be terminated or OOM-killed by the kubelet. This is a core concept in Kubernetes resource management for ensuring predictable application behavior.

Exam trap

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

Practice this question →

137

MCQmedium

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

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerC

ConfigMaps store non-sensitive configuration data.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

138

MCQeasy

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

A.Ingress

B.EndpointSlice

C.Service

D.NetworkPolicy

AnswerC

A Service provides a stable IP and DNS name to reach a group of pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

139

MCQeasy

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

A.Service

B.Container

C.Pod

D.Deployment

AnswerC

A Pod is the smallest deployable unit.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

Option A is wrong because a Service is an abstraction that defines a logical set of Pods and a policy to access them; it is not a deployable unit but rather a networking resource that sits on top of Pods. Option B is wrong because a Container is not a Kubernetes API object; Kubernetes manages containers only within the context of a Pod, and you cannot create or manage a standalone container via the Kubernetes API. Option D is wrong because a Deployment is a higher-level controller that manages ReplicaSets and Pods; it is not the smallest deployable unit but rather a declarative way to manage Pod scaling and updates.

Practice this question →

140

MCQeasy

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

A.container runtime

B.kube-proxy

C.kubelet

D.kube-scheduler

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

141

MCQhard

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

A.The pods have a liveness probe that fails

B.The Deployment replicas are set to zero

C.The pods have a failing readiness probe

D.The Service type is NodePort

AnswerC

Readiness probe determines if a pod should receive traffic. Failing removes pod from Service endpoints.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

142

MCQmedium

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

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta1

AnswerC

apps/v1 is the current stable version for Deployments.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

143

MCQeasy

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

A.etcd

B.kube-apiserver

C.kube-controller-manager

D.kube-scheduler

AnswerC

The kube-controller-manager runs controller loops that reconcile the current state with the desired state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

144

MCQhard

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

A.Job with a Service

B.DaemonSet with a Service

C.StatefulSet with a Headless Service

D.Deployment with a Service

AnswerC

StatefulSets assign stable, unique DNS names to pods, typically used with a Headless Service for peer discovery.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

145

MCQeasy

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

A.Ingress

B.ConfigMap

C.Service

D.Deployment

AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

146

Multi-Selecthard

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

Select 2 answers

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

B.A database cluster that requires stable network identities

C.A batch job that runs once and exits

D.A stateless web application that can scale horizontally

E.A microservice that can use any available node

AnswersA, B

StatefulSet can use PersistentVolumeClaims with unique volumes per pod.

Why this answer

StatefulSets are designed for applications that require unique, persistent storage per Pod. Each Pod in a StatefulSet gets its own PersistentVolumeClaim (PVC) that is not shared, ensuring data isolation and durability even if the Pod is rescheduled. This is essential for stateful workloads like databases or message queues.

Exam trap

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

Practice this question →

147

MCQeasy

What is the primary purpose of a Kubernetes Service?

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

B.To provide persistent storage for pods

C.To store configuration data for pods

D.To manage rolling updates of applications

AnswerA

A Service provides a stable endpoint and load balancing for pods.

Why this answer

A Kubernetes Service provides a stable network endpoint (IP address and DNS name) to access a set of pods, which are ephemeral and can be rescheduled with different IPs. It acts as an abstraction layer, enabling load-balanced traffic to the pods via kube-proxy and iptables/IPVS rules. This is the core purpose of a Service, as defined in the Kubernetes API.

Exam trap

CNCF often tests the misconception that a Service manages pod lifecycle or updates, but the trap here is confusing the role of a Service (stable network abstraction) with that of a Deployment (reconciliation and rolling updates).

How to eliminate wrong answers

Option B is wrong because persistent storage for pods is provided by PersistentVolume (PV) and PersistentVolumeClaim (PVC) resources, not by a Service. Option C is wrong because configuration data for pods is stored in ConfigMaps or Secrets, not in a Service. Option D is wrong because managing rolling updates of applications is the responsibility of a Deployment (or StatefulSet), which uses a ReplicaSet to control the update strategy; a Service only exposes the pods, it does not manage their lifecycle or updates.

Practice this question →

148

MCQmedium

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

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

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

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

D.kubectl logs web-pod-7d4f8 app

AnswerC

This is the correct command to view logs of a specific container in a pod.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

149

MCQmedium

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

A.Deployments can expose services externally

B.Deployments support rolling updates and rollbacks

C.Deployments automatically configure DNS

D.Deployments provide persistent storage

AnswerB

Deployments enable controlled updates with revision history.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

150

MCQmedium

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

A.kubectl logs app -c sidecar

B.kubectl logs app sidecar

C.kubectl logs sidecar app

D.kubectl logs sidecar -p app

AnswerA

This command retrieves logs from the specified container.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →