CCNA Kubernetes Fundamentals Questions — Page 5 of 6

301

MCQmedium

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

A.Set strategy type to 'Recreate'.

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

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

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

AnswerC

RollingUpdate replaces pods incrementally; maxUnavailable=0 forbids any capacity drop, so the controller must create new pods before terminating old ones. maxSurge=1 permits one extra pod above the desired replica count, guaranteeing the zero-downtime constraint the team requires.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

302

MCQmedium

Which kubectl command is used to apply a manifest file to create or update resources?

A.kubectl update -f manifest.yaml

B.kubectl run -f manifest.yaml

C.kubectl apply -f manifest.yaml

D.kubectl create -f manifest.yaml

AnswerC

`kubectl apply -f manifest.yaml` performs a declarative create-or-update against the cluster's live state, satisfying the stem's dual requirement. It reads the manifest, compares it with the stored last-applied configuration, then patches only the differences — creating the resource when absent and updating it when present, without deleting and recreating.

Why this answer

`kubectl apply -f manifest.yaml` is the declarative management command that creates or updates resources by applying a configuration manifest. It uses a three-way merge algorithm to compute the changes needed to reconcile the desired state in the manifest with the current state in the cluster, making it suitable for both initial creation and subsequent updates.

Exam trap

The trap here is that candidates confuse `kubectl create` (imperative, fails on existing resources) with `kubectl apply` (declarative, handles both create and update), leading them to choose option D when they see 'create or update' in the question.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; the correct imperative update command is `kubectl edit` or `kubectl patch`, and `kubectl apply` is the declarative approach. Option B is wrong because `kubectl run` is used to create a pod or deployment imperatively from an image, not to apply a manifest file; it does not accept a `-f` flag for a manifest file. Option D is wrong because `kubectl create -f manifest.yaml` only creates resources and will fail if the resource already exists, whereas `kubectl apply` handles both creation and updates idempotently.

Practice this question →

303

MCQhard

A user creates a Pod with a PersistentVolumeClaim (PVC) that requests 5Gi of storage. The cluster has two PersistentVolumes (PVs): PV1 (3Gi, AccessModes: ReadWriteOnce) and PV2 (10Gi, AccessModes: ReadOnlyMany). The PVC specifies storageClassName: "" and AccessModes: ReadWriteOnce. Which PV will bind to the PVC?

A.PV2 will bind because it has sufficient capacity.

B.Neither PV will bind; the PVC will remain pending.

C.PV1 will bind because it has matching AccessModes.

D.Both PVs will bind to satisfy the request.

AnswerB

Binding requires matching capacity and access modes. PV1 is too small for the 5Gi request, while PV2 offers only ReadOnlyMany, not the requested ReadWriteOnce. With no storage class, no other PV satisfies both constraints, so the PVC stays Pending.

Why this answer

The PVC specifies storageClassName: "", which means it requires a PV with the same empty storage class (i.e., a statically provisioned PV without a StorageClass). PV1 has 3Gi capacity, which is less than the requested 5Gi, so it fails capacity matching. PV2 has ReadOnlyMany access mode, which does not match the PVC's ReadWriteOnce.

Since neither PV satisfies all binding criteria (capacity, access modes, and storage class), the PVC remains Pending.

Exam trap

The trap here is that candidates assume capacity is the only criterion or that a larger PV can compensate for mismatched access modes, but Kubernetes requires all three conditions (capacity, access modes, and storage class) to match exactly for a static PV to bind.

How to eliminate wrong answers

Option A is wrong because PV2 has ReadOnlyMany access mode, which does not match the PVC's ReadWriteOnce, and the storage class mismatch (empty string vs. implicit) also prevents binding; capacity alone is insufficient. Option C is wrong because PV1 has only 3Gi capacity, which is less than the PVC's request of 5Gi, so it fails the capacity requirement even though access modes match. Option D is wrong because a PVC binds to exactly one PV that satisfies all criteria; multiple PVs cannot bind to satisfy a single PVC request.

Practice this question →

304

MCQmedium

Which command is used to view the logs of a pod named 'web-pod'?

A.kubectl logs web-pod

B.kubectl describe pod web-pod

C.kubectl get logs web-pod

D.kubectl exec web-pod -- logs

AnswerA

kubectl logs retrieves stdout/stderr from a named pod's containers, satisfying the requirement to view 'web-pod' output. The logs subcommand targets a single pod directly, unlike exec or describe, which inspect state rather than emitted log streams.

Why this answer

The correct command to view logs from a pod in Kubernetes is 'kubectl logs web-pod'. This command retrieves the current stdout/stderr output from the primary container in the specified pod, which is the standard method for accessing container logs without entering the pod.

Exam trap

A common trap is confusing 'kubectl logs' with 'kubectl describe'. Candidates mistakenly think 'describe' shows logs due to its verbose output, but it only shows events and configuration, not the actual log stream.

How to eliminate wrong answers

Option B is wrong because 'kubectl describe pod web-pod' shows detailed metadata, status, and events for the pod, but does not display container logs; it provides configuration and state information, not log output. Option C is wrong because 'kubectl get logs' is not a valid kubectl subcommand; the correct subcommand is 'logs', and 'get' is used for resources like pods or deployments, not for log retrieval. Option D is wrong because 'kubectl exec web-pod -- logs' attempts to run a command named 'logs' inside the container, which does not exist; 'kubectl exec' is for executing arbitrary commands in a container, not for fetching logs, and would fail unless the container has a 'logs' binary.

Practice this question →

305

MCQhard

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

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

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

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

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

AnswerA

A Secret stores the API key separately from the image and Pod spec, and envFrom or valueFrom injects it as an environment variable at runtime. This satisfies the requirement to mount the key into the Pod without hard-coding credentials in the manifest or container image.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

306

Multi-Selecthard

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

Select 3 answers

A.Labels are encrypted at rest by default

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

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

D.Labels are immutable after creation

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

AnswersB, C, E

Set-based requirements use In, NotIn, Exists and DoesNotExist, matching a label against a list of values rather than exact equality. Equality-based selectors only compare a single key to a single value, so this statement is true.

Why this answer

Option B is correct because set-based selectors support operators such as In, NotIn, Exists, and DoesNotExist, allowing matching against a set of values rather than a single equality. Option C is correct because a Service uses its selector to match pod labels and route traffic only to the pods whose labels satisfy that selector. Option E is correct because labels are key/value pairs attached to objects specifically so users can organize and select subsets of objects, for example with kubectl get pods -l app=web.

Option A is not correct because labels are ordinary metadata and are not encrypted at rest by default; encryption at rest applies to etcd data only if configured. Option D is not correct because labels are mutable and can be added, updated, or removed after object creation.

Exam trap

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

Practice this question →

307

MCQmedium

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

A.Service

B.Ingress

C.Deployment

D.Pod

AnswerA

A Service front-ends a dynamic pod set behind a single stable virtual IP and DNS name, and kube-proxy load-balances connections across the selected endpoints. That satisfies the requirement for stable addressing plus load balancing, which bare pods with ephemeral IPs cannot provide.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

308

MCQeasy

A cluster administrator needs to run a log-forwarding agent on every node, including nodes added later, without manually scheduling a Pod per node. Which workload object should be used?

A.A Deployment with a high replica count

B.A Job with parallelism set to the node count

C.A DaemonSet

D.A StatefulSet with podManagementPolicy set to Parallel

AnswerC

A DaemonSet ensures one copy of a Pod runs on each eligible node and automatically schedules a copy onto nodes added to the cluster later. That matches node-level agents such as log shippers, metrics collectors, and CNI helpers. It removes the need to hand-place Pods or maintain per-node manifests as the cluster grows or nodes are replaced.

Why this answer

Node-wide agents need exactly one instance per node with automatic coverage of newly joined nodes. A DaemonSet is purpose-built for that pattern, scheduling a Pod onto each eligible node as the cluster changes. Deployments, Jobs, and StatefulSets all lack the one-per-node guarantee, so they cannot satisfy the requirement reliably.

Exam trap

The trap here is reaching for a Deployment with many replicas, which spreads Pods unevenly and never guarantees coverage of every node.

Practice this question →

309

MCQeasy

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

A.All nodes have disk pressure.

B.All nodes are unreachable or have been cordoned.

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

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

AnswerB

The taint indicates nodes are unreachable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

310

MCQmedium

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

A.Secret

B.PersistentVolume

C.ConfigMap

D.Service

AnswerC

ConfigMaps hold non-sensitive key-value configuration decoupled from pod images, satisfying the stem's requirement for data consumable as environment variables or mounted files. Secrets are reserved for sensitive data, so ConfigMap is the correct object here.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

311

MCQhard

A pod is stuck in the 'Pending' state. Which command would you use to get more details about why the pod cannot be scheduled?

A.kubectl logs <pod-name>

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

C.kubectl describe pod <pod-name>

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

AnswerC

kubectl describe pod returns the pod's events, including scheduler messages such as insufficient CPU, unschedulable taints or unbound persistent volume claims. Those events reveal why the scheduler cannot bind the pod, satisfying the stem's requirement for scheduling failure details.

Why this answer

`kubectl describe pod <pod-name>` provides detailed event logs and status information, including scheduler decisions, resource constraints, and node conditions that explain why a pod remains in 'Pending' state. The 'Pending' state typically indicates the pod has not been scheduled, and `kubectl describe` surfaces the exact reason, such as insufficient CPU/memory, persistent volume claims not bound, or node selector mismatches.

Exam trap

A common trap in Kubernetes exams is confusing `kubectl describe pod` (which shows dynamic runtime events and scheduling reasons) with `kubectl get pod -o yaml` (which shows static configuration). Candidates may think YAML output provides the same troubleshooting detail, but it lacks the scheduler decisions and event history that explain why a pod is 'Pending'.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` retrieves container stdout/stderr logs, which are only available after the pod has started running; a pod stuck in 'Pending' has no running containers, so this command returns nothing useful. Option B is wrong because `kubectl exec -it <pod-name> -- sh` attempts to open an interactive shell inside a running container, which is impossible when the pod is not scheduled and no containers exist. Option D is wrong because `kubectl get pod <pod-name> -o yaml` outputs the pod's current YAML manifest, which may show the `status.conditions` field but does not include the detailed scheduler events and resource allocation failures that `kubectl describe` surfaces in its 'Events' section.

Practice this question →

312

MCQmedium

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

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

B.The container image is invalid

C.Insufficient CPU or memory resources on any available node

D.The pod's liveness probe failed

AnswerC

The scheduler cannot bind the pod to any node because no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests. With no feasible node, the pod remains unscheduled in Pending rather than being placed and failing at runtime.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

313

MCQmedium

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

A.StatefulSet

B.DaemonSet

C.Job

D.ReplicaSet

AnswerD

A Deployment creates and owns a ReplicaSet, which in turn maintains the desired pod count and directly manages pod creation and deletion during a rolling update. The Deployment orchestrates revisions, but the ReplicaSet satisfies the replicas: 3 constraint by spawning replacement pods as old ones terminate.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

314

MCQeasy

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

A.kubectl attach <pod-name>

B.kubectl logs <pod-name>

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

D.kubectl describe pod <pod-name>

AnswerB

kubectl logs retrieves stdout and stderr captured by the kubelet for a container in the named pod, which is the standard mechanism for inspecting application output. Flags such as -c select a specific container in multi-container pods.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

315

MCQmedium

Which of the following is true about Kubernetes Namespaces?

A.Namespaces can be nested

B.Namespaces are required for all resources

C.Namespaces provide network isolation by default

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

AnswerD

Namespaces partition cluster resources, giving pods, services and other objects a logical scope so names need only be unique within each namespace. This satisfies the stem's requirement for logical isolation, though it is not network security: traffic between namespaces still flows unless NetworkPolicies restrict it.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

316

MCQeasy

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

A.Annotations

B.Selectors

C.Namespaces

D.Labels

AnswerC

Namespaces partition a single Kubernetes cluster into virtual scopes, letting objects such as pods and services be grouped and addressed independently. This satisfies the stem's requirement for logical isolation, since names, quotas and RBAC policies can be scoped per namespace without provisioning separate physical clusters.

Why this answer

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

Practice this question →

317

Multi-Selectmedium

Which THREE of the following are valid ways to pass configuration data to a container in a pod? (Select 3)

Select 3 answers

A.Modifying the container image after deployment

B.Using a PersistentVolumeClaim to store configuration

C.Setting environment variables directly in the pod spec

D.Using a ConfigMap mounted as a volume

E.Using a Secret as an environment variable

AnswersC, D, E

The env field in a container spec injects configuration as environment variables at container start, satisfying the requirement to pass configuration data directly. Values can be literal or reference ConfigMap and Secret keys, making this a valid in-spec mechanism.

Why this answer

Option C is correct because the pod spec allows you to define environment variables directly under the container's env field, which Kubernetes injects into the container process at startup. Option D is correct because a ConfigMap can be mounted as a volume, making its key-value pairs available as files inside the container's filesystem. Option E is correct because a Secret can be exposed as an environment variable using env or envFrom with valueFrom.secretKeyRef or secretRef, delivering sensitive configuration data to the container.

Option A is not a valid runtime configuration method because container images are immutable after deployment and cannot be modified in place. Option B is not a configuration-passing mechanism; a PersistentVolumeClaim provides persistent storage, not structured configuration data.

Exam trap

The trap here is that candidates might think PersistentVolumeClaims are valid for configuration data because they associate 'storage' with 'configuration files,' but PVCs are designed for persistent data, not for injecting small, mutable configuration values that are better handled by ConfigMaps or environment variables.

Practice this question →

318

MCQmedium

A user creates a Deployment with 'replicas: 3'. After applying the manifest, only 2 pods are running. What is the most likely cause?

A.The Deployment's YAML had a syntax error

B.There is insufficient node capacity to schedule the third pod

C.The container image name is misspelled

D.The ReplicaSet controller is not running

AnswerB

The ReplicaSet controller has created three pods, but the scheduler leaves one Pending because no node has sufficient allocatable CPU or memory. Replica count and scheduling are separate concerns, so insufficient node capacity is the most likely cause.

Why this answer

The most likely cause is insufficient node capacity, as the scheduler cannot place the third pod due to resource constraints (CPU, memory, or other limits). The Deployment controller creates a ReplicaSet, which instructs the scheduler to place pods; if nodes lack sufficient allocatable resources, pods remain in Pending state. This is a common scenario when cluster resources are exhausted.

Exam trap

KCNA often tests the distinction between pod creation failures (e.g., image errors, syntax errors) and scheduling failures (resource exhaustion), where candidates mistakenly attribute missing pods to configuration errors rather than cluster capacity.

How to eliminate wrong answers

Option A is wrong because a syntax error in the YAML would cause the API server to reject the manifest entirely, resulting in zero pods running, not two out of three. Option C is wrong because a misspelled container image name would cause the pod to fail with ImagePullBackOff or ErrImagePull, but the ReplicaSet would still attempt to create three pods, and they would show as running (though with errors) or in CrashLoopBackOff, not simply missing. Option D is wrong because the ReplicaSet controller is a core component of kube-controller-manager; if it were not running, no ReplicaSets would be reconciled, and zero pods would be created, not two.

Practice this question →

319

MCQmedium

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

A.DaemonSet

B.Deployment

C.ReplicaSet

D.StatefulSet

AnswerB

A Deployment manages stateless Pods through a ReplicaSet, guaranteeing the five replicas the stem demands. Its rolling update strategy replaces Pods incrementally, and `kubectl rollout undo` reverts to a prior revision, satisfying both the rolling update and rollback requirements. StatefulSets suit stateful workloads, and bare Pods lack self-healing.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

320

Multi-Selecthard

Which TWO statements about Namespaces are correct?

Select 2 answers

A.Resource names must be unique within a namespace

B.Namespaces provide network isolation by default

C.All Kubernetes resources are namespaced

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

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

AnswersA, D

Within a single namespace, object names must be unique for a given resource type, because the API server scopes identity by namespace plus name. This satisfies the stem's requirement for a correct Namespaces statement, unlike cross-namespace naming, which may legitimately repeat.

Why this answer

Option A is correct because within a single namespace, resource names (for a given resource type) must be unique — for example, you cannot have two Pods both named 'web' in the same namespace, though the same name can exist in different namespaces. Option D is correct because namespaces are intended to divide cluster resources among multiple users or teams, commonly combined with ResourceQuota and RBAC to scope access and limit consumption per namespace. Option B is not correct because namespaces do not provide network isolation by default; Pods across namespaces can communicate freely unless NetworkPolicies are applied.

Option C is not correct because not all resources are namespaced — cluster-scoped resources such as Nodes, PersistentVolumes, and ClusterRoles exist outside any namespace. Option E is not correct because deleting a namespace deletes all resources contained within it, so it does affect the resources inside.

Exam trap

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

Practice this question →

321

Multi-Selecthard

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

Select 2 answers

A.Deployments support rolling updates and rollbacks

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

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

D.Deployments manage the lifecycle of ReplicaSets

E.Deployments provide stable network identities for Pods

AnswersA, D

Deployments use a rolling update strategy to replace Pods gradually, and retain revision history so kubectl rollout undo can revert to a previous ReplicaSet. This satisfies the stem's requirement for correct Deployment statements, distinguishing them from bare ReplicaSets, which lack rollback capability.

Why this answer

Option A is correct because a Deployment's pod template can be updated declaratively, and the Deployment controller performs a rolling update by creating a new ReplicaSet and gradually scaling it up while scaling the old one down, with `kubectl rollout undo` providing rollback to a previous revision. Option D is correct because a Deployment does not manage Pods directly; it creates and manages ReplicaSets, which in turn maintain the desired number of Pod replicas, and each template change produces a new ReplicaSet revision. Option B is wrong because running one Pod copy per node is the job of a DaemonSet, not a Deployment.

Option C is wrong because run-to-completion batch workloads are handled by Jobs (or CronJobs), whereas Deployments are intended for long-running stateless services. Option E is wrong because stable network identities and per-Pod DNS names are provided by a headless Service (typically with a StatefulSet), not by a Deployment.

Exam trap

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

Practice this question →

322

Multi-Selectmedium

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

Select 2 answers

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

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

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

D.To improve application performance by reducing latency.

E.To store environment variables for containers.

AnswersA, C

NetworkPolicy objects are namespaced resources, so placing Pods in separate Namespaces lets you apply policies that restrict cross-Namespace traffic. This directly satisfies the stem's requirement to enforce network policies restricting traffic between Pods in different Namespaces.

Why this answer

Option A is correct because Namespaces provide a boundary for scoping resources, and NetworkPolicy objects are namespaced resources that select Pods within a namespace; policies can allow or deny ingress/egress traffic to Pods in other namespaces, so namespaces are a valid way to organize and enforce network segmentation between teams or environments. Option C is correct because Namespaces provide logical isolation of cluster resources (Pods, Services, ConfigMaps, etc.) and enforce unique names within each namespace, so two teams can each create a Service named 'web' in their own namespace without collision. Option B is not a reason to use Namespaces, since namespaces do not reduce control-plane API calls; if anything, managing more namespaces adds API objects.

Option D is not correct because namespaces are an organizational and isolation construct and do not reduce network latency or improve application performance. Option E is not correct because environment variables for containers are supplied via Pod specs, ConfigMaps, or Secrets, not by namespaces themselves.

Exam trap

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

Practice this question →

323

Multi-Selectmedium

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

Select 2 answers

A.kube-proxy

B.container runtime

C.kube-apiserver

D.kube-controller-manager

E.kubelet

AnswersC, D

The kube-apiserver runs on control-plane nodes and exposes the Kubernetes API, validating and persisting every object to etcd. It is a core control-plane component, satisfying the stem's requirement to identify two control-plane parts rather than worker-node agents like kubelet.

Why this answer

The Kubernetes control plane consists of components that make global cluster decisions and manage cluster state, and kube-apiserver (C) is the central control plane component that exposes the Kubernetes API and is the front end through which all other components communicate. kube-controller-manager (D) is also a control plane component; it runs the built-in controllers (such as node, replication, endpoints, and service account controllers) that continuously reconcile the desired state stored in etcd with the actual cluster state. By contrast, kube-proxy (A) is a node-level component that maintains network rules (iptables/IPVS) for Service load balancing, the container runtime (B) is node software like containerd or CRI-O that actually runs containers, and kubelet (E) is the node agent that registers the node and manages pods on it — all three run on worker nodes rather than as part of the control plane.

Exam trap

The trap here is that kube-proxy and kubelet sound like 'control' components but are actually node-level services, while the container runtime is often mistakenly thought of as part of the control plane due to its critical role.

Practice this question →

324

MCQmedium

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

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

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

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

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

AnswerD

--from-file reads the given file's contents and stores them as a single ConfigMap key named after the file, so app.properties becomes one entry. This satisfies the stem's requirement to build a ConfigMap directly from that file without manual YAML.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

325

MCQmedium

Which component of the control plane is responsible for persisting the entire cluster state?

A.kube-scheduler

B.kube-controller-manager

C.etcd

D.kube-apiserver

AnswerC

etcd is the distributed key-value store holding all cluster objects and their state; the API server reads and writes every resource there. Only etcd persists cluster state durably, so losing it loses the cluster's configuration and workload definitions.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects (Pods, Services, ConfigMaps, etc.), their specifications, and their current status. It is the only component that persists data to disk, ensuring that the cluster can recover its full state after a restart or failure. The kube-apiserver reads from and writes to etcd, but etcd itself is the storage backend.

Exam trap

The KCNA exam often tests the misconception that kube-apiserver is the persistence layer because it is the central entry point, but the trap is that the API server is stateless and only acts as a gateway to etcd, which is the actual durable store.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints, but it does not persist any state; it only updates scheduling decisions via the API server. Option B is wrong because kube-controller-manager runs controller loops (e.g., ReplicaSet, Node, Deployment controllers) that reconcile desired state with actual state, but it relies on etcd for persistence and does not store data itself. Option D is wrong because kube-apiserver is the front-end for the control plane that validates and processes REST requests, but it delegates all persistent storage to etcd and does not maintain its own durable state.

Practice this question →

326

MCQeasy

What is the primary purpose of Kubernetes?

A.To orchestrate containers across a cluster of machines

B.To provide a graphical user interface for managing containers

C.To replace Docker as a container runtime

D.To provide a virtual machine management platform

AnswerA

Kubernetes schedules, runs and reconciles containerised workloads across a pool of machines, handling placement, scaling, networking and self-healing. This satisfies the stem's requirement that containers be orchestrated across a cluster rather than run on a single host.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

327

MCQhard

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

A.The image registry credentials are missing

B.The liveness probe is misconfigured and killing the container

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

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

AnswerD

The error shows the container runtime cannot locate the "app" executable in $PATH, meaning the image lacks that binary. The command field references a file absent from the image, so the container exits immediately and Kubernetes retries, producing CrashLoopBackOff.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

328

MCQhard

An administrator is configuring a NetworkPolicy to allow ingress traffic to Pods with label `role=db` only from Pods with label `role=api` on TCP port 6379. The NetworkPolicy is applied in the same namespace as the Pods. Which NetworkPolicy YAML correctly implements this requirement?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379

B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379 egress: - to: - podSelector: matchLabels: role: api ports: - protocol: TCP port: 6379

C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: db policyTypes: - Ingress ingress: - from: - namespaceSelector: {} ports: - protocol: TCP port: 6379

D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-api-to-db spec: podSelector: matchLabels: role: api policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: role: db ports: - protocol: TCP port: 6379

AnswerA

This policy selects Pods with role=db and allows ingress from Pods with role=api on TCP port 6379. It correctly uses podSelector in the ingress rule to match the source Pods and specifies the port. Since it is in the same namespace, no namespaceSelector is needed. This precisely implements the requirement, allowing only the intended traffic.

Why this answer

The correct NetworkPolicy selects the target Pods (role=db) and defines an ingress rule that allows traffic from Pods labeled role=api on TCP port 6379. It uses a podSelector within the from clause to match the source Pods. Since both sets of Pods are in the same namespace, no namespaceSelector is required.

The other options either allow too much traffic, reverse the roles, or add unnecessary egress restrictions that could disrupt other traffic.

Exam trap

The trap here is using an empty namespaceSelector, which allows all Pods in all namespaces, instead of a podSelector to restrict to specific Pods.

Practice this question →

329

Multi-Selecthard

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

Select 2 answers

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

B.Check that the container runtime is working

C.Check the kube-apiserver status

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

E.Restart all nodes in the cluster

AnswersA, D

kube-proxy programs the iptables or IPVS rules that implement ClusterIP Service load balancing on each node. If it is not running, traffic to the Service's virtual IP is never forwarded to backend Pods, so verifying it directly addresses the connectivity failure.

Why this answer

Option A is correct because ClusterIP Services rely on kube-proxy running on each node to program iptables/IPVS rules that translate the virtual ClusterIP into the backing Pod IPs, so if kube-proxy is down, traffic to the Service will fail. Option D is correct because a ClusterIP Service with no endpoints (empty Endpoints object) means the selector doesn't match any ready Pods, which is the most common cause of an unreachable Service; 'kubectl get endpoints <service>' quickly reveals this. Option B is not the right focus because a broken container runtime would affect Pod scheduling/status broadly, not specifically Service routing, and would typically show up as Pod failures rather than a Service-only issue.

Option C is not appropriate because if the kube-apiserver were down, kubectl commands and cluster-wide operations would fail, not just one web application's Service. Option E is not appropriate because restarting all nodes is a disruptive, non-diagnostic action that does not isolate the root cause and is not a troubleshooting step.

Exam trap

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

Practice this question →

330

MCQmedium

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

A.kubectl get pods -n team-a

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

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

D.kubectl get pods --all-namespaces

AnswerA

kubectl get pods -n team-a scopes the listing to that namespace and returns all pods regardless of readiness, since readiness only affects the READY column. Without -n, the command defaults to the current namespace, which may not be team-a.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

331

MCQhard

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

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

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

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

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

AnswerC

Scaling a Deployment adjusts the existing ReplicaSet's replica count rather than creating a new one; the ReplicaSet controller then creates the two additional pods to reach five, since no pod template change triggers a rollout.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

332

MCQeasy

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

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerD

The kube-apiserver exposes the Kubernetes REST API and serves as the sole entry point for administrative tasks, validating and processing every request before persisting state to etcd. It satisfies the stem's requirement directly: all administrative operations, including kubectl commands, route through this component rather than any other control plane service.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

333

MCQmedium

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

A.ConfigMap

B.Secret

C.ServiceAccount

D.PersistentVolume

AnswerA

ConfigMap stores non-sensitive configuration as key–value pairs, which Kubernetes can project into a pod as environment variables via `envFrom` or `valueFrom.configMapKeyRef`. This satisfies the stem's constraint that the data is not sensitive, unlike Secret, which is intended for credentials and base64-encodes values.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

334

MCQmedium

You have a Deployment that must run exactly one replica on each node in the cluster for logging purposes. Which Kubernetes resource should you use?

A.Job

B.Deployment

C.StatefulSet

D.DaemonSet

AnswerD

A DaemonSet guarantees one pod replica on every node, matching the stem's exactly-one-per-node logging requirement. Unlike a Deployment, whose replica count is cluster-wide and scheduler-placed, the DaemonSet controller bypasses scheduling decisions and tracks node membership, automatically adding pods to newly joined nodes.

Why this answer

A DaemonSet ensures that exactly one replica of a Pod runs on every node in the cluster, including when nodes are added or removed. This makes it the ideal resource for cluster-wide logging, monitoring, or other node-level agents that must be present on each node.

Exam trap

A common misconception is that a Deployment with a high replica count can achieve per-node coverage, but Deployments do not enforce node-level placement and can leave some nodes empty or run multiple Pods on the same node.

How to eliminate wrong answers

Option A is wrong because a Job is designed to run a finite task to completion, not to maintain a persistent Pod on every node. Option B is wrong because a Deployment manages a desired number of replicas across the cluster, but it does not guarantee one Pod per node; it uses a scheduler to distribute replicas arbitrarily. Option C is wrong because a StatefulSet is intended for stateful applications requiring stable network identities and ordered deployment, not for ensuring one Pod per node.

Practice this question →

335

MCQeasy

What is the purpose of a Service in Kubernetes?

A.To provide persistent storage volumes

B.To manage rolling updates of pods

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

D.To store configuration data as key-value pairs

AnswerC

A Service provides a stable virtual IP and DNS name that load-balances traffic across a dynamically changing set of pods selected by labels. This decouples clients from individual pod IPs, which change as pods are created or replaced.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

336

MCQhard

Which Kubernetes resource can be used to assign a pod to a specific node?

A.Node affinity rules in the pod spec

B.A NetworkPolicy

C.A Service account

D.A ConfigMap

AnswerA

Node affinity in the pod spec constrains scheduling to nodes matching label expressions, such as requiredDuringSchedulingIgnoredDuringExecution with a hostname selector. This assigns the pod to a specific node, unlike taints, which repel pods rather than attract them.

Why this answer

Node affinity rules in the pod spec are a set of constraints that define which nodes a pod can be scheduled on, based on node labels. This is a native Kubernetes scheduling feature that allows you to attract pods to specific nodes using required or preferred matching rules, such as `requiredDuringSchedulingIgnoredDuringExecution`. This directly answers the question of assigning a pod to a specific node.

Exam trap

A common trap is thinking that a NetworkPolicy or a ConfigMap can influence pod placement, when in fact only scheduling constructs like node affinity, nodeSelector, or taints/tolerations control node assignment.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy is a Kubernetes resource that controls ingress and egress traffic between pods and network endpoints, not pod placement or node assignment. Option C is wrong because a Service account provides an identity for pods to authenticate with the Kubernetes API server, and it has no role in scheduling or node selection. Option D is wrong because a ConfigMap is used to inject configuration data (key-value pairs) into pods as environment variables, command-line arguments, or files; it does not influence the scheduler's node assignment.

Practice this question →

337

Multi-Selectmedium

Which two statements correctly describe etcd in a Kubernetes cluster?

Select 2 answers

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

B.It runs on every worker node

C.It manages network rules for Services

D.It implements the Kubernetes API

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

AnswersA, E

etcd is the consistent, distributed key-value store backing the cluster, persisting all API objects including configuration, Secrets and state. Every read and write through the API server depends on it, making it the authoritative source of cluster data.

Why this answer

Option A is correct because etcd is the distributed, consistent key-value store that persists all Kubernetes cluster data, including configuration, object definitions, and cluster state, making it the single source of truth for the control plane. Option E is correct because etcd is a critical component: losing its data can render the cluster unrecoverable, so regular backups (e.g., via etcdctl snapshot save) are essential for disaster recovery. Option B is wrong because etcd typically runs only on control plane nodes (or as an external cluster), not on every worker node.

Option C is wrong because network rules for Services are handled by kube-proxy (and CNI plugins), not etcd. Option D is wrong because the Kubernetes API is implemented by the kube-apiserver, which reads from and writes to etcd rather than etcd implementing the API itself.

Exam trap

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

Practice this question →

338

MCQhard

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

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

B.Use ConfigMap for both

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

D.Use Secret for both

AnswerA

ConfigMaps hold non-sensitive configuration data such as files, while Secrets store sensitive values like database passwords with base64 encoding and tighter access controls. Splitting them keeps credentials out of plain configuration and satisfies the secure-management requirement.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

339

MCQmedium

You have a Deployment defined with replicas: 3. You run 'kubectl scale deployment my-deployment --replicas=5'. What happens?

A.The Deployment is updated to have 5 replicas, but existing pods are recreated to match.

B.The command fails because you cannot scale a Deployment directly.

C.The Deployment rolls out a new version with 5 replicas.

D.The Deployment is updated to have 5 replicas, and the ReplicaSet creates 2 additional pods.

AnswerD

Scaling updates the Deployment's desired replica count to 5, and the Deployment controller propagates this to its ReplicaSet, which creates 2 additional pods to reach the target. This satisfies the stem's constraint that the change flows through the Deployment–ReplicaSet ownership hierarchy rather than acting on pods directly.

Why this answer

`kubectl scale` directly updates the `.spec.replicas` field of the Deployment, which in turn instructs the existing ReplicaSet to adjust its pod count. The ReplicaSet controller then creates 2 additional Pods to reach the desired 5 replicas, without recreating existing Pods or triggering a rollout.

Exam trap

The trap here is that candidates confuse scaling with rolling updates, assuming that any change to a Deployment triggers a rollout, when in fact only changes to the Pod template (e.g., image, command) cause a new ReplicaSet to be created.

How to eliminate wrong answers

Option A is wrong because scaling does not recreate existing Pods; the ReplicaSet simply adds or removes Pods to match the new replica count, leaving healthy Pods untouched. Option B is wrong because `kubectl scale` is a valid command for Deployments, ReplicaSets, and StatefulSets, and it does not fail when used correctly. Option C is wrong because scaling does not trigger a rollout (which would require a change to the Pod template, such as a new container image); it only changes the replica count, leaving the current ReplicaSet in place.

Practice this question →

340

MCQeasy

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

A.Service

B.Container

C.Pod

D.Node

AnswerC

A pod groups one or more containers that share a network namespace and volumes, and is the atomic unit the scheduler places on a node. Deployments, ReplicaSets and Services operate on pods rather than being scheduled themselves.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

341

MCQmedium

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

A.apiVersion: extensions/v1beta1

B.apiVersion: v1

C.apiVersion: apps/v1

D.apiVersion: apps/v1beta2

AnswerC

Deployments moved from the deprecated extensions/v1beta1 to the stable apps/v1 group, which remains the required API version through Kubernetes v1.29 and beyond. Specifying apps/v1 satisfies the stem's modern-cluster constraint, ensuring the manifest is accepted rather than rejected as an unknown or removed resource type.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

342

MCQmedium

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

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

B.The pod's image pull is failing.

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

D.The pod was evicted due to resource pressure.

AnswerC

The scheduler reports insufficient memory on three nodes, meaning each lacks the capacity to satisfy the pod's declared resource requests. Requests, not actual usage, drive scheduling decisions, so the pod remains Pending until a node with adequate allocatable memory becomes available.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

343

MCQeasy

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

A.To create or update resources from a manifest

B.To view resource details

C.To delete resources

D.To execute commands inside a container

AnswerA

kubectl apply performs a declarative create-or-update by comparing the manifest against live state and patching differences. This satisfies the requirement to reconcile resources from a file, unlike imperative create, which fails if the resource already exists.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

344

Multi-Selecteasy

Which THREE statements about Kubernetes Namespaces are correct?

Select 3 answers

A.Namespaces provide a way to divide cluster resources between multiple users or teams.

B.All Kubernetes resources must be created within a namespace.

C.Namespaces provide network isolation by default.

D.Deleting a namespace will delete all resources in it.

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

AnswersA, D, E

Namespaces create logical partitions within a single cluster, letting teams share underlying nodes while scoping names, RBAC and quotas per partition. This satisfies the stem's requirement for dividing cluster resources between multiple users or teams without provisioning separate clusters.

Why this answer

Option A is correct because Kubernetes Namespaces are designed as a logical partitioning mechanism that lets a single physical cluster be shared among multiple users, teams, or projects, scoping names and resource usage per group. Option D is correct because deleting a Namespace triggers cascading deletion of all namespaced objects contained in it (e.g., Pods, Services, ConfigMaps), so the namespace and its contents are removed together. Option E is correct because ResourceQuota objects are applied at the namespace scope to cap aggregate consumption of resources such as CPU, memory, and object counts within that namespace.

Option B is incorrect because many resources are cluster-scoped and cannot live in a namespace, such as Nodes, PersistentVolumes, ClusterRoles, and StorageClasses. Option C is incorrect because namespaces do not enforce network isolation by default; without a NetworkPolicy, pods in different namespaces can communicate freely, so isolation must be explicitly configured.

Exam trap

CNCF often tests the misconception that Namespaces provide automatic network isolation, but in reality, network policies must be explicitly defined to restrict traffic between namespaces.

Practice this question →

345

MCQhard

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

A.Use a resource request for SSD storage capacity

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

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

D.Add a toleration for a taint on SSD nodes

AnswerC

nodeSelector pins the Pod to nodes bearing matching labels, so labelling SSD nodes disktype: ssd and referencing it in the Pod spec satisfies the SSD constraint. This differs from affinity, which expresses richer preference and topology rules.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

346

MCQmedium

A developer creates a Pod with two containers. The first container writes logs every 30 seconds to a shared volume. The second container reads those logs. After deployment, the second container fails to start because it cannot find the log file. The Pod spec uses an emptyDir volume mounted at /var/logs in both containers. What is the most likely cause?

A.emptyDir volumes are not shared between containers in the same Pod; each container gets its own isolated volume.

B.The Pod's restartPolicy is set to Never, so the second container will not restart after failing.

C.The second container starts before the first container writes any logs, and it exits because the file does not exist.

D.The second container lacks the necessary permissions to read files written by the first container.

AnswerC

Containers in a Pod start concurrently, not sequentially. The reader container may start before the writer has created the log file, causing a failure if it expects the file to exist immediately. Using an init container or a retry loop would resolve this race condition.

Why this answer

Containers within a Pod start simultaneously without guaranteed ordering. When one container depends on a file created by another, the reader may start first and fail. This race condition is best solved by using an init container that waits for the file, or by making the reader container resilient to the file's absence.

Exam trap

The trap here is assuming that containers in a Pod start sequentially, with the first container completing its initial work before the second starts.

Practice this question →

347

MCQeasy

A platform engineer wants to restrict a Pod so that it runs only on nodes that have the label disktype=ssd. The engineer adds a nodeSelector field to the Pod specification. Which statement best describes the effect of nodeSelector in this scenario?

A.The Pod is scheduled only onto nodes that have at least one label, regardless of the label value.

B.The Pod is scheduled onto any node, but nodes without the label are given lower priority.

C.The Pod is scheduled only onto nodes whose labels match all specified key-value pairs.

D.The Pod can run on any node, but the kubelet on unlabeled nodes refuses to start the container.

AnswerC

nodeSelector is a hard scheduling constraint expressed as a map of labels. The scheduler filters nodes and only considers those that contain every label key-value pair listed in nodeSelector. If no node matches, the Pod remains Pending. In this scenario, only nodes labeled disktype=ssd are eligible, which is exactly the intended behavior.

Why this answer

nodeSelector is a hard constraint that filters the node set to those containing all specified labels. The scheduler binds the Pod only to a matching node; otherwise the Pod remains Pending. This makes it suitable for simple placement requirements such as selecting SSD-backed nodes.

The other descriptions confuse nodeSelector with soft preferences, kubelet behavior, or label existence checks, all of which are inaccurate.

Exam trap

The trap here is confusing nodeSelector's hard filter with node affinity's soft preference, leading to the belief that non-matching nodes are still usable with lower priority.

Practice this question →

348

Multi-Selecteasy

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

Select 2 answers

A.Ensuring the desired number of pod replicas are running

B.Implementing service networking rules

C.Storing the cluster state

D.Detecting node failures and reacting

E.Scheduling pods onto nodes

AnswersA, D

The ReplicaSet controller, embedded within the kube-controller-manager, continuously reconciles the observed pod count against the declared replica count, creating or deleting pods to match. This control loop directly maintains the desired number of pod replicas, satisfying the stem's requirement.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicaSet controller (and Deployment controller), which continuously reconciles the actual number of pod replicas with the desired count specified in the ReplicaSet/Deployment spec. Option D is correct because the node lifecycle controller within the kube-controller-manager monitors node heartbeats and marks nodes as NotReady or evicts their pods when failures are detected. Option B is wrong because service networking rules are implemented by kube-proxy (via iptables/IPVS) on each node, not by the kube-controller-manager.

Option C is wrong because cluster state is stored in etcd, the distributed key-value store. Option E is wrong because pod placement is the job of the kube-scheduler, which binds pods to nodes.

Exam trap

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

Practice this question →

349

MCQmedium

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

A.Secret

B.PersistentVolume

C.ConfigMap

D.ServiceAccount

AnswerA

A Secret stores sensitive data such as passwords separately from pod specs, and it can be injected into a container as an environment variable via envFrom or valueFrom.secretKeyRef, satisfying the stem's secure storage and environment variable constraints.

Why this answer

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

Practice this question →

350

MCQeasy

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

A.kubectl describe pod web-pod

B.kubectl get pod web-pod

C.kubectl logs web-pod

D.kubectl exec web-pod -- env

AnswerA

kubectl describe pod web-pod queries the API server for the pod's full status, including events, conditions, container states, and recent scheduling failures. It defaults to the current namespace, so the default namespace requires no extra flag.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

351

MCQeasy

Which Kubernetes control plane component is the entry point for all REST API requests?

A.kube-controller-manager

B.kube-apiserver

C.kube-scheduler

D.etcd

AnswerB

The kube-apiserver exposes the Kubernetes REST API and is the sole entry point through which all clients, including kubectl and internal components, submit requests. This satisfies the stem's requirement for the control plane's API entry point.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all REST API requests. It validates and processes API calls (e.g., via kubectl, client libraries, or internal components) before persisting state to etcd or triggering other controllers. No other component directly exposes an API endpoint for external or internal management operations.

Exam trap

Some may mistakenly think etcd is the entry point because it stores all cluster data, but the apiserver is the only component that directly interfaces with etcd and exposes the Kubernetes API.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager runs controller loops (e.g., Node Controller, Replication Controller) but does not expose a REST API; it relies on the kube-apiserver to watch and update resources. Option C is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource constraints and policies, not for handling API requests; it communicates with the apiserver to bind pods. Option D is wrong because etcd is a distributed key-value store used for cluster state persistence, not an API entry point; it is accessed only by the kube-apiserver via the etcd API (gRPC), never directly by users or other components.

Practice this question →

352

MCQmedium

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

A.There are insufficient resources on any available node

B.The pod is still being initialized

C.The container image is missing

D.The pod has crashed and is restarting

AnswerA

The scheduler cannot bind a Pod when no node has enough allocatable CPU or memory to satisfy its requests, leaving it Pending indefinitely. Insufficient node resources is the most frequent cause of unschedulable Pods, matching the stem's Pending symptom.

Why this answer

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

Practice this question →

353

MCQhard

A platform engineer is designing a multi-tenant cluster. They want to ensure that a specific team's workloads can only be scheduled onto nodes labeled `team=blue`, and that workloads from other teams cannot be scheduled there. The team's Pods should not run on any other nodes. Which combination of Kubernetes features should the engineer use to enforce this?

A.NetworkPolicy applied to the team's namespace with a node selector.

B.Pod affinity rules alone, using requiredDuringSchedulingIgnoredDuringExecution.

C.nodeSelector on the Pods plus taints and tolerations on the nodes.

D.ResourceQuota and LimitRange applied to the team's namespace.

AnswerC

nodeSelector or nodeAffinity attracts the team's Pods to nodes labeled team=blue, while a taint such as dedicated=blue:NoSchedule on those nodes repels Pods that lack the matching toleration. Together they provide both attraction and repulsion, ensuring only the intended Pods land on those nodes and that those Pods go nowhere else. This is the standard pattern for dedicated node pools.

Why this answer

Dedicated node pools are implemented by combining attraction and repulsion. nodeSelector or nodeAffinity pulls the team's Pods toward nodes labeled team=blue, while a taint on those nodes, paired with a toleration on the Pods, keeps other workloads away. Neither feature alone provides full isolation: nodeSelector without a taint lets others share the node, and a taint without nodeSelector lets the team's Pods land elsewhere.

Exam trap

The trap here is thinking that nodeSelector alone provides isolation, when it only attracts Pods and does not repel others from the node.

Practice this question →

354

MCQmedium

A developer needs to update a running Deployment's container image from 'nginx:1.21' to 'nginx:1.23' with minimal downtime and the ability to roll back if the new version fails. Which kubectl command should be used?

A.kubectl edit deployment my-deployment

B.kubectl apply -f updated-deployment.yaml

C.kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.23"}]}}}}'

D.kubectl set image deployment/my-deployment nginx=nginx:1.23

AnswerD

The `kubectl set image` command triggers a rolling update of the Deployment, which incrementally replaces Pods running `nginx:1.21` with `nginx:1.23` while keeping the ReplicaSet available. This satisfies the minimal-downtime requirement because the controller maintains at least the desired number of healthy Pods during the transition. Additionally, the previous ReplicaSet is retained, enabling a rollback via `kubectl rollout undo` if the new image fails.

Why this answer

`kubectl set image` directly updates the container image of a running Deployment, triggering a rolling update that replaces pods gradually to minimize downtime. This command also preserves the Deployment's rollout history, enabling a simple `kubectl rollout undo` to roll back if the new image fails.

Exam trap

This question tests the misconception that any imperative command (like `edit` or `patch`) is equivalent for updating images, but the trap here is that `kubectl set image` is the simplest, most reliable imperative command specifically designed for this task, while other options introduce unnecessary complexity or risk of configuration drift.

How to eliminate wrong answers

Option A is wrong because `kubectl edit` opens an interactive editor, which is error-prone and not scriptable, and it does not inherently provide a clean rollout history for rollback. Option B is wrong because `kubectl apply` uses a declarative approach that may overwrite other changes in the live configuration if the YAML file is not fully synchronized, and it requires an updated file, adding unnecessary overhead. Option C is wrong because `kubectl patch` directly modifies the pod template spec, but it is more complex and error-prone than the dedicated `set image` command, and it does not automatically leverage the Deployment's rollout history for rollback.

Practice this question →

355

MCQeasy

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

A.kube-scheduler

B.etcd

C.kube-controller-manager

D.kube-apiserver

AnswerC

kube-controller-manager runs the built-in controllers — node, replication, endpoints and service account controllers — each watching resource state through the API server and reconciling actual state toward the declared desired state. This continuous control loop is precisely the mechanism the stem asks for when it specifies maintaining desired cluster state.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

356

MCQmedium

Which component is responsible for ensuring that the containers in a pod are running as specified?

A.kube-apiserver

B.kube-controller-manager

C.kubelet

D.kube-proxy

AnswerC

The kubelet runs on each node as the primary agent, receiving PodSpecs and directly managing container lifecycles through the container runtime. It continuously reconciles actual container state against the declared specification, restarting or reporting containers that deviate, which satisfies the requirement that containers run as specified.

Why this answer

The kubelet is the primary node agent that runs on each worker node. It receives PodSpec definitions from the API server (or from a local file/HTTP source for static pods) and ensures that the containers described in those PodSpecs are actually running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) via the CRI to start, stop, and restart containers as needed, continuously reconciling the actual state with the desired state.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager's role in managing controllers (like Deployments) with the actual node-level execution of containers, leading them to pick Option B instead of the kubelet.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane, exposing the REST API and validating/processing requests, but it does not directly manage container lifecycle on nodes. Option B is wrong because kube-controller-manager runs controller processes (like ReplicaSet or Node controllers) that make global decisions about cluster state, but it does not directly interact with containers on a node; it delegates execution to the kubelet. Option D is wrong because kube-proxy is a network proxy that handles service-to-pod routing and load balancing using iptables or IPVS rules, not container lifecycle management.

Practice this question →

357

MCQmedium

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

A.Using a ConfigMap

B.Using an annotation

C.Using a Secret

D.Using a PersistentVolume

AnswerA

A ConfigMap holds non-confidential key-value configuration that can be consumed as environment variables, command-line arguments or mounted files, decoupling settings from the container image. This lets the same image run across environments with different configuration, satisfying the stem's constraint.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

358

MCQmedium

A cluster administrator needs to grant a CI/CD service account permission to create and delete Pods only within the staging namespace, while denying access in all other namespaces. Which Kubernetes authorization mechanism should be used?

A.A PodSecurityPolicy scoped to the staging namespace

B.A NetworkPolicy with a namespaceSelector targeting staging

C.A ClusterRole and ClusterRoleBinding

D.A Role and RoleBinding in the staging namespace

AnswerD

A Role defines permissions within a single namespace, and a RoleBinding grants those permissions to a subject such as a ServiceAccount in that namespace. Creating the Role and RoleBinding in staging limits the CI/CD service account to Pod operations there, leaving other namespaces unaffected, which matches the principle of least privilege.

Why this answer

Role-based access control scopes permissions either cluster-wide or to a namespace. A Role paired with a RoleBinding in staging grants the service account permission to act on Pods only in that namespace. A ClusterRoleBinding would widen access to every namespace, while NetworkPolicy and PodSecurityPolicy address network filtering and Pod security admission respectively, not API authorization.

Exam trap

The trap here is choosing a ClusterRole with a ClusterRoleBinding because it is convenient, forgetting that a ClusterRoleBinding always grants cluster-wide access rather than namespace-scoped access.

Practice this question →

359

Multi-Selecthard

Which TWO of the following are correct about the 'kubectl apply' command compared to 'kubectl create'? (Select exactly two.)

Select 2 answers

A.kubectl apply requires the --save-config flag to record the last-applied-configuration annotation

B.kubectl apply cannot be used on resources that already exist

C.kubectl apply can create objects but not update them

D.kubectl apply can accept a directory of YAML files with -f

E.kubectl apply uses a declarative approach and can update existing objects

AnswersD, E

Both apply and create accept -f, and that flag works with a directory path, recursively processing every YAML file inside. This lets you apply a whole manifest set in one command, satisfying the directory requirement in the stem.

Why this answer

Option D is correct because 'kubectl apply -f <directory>' accepts a directory path and recursively applies all YAML/JSON manifests it contains, just like 'kubectl create -f' does. Option E is correct because 'kubectl apply' is the declarative management command: it creates the object if it does not exist and patches/updates it if it does, using the last-applied-configuration annotation to compute a three-way merge. Option A is wrong because '--save-config' is not required for apply; apply itself records the kubectl.kubernetes.io/last-applied-configuration annotation automatically (the flag is mainly used with 'kubectl create' to enable later apply).

Option B is wrong because apply is specifically designed to work on existing resources, updating them in place. Option C is wrong because apply both creates new objects and updates existing ones.

Exam trap

The trap here is that candidates often confuse `kubectl apply` with `kubectl create`, mistakenly thinking `apply` cannot update existing resources or that it requires extra flags to record configuration history, when in fact `apply` is inherently declarative and updates are its primary strength.

Practice this question →

360

Multi-Selectmedium

Which TWO of the following are responsibilities of the kubelet? (Select 2)

Select 2 answers

A.Registering the node with the cluster and reporting node status

B.Ensuring that containers defined in PodSpecs are running and healthy

C.Scheduling pods onto nodes based on resource availability

D.Creating and managing network iptables rules for Services

E.Storing cluster configuration data

AnswersA, B

The kubelet runs on each node and, via its node registration and status-reporting duties, creates the Node object and periodically posts node conditions and capacity to the API server. This satisfies the stem's requirement for a genuine kubelet responsibility, distinct from control-plane scheduling.

Why this answer

Option A is correct because the kubelet is the node agent that registers its node with the API server (via a Node object) and continuously reports node status, including conditions and capacity, through the node status heartbeat mechanism. Option B is correct because the kubelet watches for PodSpecs assigned to its node and ensures the described containers are started and running, performing liveness, readiness, and startup probes to maintain container health. Option C is incorrect because pod scheduling is the responsibility of the kube-scheduler, which selects nodes based on resource availability and constraints, not the kubelet.

Option D is incorrect because Service iptables/IPVS rules are programmed by kube-proxy, not the kubelet. Option E is incorrect because cluster configuration data is stored in etcd, the cluster's key-value datastore, not managed by the kubelet.

Exam trap

A common exam trap is confusing the kubelet (node agent) with the kube-scheduler (pod placement). Candidates mistakenly assign scheduling duties to the kubelet because it is the component that actually runs the pods.

Practice this question →

361

MCQhard

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

A.The Service is not associated with a namespace

B.The Service is exposed on the wrong port

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

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

AnswerD

A ClusterIP Service routes traffic only to pods whose labels match its selector; an empty endpoint list means no pod satisfied that selector. Since the stem shows no endpoints, the selector likely mismatches the running pods' labels, so kube-proxy has no backend addresses to forward to.

Why this answer

A ClusterIP Service with no endpoints almost always means its label selector does not match any running pods. The endpoints controller populates the Endpoints object by matching the Service's selector against pod labels; if no pods match, the list is empty and traffic cannot be routed. This is the most common cause of the reported symptom.

Exam trap

KCNA often tests the relationship between Service selectors and pod labels, so candidates who focus on network-level causes (kube-proxy, ports) instead of the selector mismatch pick the wrong answer.

How to eliminate wrong answers

Option A is wrong because every Service in Kubernetes is associated with a namespace (default if unspecified); a Service cannot exist without a namespace, so this is not a valid cause. Option B is wrong because an incorrect port would cause connection failures but would not result in an empty endpoints list; the endpoints would still be populated. Option C is wrong because if kube-proxy were not running, the Service would still have endpoints; the failure would be in traffic routing, not endpoint discovery.

Practice this question →

362

MCQmedium

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

A.Service

B.PersistentVolumeClaim

C.Secret

D.ConfigMap

AnswerC

A Secret stores sensitive data such as passwords separately from Pod specifications, and can be injected into containers as environment variables via envFrom or valueFrom. This satisfies the stem's requirement to store the database password securely while exposing it as an environment variable.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

363

MCQmedium

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

A.Deployment

B.StatefulSet

C.Job

D.DaemonSet

AnswerA

A Deployment manages a ReplicaSet that maintains three identical, interchangeable pods and performs rolling updates, replacing pods gradually so service stays available. Statelessness suits this model; StatefulSet would add unnecessary stable identities and ordering guarantees.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

364

MCQeasy

A developer runs `kubectl create configmap app-config --from-literal=LOG_LEVEL=debug` and then creates a Pod that references this ConfigMap as a volume. After the ConfigMap is updated with `kubectl edit configmap app-config` to change LOG_LEVEL to info, the application inside the running Pod still reads LOG_LEVEL=debug. What is the most likely reason?

A.ConfigMaps mounted as volumes are immutable after Pod creation; the Pod must be deleted and recreated to pick up changes.

B.ConfigMap volumes are updated automatically, but the application must be designed to reload the file; the kubelet sync period may cause a delay.

C.The ConfigMap was created in a different namespace than the Pod, so the volume mount silently falls back to the original literal value.

D.Environment variables sourced from ConfigMaps are updated live, but volume-mounted ConfigMaps are cached indefinitely by the container runtime.

AnswerB

When a ConfigMap is mounted as a volume, the kubelet periodically syncs the projected volume, so the file on disk is eventually updated. However, the application must watch for file changes and reload the configuration; many applications read the file only at startup. A delay up to the kubelet sync period and cache TTL can also occur, so the old value may still be seen temporarily.

Why this answer

The key fact is that volume-mounted ConfigMaps are eventually updated on disk by the kubelet, but the application must detect and reload the change. Environment variables from ConfigMaps are fixed at container start. The observed stale value is therefore explained by the application not reloading the file, possibly combined with the kubelet sync interval.

This is a common operational nuance.

Exam trap

The trap here is assuming that updating a ConfigMap immediately changes what a running application sees, when volume updates are eventual and environment variables are static.

Practice this question →

365

Multi-Selecteasy

Which two statements about Pods are true? (Select TWO)

Select 2 answers

A.A Pod can only contain one container

B.Containers in the same Pod share the same network namespace

C.A Pod is automatically recreated if its Node fails

D.A Pod is the smallest deployable unit in Kubernetes

E.Pods are always created directly by users

AnswersB, D

Containers within one Pod share a single network namespace, so they share an IP address and port space and communicate via localhost. This satisfies the shared-networking statement, distinguishing Pods from separate containers that each hold their own network stack.

Why this answer

Option B is correct because all containers within a single Pod share the same network namespace, meaning they share the same IP address and port space and can communicate with each other via localhost. Option D is correct because the Pod is the smallest deployable unit in Kubernetes; you cannot deploy or schedule a single container directly without wrapping it in a Pod. Option A is incorrect because a Pod can contain multiple containers (e.g., sidecar, ambassador, or adapter patterns) that are co-scheduled and co-located.

Option C is incorrect because a Pod is not automatically recreated if its Node fails; only Pods managed by a controller such as a ReplicaSet or Deployment are rescheduled and recreated. Option E is incorrect because users typically create Pods indirectly through controllers like Deployments, ReplicaSets, or StatefulSets, and bare Pods created directly are not rescheduled if they fail.

Exam trap

A common misconception is that a Pod is the smallest unit of scheduling and that it is automatically recreated on node failure, but the trap here is that Pods themselves are ephemeral and rely on controllers (such as ReplicaSets or Deployments) for recovery, not automatic recreation by the scheduler.

Practice this question →

366

MCQeasy

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

A.kubectl logs web-pod

B.kubectl get pod web-pod

C.kubectl describe pod web-pod

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

AnswerC

`kubectl describe pod web-pod` retrieves the pod's full status via the API server, showing events, container states, conditions and resource details — exactly the "detailed state" the stem requests. Unlike `get`, which returns summary columns, `describe` aggregates the diagnostic context needed to inspect a specific pod in the default namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

367

MCQeasy

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

A.Secret

B.ServiceAccount

C.ConfigMap

D.PersistentVolumeClaim

AnswerA

A Secret stores sensitive values such as the database password and can be injected into a pod as an environment variable, keeping credentials out of the image and manifest while granting the pod secure access.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

368

MCQmedium

You have a Deployment named 'web-app' with 3 replicas. You need to scale it to 5 replicas. Which kubectl command should you use?

A.kubectl create deployment web-app --replicas=5

B.kubectl scale deployment web-app --replicas=5

C.kubectl edit deployment web-app --replicas=5

D.kubectl describe deployment web-app

AnswerB

kubectl scale deployment web-app --replicas=5 updates the Deployment's spec.replicas field, causing the controller to reconcile from three to five pods. This satisfies the scaling requirement declaratively, unlike editing individual pods, which the ReplicaSet would not treat as desired state.

Why this answer

The `kubectl scale` command is the correct way to adjust the replica count of an existing Deployment. It directly modifies the `spec.replicas` field in the Deployment's desired state, instructing the ReplicaSet controller to create or delete Pods to match the new count. Option B uses the correct syntax `kubectl scale deployment web-app --replicas=5` to achieve this.

Exam trap

The trap here is that candidates confuse `kubectl create` with `kubectl scale`, thinking they can reuse the create command with a different replica count to update an existing Deployment, when in fact `create` is only for initial creation and will fail or overwrite the resource.

How to eliminate wrong answers

Option A is wrong because `kubectl create deployment` creates a new Deployment from scratch, not scaling an existing one; using `--replicas=5` would create a new Deployment named 'web-app' (or fail if it already exists), overwriting the original configuration and ignoring the existing 3 replicas. Option C is wrong because `kubectl edit deployment` opens an interactive editor for manual YAML/JSON modification, not a direct scaling command; the `--replicas` flag is not valid with `edit`, and the user would need to manually change the `spec.replicas` field, which is inefficient and error-prone. Option D is wrong because `kubectl describe deployment` only displays the current state and details of the Deployment, including its replica count, but does not perform any scaling action.

Practice this question →

369

Multi-Selecteasy

Which TWO of the following are responsibilities of the kubelet on a worker node?

Select 2 answers

A.Storing cluster state in etcd

B.Scheduling Pods onto the node

C.Implementing network rules for Services

D.Ensuring containers are running as specified in the PodSpec

E.Registering the node with the control plane

AnswersD, E

The kubelet acts as the node agent, watching the API server for PodSpecs bound to its node and starting, stopping and health-checking the corresponding containers. This directly satisfies the stem's requirement that containers run as specified in the PodSpec.

Why this answer

Option D is correct because the kubelet is the node agent that watches for PodSpecs assigned to its node and actively reconciles the actual container state to match the desired state, restarting or starting containers via the container runtime (e.g., containerd or CRI-O) so they run as specified. Option E is correct because the kubelet registers its node with the control plane by creating/updating the Node object through the API server, and it periodically reports node status and heartbeats. Option A is wrong because etcd is the cluster's distributed key-value store, written to by the API server, not by the kubelet.

Option B is wrong because Pod scheduling is performed by the kube-scheduler, which selects a node and binds the Pod; the kubelet only runs Pods already assigned to it. Option C is wrong because Service network rules (iptables/IPVS or eBPF load-balancing) are implemented by the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with that of kube-proxy or the scheduler, especially because the kubelet does interact with the API server and manages Pod lifecycle, but it does not perform scheduling or network rule enforcement.

Practice this question →

370

MCQhard

A Pod is in 'CrashLoopBackOff' state. You run 'kubectl logs <pod>' and see an error that the application cannot bind to port 8080 because the port is already in use. What is the most likely cause?

A.The container's health check is misconfigured

B.The container runtime is not installed

C.The Pod's resource limits are too low

D.Another process inside the container is already using port 8080

AnswerD

A second process within the same container has already bound port 8080, so the application's bind attempt fails with EADDRINUSE and the container exits, triggering CrashLoopBackOff. This satisfies the stem's constraint: the conflict occurs inside the container's network namespace, not from another Pod or Service.

Why this answer

The 'CrashLoopBackOff' state indicates the container repeatedly starts, fails, and is restarted by the kubelet. The error message 'port is already in use' means the application inside the container cannot bind to port 8080 because another process within the same container's network namespace is already listening on that port. This is a classic application-level conflict, not a Kubernetes configuration issue.

Exam trap

The trap here is that candidates may confuse a container-level port conflict with a Kubernetes-level port conflict (e.g., hostPort or NodePort collision), but the error originates from inside the container's own network namespace, not from the host or cluster networking layer.

How to eliminate wrong answers

Option A is wrong because a misconfigured health check (e.g., liveness or readiness probe) would cause the Pod to be restarted due to probe failures, but the specific error 'port is already in use' is not a probe-related message; it is a bind system call failure. Option B is wrong because if the container runtime were not installed, the Pod would never reach the 'Running' state, let alone 'CrashLoopBackOff'; the kubelet would fail to start the container entirely. Option C is wrong because insufficient resource limits (CPU/memory) would cause the container to be OOMKilled or throttled, resulting in 'OOMKilled' or 'CrashLoopBackOff' with resource-related errors, not a 'port already in use' bind error.

Practice this question →

371

MCQmedium

You have a pod that needs to securely access a database password. Which Kubernetes resource should you use to store the password?

A.ServiceAccount

B.Secret

C.ConfigMap

D.PersistentVolume

AnswerB

Secrets store sensitive data such as passwords separately from pod specs and images, and can be mounted or injected as environment variables. This satisfies the need for secure access to the database credential rather than embedding it in plain ConfigMaps.

Why this answer

A Kubernetes Secret is specifically designed to store sensitive data, such as database passwords, in a base64-encoded format. Secrets can be mounted as volumes or exposed as environment variables in a pod, ensuring the password is not stored in plaintext in the pod specification or container image.

Exam trap

The trap here is that candidates often confuse ConfigMaps with Secrets, assuming both can store sensitive data, but ConfigMaps store data in plaintext and lack the security features of Secrets, such as encryption at rest and RBAC controls.

How to eliminate wrong answers

Option A is wrong because a ServiceAccount is an identity for processes running in a pod, used for authentication to the Kubernetes API server, not for storing sensitive data like passwords. Option C is wrong because a ConfigMap is intended for non-confidential configuration data, such as environment variables or configuration files, and does not provide encryption or security for sensitive values. Option D is wrong because a PersistentVolume is a storage resource for persistent data in a cluster, not a mechanism for storing secrets or passwords.

Practice this question →

372

Multi-Selecthard

Which three of the following are true about etcd in Kubernetes?

Select 3 answers

A.etcd stores all cluster state, including Pods, ConfigMaps, and Secrets

B.etcd is a relational database

C.etcd is a distributed, consistent key-value store

D.etcd can be used as a message queue

E.etcd supports watches to monitor changes to keys

AnswersA, C, E

etcd is the sole persistent backing store for the Kubernetes API server, holding every object's serialised state — Pods, ConfigMaps, Secrets and more — in a consistent, watchable key-value store. This satisfies the stem's requirement that cluster state, including those three resource types, resides in etcd.

Why this answer

Option A is correct because etcd is the backing store for the Kubernetes API server, persisting the entire cluster state — every object such as Pods, ConfigMaps, Secrets, Deployments, and ServiceAccounts — as serialized data under keys like /registry/pods. Option C is correct because etcd is architecturally a distributed, strongly consistent key-value store built on the Raft consensus algorithm, which guarantees linearizable reads and writes across its cluster members. Option E is correct because etcd exposes a watch API that lets clients subscribe to a key or key range and receive streaming notifications whenever those keys change, which is exactly how the Kubernetes API server drives its informers and controllers.

Option B is wrong because etcd is not relational: it has no tables, schemas, joins, or SQL, only a flat hierarchical keyspace. Option D is wrong because etcd is not a message queue; it offers no publish/subscribe topics, consumer groups, or delivery guarantees like RabbitMQ or Kafka, and using it as one is an anti-pattern.

Exam trap

The trap here is that candidates may confuse etcd's watch functionality with message queuing, or incorrectly assume that any database with key-value storage is relational, leading them to select options B or D.

Practice this question →

373

Multi-Selectmedium

Which TWO statements about Kubernetes Services are correct?

Select 2 answers

A.A Service can expose only one container port

B.A Service can only route traffic to pods on the same node as the Service

C.The default Service type is ClusterIP

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

E.A Service of type NodePort exposes the service only on the node where the pod is running

AnswersC, D

If no type is specified, ClusterIP is used.

Why this answer

The default Service type in Kubernetes is ClusterIP, which exposes the Service on a cluster-internal IP address. This means the Service is only reachable from within the cluster, providing a stable internal endpoint for pod-to-pod communication without external exposure.

Exam trap

The KCNA exam often tests the misconception that a Service can only expose one port or that NodePort is node-specific, when in fact multiple ports are supported and NodePort opens the port on every node in the cluster.

Practice this question →

374

MCQmedium

What is the function of kube-proxy on a worker node?

A.It ensures the desired number of pods are running

B.It runs the container runtime

C.It reports node status to the control plane

D.It implements part of the Kubernetes Service concept by managing network rules

AnswerD

kube-proxy watches Services and Endpoints via the API server, then programs iptables or IPVS rules on each node to load-balance traffic to backing pods. This implements the Service abstraction's virtual IP and routing behaviour at the data plane.

Why this answer

kube-proxy runs on each worker node and is responsible for implementing the Kubernetes Service abstraction by managing network rules (e.g., iptables, IPVS, or userspace mode). It watches the API server for Service and EndpointSlice changes and configures local packet filtering or forwarding rules to route traffic to the correct backend pods, enabling load balancing and service discovery.

Exam trap

A common misconception is that kube-proxy handles pod lifecycle or node health reporting, when in fact those are kubelet responsibilities. Candidates often confuse the 'proxy' name with general node management.

How to eliminate wrong answers

Option A is wrong because ensuring the desired number of pods are running is the function of the ReplicaSet controller and the kubelet, not kube-proxy. Option B is wrong because running the container runtime (e.g., containerd, CRI-O) is the responsibility of the kubelet, which interacts with the CRI, while kube-proxy handles network proxying. Option C is wrong because reporting node status to the control plane is a core function of the kubelet, which sends NodeStatus updates via the Kubernetes API, not kube-proxy.

Practice this question →

375

MCQhard

A pod has resource requests set to 'cpu: 500m' and 'memory: 256Mi'. The node has 2 CPU cores and 4Gi memory. How many pods with the same resource requests can be scheduled on that node, assuming no other pods?

A.2

B.4

C.8

D.16

AnswerB

Scheduling is governed by requests, not limits. Memory allows 4Gi ÷ 256Mi = 16 pods; CPU allows 2000m ÷ 500m = 4 pods. The CPU request is the binding constraint, so exactly 4 pods fit on the node.

Why this answer

Each pod requests 0.5 CPU cores (500m) and 256 MiB of memory. The node has 2 CPU cores, so the CPU limit allows 2 / 0.5 = 4 pods. The node has 4 GiB of memory (4096 MiB), so the memory limit allows 4096 / 256 = 16 pods.

The tighter constraint is CPU, which permits exactly 4 pods. Option B is correct.

Exam trap

Candidates often mistakenly calculate the maximum number of pods based on memory (16) instead of CPU (4), since memory appears less restrictive. However, CPU is the tighter constraint in this scenario.

How to eliminate wrong answers

Option A is wrong because it assumes only 2 pods can fit, likely confusing the 2 CPU cores with the number of pods without dividing by the per-pod request of 500m. Option C is wrong because 8 pods would require 8 * 500m = 4 CPU cores, which exceeds the node's 2 cores. Option D is wrong because 16 pods would require 16 * 500m = 8 CPU cores, far beyond the node's capacity, even though memory alone could support 16 pods.

Practice this question →