CCNA Kubernetes Fundamentals Questions — Page 6 of 6

376

MCQmedium

You need to securely store a database password for use by a Pod. Which Kubernetes resource should you use?

A.Secret

B.PersistentVolumeClaim

C.ServiceAccount

D.ConfigMap

AnswerA

Secrets hold sensitive data such as passwords, tokens and keys, base64-encoded and mountable into pods as volumes or environment variables. They keep credentials out of image layers and plain pod specs, satisfying the secure storage requirement.

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 mounted as a volume or injected as an environment variable into a Pod. Unlike ConfigMaps, Secrets are designed for confidential information and support optional encryption at rest when enabled in the cluster. This ensures the password is not stored in plaintext in the Pod specification or version control.

Exam trap

CNCF often tests the misconception that ConfigMaps are suitable for all configuration data, including sensitive values, but the KCNA exam expects you to know that Secrets are the dedicated resource for confidential information like passwords and API keys.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it is used to request storage volumes for Pods, not to store sensitive configuration data like passwords. Option C (ServiceAccount) is wrong because it provides an identity for Pods to authenticate with the Kubernetes API server, not a mechanism for storing secrets. Option D (ConfigMap) is wrong because it is intended for non-sensitive configuration data; storing a password in a ConfigMap would expose it in plaintext and violate security best practices.

Practice this question →

377

MCQmedium

A platform team needs to ensure that a critical StatefulSet pod always runs on a specific node that has local NVMe storage. The node is labeled `disktype=nvme`. Which Kubernetes scheduling mechanism should they use to guarantee this placement?

A.nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution

B.Taints and tolerations on the node

C.nodeName field in the Pod spec

D.podAffinity with preferredDuringSchedulingIgnoredDuringExecution

AnswerA

This is correct because requiredDuringSchedulingIgnoredDuringExecution enforces a hard constraint: the pod will only be scheduled on a node matching the specified label selector. In this scenario, the team can specify a nodeAffinity rule requiring the label disktype=nvme, ensuring the StatefulSet pod always lands on the node with local NVMe storage. This satisfies the guarantee requirement without manual intervention.

Why this answer

The requirement is a guaranteed placement on a node with a specific label. nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution enforces a hard rule that the pod must be scheduled on a node matching the label selector. This is the standard, declarative way to pin pods to nodes based on labels, and it works well with StatefulSets. Other options either provide only soft preferences, do not attract pods, or bypass the scheduler in a non-idiomatic way.

Exam trap

The trap here is confusing taints and tolerations with node selection: tolerations only allow a pod to be scheduled on a tainted node, but they do not require the pod to go there.

Practice this question →

378

Multi-Selectmedium

Which TWO of the following are characteristics of a Namespace in Kubernetes?

Select 2 answers

A.Namespaces are required for all Kubernetes objects

B.Namespaces provide network isolation by default

C.Resource names must be unique within a namespace, but can be reused across namespaces

D.Namespaces allow multiple virtual clusters within a physical cluster

E.Deleting a namespace deletes all objects inside it

AnswersC, D

Namespaced object names are scoped to their namespace, so two namespaces may each contain a pod named web. Cluster-scoped resources such as nodes and PersistentVolumes are exempt, which is why the uniqueness boundary is the namespace.

Why this answer

Option D is correct because a Kubernetes Namespace partitions a single physical cluster into multiple virtual clusters, letting teams or projects share the same underlying nodes and control plane while keeping their objects logically separated. Option C is correct because object names (for namespaced resources such as Pods, Services, and Deployments) must be unique within a given namespace, yet the same name can be reused in a different namespace since the namespace scopes the name. Option A is wrong because many Kubernetes objects are cluster-scoped and do not live in a namespace, such as Nodes, PersistentVolumes, StorageClasses, and ClusterRoles.

Option B is wrong because namespaces do not provide network isolation by default; Pods in different namespaces can communicate freely unless a NetworkPolicy is applied. Option E is wrong because although deleting a namespace typically garbage-collects its contents, that is a consequence of deletion rather than a defining characteristic of a namespace, and it is not one of the two marked correct answers.

Exam trap

CNCF often tests the misconception that Namespaces provide built-in network isolation, but in reality, they only offer logical grouping; network segmentation requires explicit NetworkPolicy resources.

Practice this question →

379

MCQhard

A pod in the 'default' namespace cannot reach a pod in the 'backend' namespace by service name 'db-service'. Both namespaces exist and the service is running. What is the most likely cause?

A.The pod does not have network policy allowing cross-namespace traffic

B.The service is not exposed on a port

C.The kube-proxy is not running

D.The pod is using the wrong service name format for cross-namespace access

AnswerD

Cross-namespace DNS resolution requires the fully qualified domain name `db-service.backend.svc.cluster.local`; a bare service name resolves only within the pod's own namespace. Since the stem confirms both namespaces and the service exist, the wrong name format is the most likely cause of the failed lookup.

Why this answer

D is correct because in Kubernetes, a pod in one namespace cannot reach a service in another namespace using just the service name (e.g., 'db-service'). Cross-namespace service discovery requires the fully qualified DNS name in the format <service>.<namespace>.svc.cluster.local (e.g., 'db-service.backend.svc.cluster.local'). Using only the service name resolves within the same namespace, causing the connection to fail.

Exam trap

The trap here is that candidates assume service names are globally unique across namespaces, but Kubernetes DNS scopes them to the namespace, so cross-namespace access requires the fully qualified domain name (FQDN).

How to eliminate wrong answers

Option A is wrong because network policies are not enabled by default and are not required for basic DNS-based cross-namespace communication; the issue here is DNS resolution, not network policy. Option B is wrong because if the service were not exposed on a port, it would not be reachable even within its own namespace, and the question states the service is running, implying it has a defined port. Option C is wrong because kube-proxy handles traffic routing within the cluster, but the failure occurs at the DNS resolution stage, not at the routing layer; if kube-proxy were not running, intra-namespace service access would also fail.

Practice this question →

380

MCQhard

A pod in the 'default' namespace has the following YAML snippet: securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 What is the effect of the fsGroup field?

A.It restricts the pod to run only on nodes with that group ID.

B.It sets the group ID for any volumes mounted into the pod.

C.It defines the group ID for the pod's service account.

D.It sets the group ID for the container's main process.

AnswerB

fsGroup applies a supplementary group ID to all processes in the pod and changes ownership of mounted volume contents, so files become group-writable. This satisfies the stem's question about volume group ownership, distinct from runAsGroup, which sets the primary group for the container process itself.

Why this answer

The `fsGroup` field in a Pod's security context sets the group ID (GID) that will be used for ownership of any volumes mounted into the pod. When a volume is mounted, Kubernetes recursively changes the group ownership of the volume's files to the specified GID (2000 in this case) and makes them readable and writable by that group. This ensures that processes running in the container, which may have a different primary group (3000 from `runAsGroup`), can still access the volume files if they are members of the fsGroup.

Exam trap

A common trap is confusing the role of `runAsGroup` (which sets the primary GID of the container process) with `fsGroup` (which sets the group ownership of mounted volumes), leading candidates to incorrectly select option D.

How to eliminate wrong answers

Option A is wrong because `fsGroup` does not restrict pod scheduling to nodes with a specific group ID; node affinity or taints/tolerations control node selection. Option C is wrong because the pod's service account group ID is unrelated to `fsGroup`; service accounts are managed via Kubernetes RBAC and do not have a group ID field in the security context. Option D is wrong because the group ID for the container's main process is set by `runAsGroup`, not `fsGroup`; `fsGroup` only affects volume file ownership, not the process's GID.

Practice this question →

381

MCQhard

A developer needs to inject configuration data into a pod as environment variables and also mount a configuration file into a volume. The data should be decoupled from the pod specification and easily updatable without rebuilding the container image. Which Kubernetes resource should be used?

A.Secret

B.PersistentVolumeClaim

C.Downward API

D.ConfigMap

AnswerD

ConfigMap is intended for non-confidential configuration data in key-value pairs. It can be consumed as environment variables, command-line arguments, or configuration files in a volume. It decouples configuration from pod specifications, allowing updates without rebuilding images. This exactly matches the requirement to inject configuration data and mount a configuration file, making ConfigMap the correct choice.

Why this answer

ConfigMap is the standard Kubernetes resource for storing non-sensitive configuration data. It can be consumed as environment variables or mounted as files, and it separates configuration from pod definitions, allowing updates without image rebuilds. Secret is for sensitive data, Downward API for metadata, and PersistentVolumeClaim for storage, so ConfigMap is the correct answer.

Exam trap

The trap here is confusing ConfigMap with Secret; while both can inject data, ConfigMap is for non-sensitive configuration and is the appropriate choice when sensitivity is not mentioned.

Practice this question →

382

Multi-Selectmedium

Which TWO of the following are valid ways to assign a pod to a specific node?

Select 2 answers

A.nodeSelector

B.affinity: nodeAntiAffinity

C.tolerations

D.nodeName

E.podSelector

AnswersA, D

nodeSelector matches pods to nodes via labels, satisfying the requirement to pin a pod to a specific node. You add a label to the target node, then reference it under `spec.nodeSelector` in the pod manifest; the scheduler only places the pod on nodes carrying that exact label.

Why this answer

Option A (nodeSelector) is correct because it is a field in the pod spec that matches against node labels, causing the scheduler to place the pod only on nodes carrying the specified label key/value pairs. Option D (nodeName) is correct because setting spec.nodeName bypasses the scheduler entirely and directly binds the pod to the named node, which is a valid (if low-level) way to assign a pod to a specific node. Option B (affinity: nodeAntiAffinity) is incorrect because node anti-affinity repels pods from nodes matching certain labels rather than assigning a pod to a specific node.

Option C (tolerations) is incorrect because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not target a specific node. Option E (podSelector) is incorrect because podSelector is used in resources like NetworkPolicy, PodDisruptionBudget, and topology spread constraints to select pods, not to assign a pod to a node.

Exam trap

CNCF often tests the distinction between mechanisms that *constrain* scheduling (like nodeSelector and nodeAffinity) versus mechanisms that *permit* scheduling (like tolerations), and candidates mistakenly think tolerations can force a pod to a specific node when they only allow it to be scheduled on tainted nodes.

Practice this question →

383

MCQhard

You run 'kubectl logs my-pod' and see: "Error from server (BadRequest): container "my-container" in pod "my-pod" is waiting to start: PodInitializing". What does this mean?

A.The container is running but producing no output

B.The container runtime is failing to start the container

C.The container has crashed and is restarting

D.The Pod is in the process of initializing and logs are not yet available

AnswerD

The BadRequest arises because the container is still in the PodInitializing phase, so its log stream does not exist yet. Init containers or image pulls must finish before the kubelet starts the main container, at which point 'kubectl logs' will return output.

Why this answer

The error 'PodInitializing' indicates that the pod's init containers are still running or the main container is waiting for init containers to complete. During this phase, the container has not started, so logs are not yet available. Option D correctly identifies that the pod is initializing and logs cannot be retrieved until the container enters the 'Running' state.

Exam trap

The trap here is that candidates confuse 'PodInitializing' with a container runtime failure or crash loop, when in fact it is a normal waiting state caused by init containers or pod initialization, not an error condition.

How to eliminate wrong answers

Option A is wrong because 'PodInitializing' means the container has not started, so it cannot be running or producing output. Option B is wrong because the error does not indicate a runtime failure; it simply means the container is waiting to start, which is a normal part of the pod lifecycle when init containers are executing. Option C is wrong because a crash loop would show 'CrashLoopBackOff' or 'Error' status, not 'PodInitializing', which is a transient state before the container starts.

Practice this question →

384

MCQeasy

An operations team wants a workload that runs exactly one Pod on every node in the cluster, including nodes added later, typically for log forwarding and node monitoring. Which Kubernetes workload resource is designed for this?

A.StatefulSet

B.DaemonSet

C.Job

D.Deployment

AnswerB

DaemonSet is purpose-built to run a copy of a Pod on every eligible node, and the DaemonSet controller automatically creates Pods for nodes that join the cluster later. It is the standard choice for node-level agents such as log shippers, monitoring exporters, and CNI or storage daemons. Taints and node selectors can scope which nodes receive the Pod, which is why control-plane nodes often need explicit tolerations.

Why this answer

A DaemonSet ensures one Pod per eligible node and extends coverage automatically as nodes join, which matches the requirement for log forwarding and node monitoring. Unlike replica-count workloads, it is node-centric rather than count-centric, and it honors taints, tolerations, and node selectors to decide which nodes receive the agent Pod.

Exam trap

The trap here is confusing count-based controllers such as Deployments with node-based coverage, which only DaemonSet guarantees.

Practice this question →

385

MCQmedium

Which of the following is NOT a responsibility of the kubelet on a worker node?

A.Performing liveness and readiness probes

B.Starting and stopping containers based on PodSpecs

C.Implementing network rules for Services

D.Reporting node and pod status to the control plane

AnswerC

Service network rules are implemented by kube-proxy, which programs iptables or IPVS rules on each node. The kubelet instead manages Pod lifecycle, volumes, and container runtime interaction, so network rule implementation falls outside its responsibilities.

Why this answer

The kubelet is the primary node agent that runs on each worker node, responsible for ensuring containers are running in a Pod as specified by the PodSpec. It performs liveness and readiness probes, starts and stops containers, and reports node and pod status to the control plane. Implementing network rules for Services, such as iptables or IPVS rules, is the responsibility of the kube-proxy, not the kubelet.

Exam trap

The trap here is that candidates often confuse the kubelet's role with kube-proxy's role, assuming the kubelet handles all networking on the node, including Service traffic routing.

How to eliminate wrong answers

Option A is wrong because the kubelet is responsible for executing liveness and readiness probes against containers and taking action based on their results (e.g., restarting containers). Option B is wrong because the kubelet directly manages container lifecycle by communicating with the container runtime (e.g., containerd, CRI-O) to start and stop containers as defined in the PodSpec. Option D is wrong because the kubelet periodically reports the node's condition and the status of each Pod to the API server via the NodeStatus and PodStatus updates.

Practice this question →

386

MCQmedium

What is the role of kube-scheduler in Kubernetes?

A.To assign pods to nodes

B.To run container health checks

C.To store cluster configuration

D.To provide network rules for services

AnswerA

The scheduler watches for newly created Pods with no assigned node and selects a suitable node based on resource requests, affinity rules, taints and tolerations. It writes that binding to the API server, satisfying the stem's constraint that pods must be placed onto nodes.

Why this answer

The kube-scheduler is responsible for selecting an optimal node for newly created pods that have not yet been assigned to a node. It evaluates constraints such as resource requirements, affinity/anti-affinity rules, and data locality, then binds the pod to the chosen node via the Kubernetes API. This makes option A correct because scheduling is the scheduler's primary and defining function.

Exam trap

A common misconception is that the scheduler also manages pod lifecycle or health checks, leading candidates to confuse the scheduler's static assignment role with the kubelet's dynamic runtime responsibilities.

How to eliminate wrong answers

Option B is wrong because container health checks (liveness, readiness, and startup probes) are executed by the kubelet on the node where the pod is running, not by the kube-scheduler. Option C is wrong because cluster configuration is stored in etcd, a distributed key-value store, and the kube-scheduler does not persist any configuration data. Option D is wrong because network rules for Services (e.g., iptables or IPVS rules) are managed by the kube-proxy component, not the scheduler.

Practice this question →

387

MCQeasy

A Pod has a container that needs to write logs to a file. The administrator wants the logs to persist even if the container restarts. What is the simplest solution?

A.Use a PersistentVolumeClaim for each container.

B.Use a hostPath volume to write logs directly to the node filesystem.

C.Store logs in a ConfigMap.

D.Use an emptyDir volume and mount it at the log path.

AnswerD

An emptyDir volume is created when the Pod is assigned to a node and survives container restarts within that Pod, so log files written to the mounted path persist across a container crash. It satisfies the persistence requirement without the complexity of a PersistentVolume claim.

Why this answer

An emptyDir volume provides a simple, ephemeral storage solution that persists across container restarts within the same Pod. When a container crashes and is restarted by the kubelet, the emptyDir volume's contents remain intact, allowing log files to survive container restarts without requiring external storage or complex configuration.

Exam trap

CNCF often tests the misconception that container restarts always wipe all data, leading candidates to choose persistent storage options like PVCs or hostPath, when in fact emptyDir volumes are specifically designed to survive container restarts within the same Pod.

How to eliminate wrong answers

Option A is wrong because a PersistentVolumeClaim (PVC) is designed for durable, long-term storage that survives Pod deletion and rescheduling, which is overkill for simple log persistence across container restarts and adds unnecessary complexity. Option B is wrong because a hostPath volume ties the Pod to a specific node and poses security risks (e.g., allowing container access to the host filesystem), and it is not the simplest solution for log persistence within a Pod. Option C is wrong because a ConfigMap is intended for storing configuration data (e.g., key-value pairs, small files) and is not designed for dynamic, writable log output; ConfigMaps are read-only when mounted and cannot be written to by containers.

Practice this question →

388

MCQmedium

A developer deploys a pod with the following resource specification: ```yaml resources: requests: memory: "256Mi" limits: memory: "512Mi" ``` The pod is killed with OOMKilled. What is the most likely cause?

A.The container exceeded the memory request of 256Mi

B.The node ran out of memory

C.The CPU limit was too low

D.The container exceeded the memory limit of 512Mi

AnswerD

The kernel OOM killer terminates a container when its memory usage breaches the configured limit of 512Mi. Requests of 256Mi only influence scheduling, not termination. Exceeding the limit is therefore the cause of the OOMKilled status described in the stem.

Why this answer

The OOMKilled exit code indicates the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it attempted to use more memory than its configured limit of 512Mi. Kubernetes enforces memory limits using cgroups; when the container exceeds the limit, the kernel kills the process, resulting in the OOMKilled status.

Exam trap

CNCF often tests the distinction between requests and limits, trapping candidates who think exceeding a request causes termination, when in fact only exceeding the limit triggers OOMKilled.

How to eliminate wrong answers

Option A is wrong because exceeding the memory request of 256Mi does not cause termination; requests are used for scheduling and guaranteed QoS, not enforcement. Option B is wrong because node memory exhaustion would cause the node to evict pods or the OOM killer to target pods, but the pod's explicit memory limit is the direct cause here, not node-level pressure. Option C is wrong because CPU limits do not cause OOMKilled; CPU is a compressible resource, and exceeding CPU limits results in throttling, not termination.

Practice this question →

389

MCQeasy

Which Kubernetes control plane component is the primary entry point for all administrative tasks and serves the Kubernetes API?

A.kube-scheduler

B.kube-controller-manager

C.kube-apiserver

D.etcd

AnswerC

kube-apiserver serves the Kubernetes API and is the sole entry point for administrative tasks, validating and persisting every request to etcd. It satisfies the stem's requirement for the primary administrative entry point exposing the Kubernetes API.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the sole entry point for all administrative operations. It exposes the Kubernetes REST API, validates and processes requests (including authentication, authorization, and admission control), and updates the corresponding objects in etcd. Without the API server, no kubectl command, automation, or internal component communication can occur.

Exam trap

CNCF often tests the misconception that etcd is the primary entry point because it stores all cluster data, but the trap here is that etcd is a data store, not an API endpoint — all interactions must go through the kube-apiserver, which is the only component that communicates directly with etcd.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is responsible only for assigning newly created pods to nodes based on resource requirements and policies, not for serving the API or handling administrative tasks. Option B is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that watch the desired state via the API server, but it does not expose an API endpoint itself. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, but it is not the entry point for administrative tasks and does not serve the Kubernetes API.

Practice this question →

390

Multi-Selectmedium

A developer inspects a Pod and sees that it is stuck in the Pending phase. Which two conditions can legitimately cause a Pod to remain Pending? (Choose two.)

Select 2 answers

A.The Pod's container image cannot be pulled from the registry.

B.The Pod requests a PersistentVolumeClaim that is not yet bound and uses a storage class with WaitForFirstConsumer.

C.No node in the cluster satisfies the Pod's resource requests or node affinity rules.

D.The Pod's liveness probe is failing repeatedly.

E.The Pod's ServiceAccount token has expired.

AnswersB, C

With WaitForFirstConsumer binding mode, the volume is provisioned only after a node is chosen, and the scheduler holds the Pod until the claim is satisfiable. Until then the Pod remains Pending, which is expected behavior rather than a failure. This is a legitimate scheduling-related cause of the Pending phase.

Why this answer

A Pod stays Pending whenever the scheduler cannot place it or its volumes are not ready. Unsatisfiable resource requests, affinity rules, or taints block scheduling, and a WaitForFirstConsumer PersistentVolumeClaim deliberately delays binding until a node is chosen. Image pull errors, failed liveness probes, and token expiry all occur after scheduling and therefore do not cause the Pending phase.

Exam trap

The trap here is blaming image pull failures for a Pending Pod, when those failures happen after scheduling and surface as ImagePullBackOff.

Practice this question →

391

MCQmedium

An application Pod in the `web` namespace must read a configuration value stored in a ConfigMap named `app-config` without restarting when the value changes. The value is consumed as a file inside the container. Which approach meets this requirement?

A.Mount the ConfigMap as a volume and let the application re-read the file periodically.

B.Use a subPath volume mount of the ConfigMap key.

C.Set the ConfigMap as an immutable object and mount it as a volume.

D.Reference the ConfigMap with envFrom and rely on automatic environment refresh.

AnswerA

ConfigMaps projected as volumes are updated in place by the kubelet after a short sync delay, so a file-reading application that re-reads on its own sees new values without a Pod restart. This is the standard way to get live configuration updates. The application must still poll or watch the file, because the kubelet does not signal the process.

Why this answer

Volume-mounted ConfigMaps are periodically refreshed by the kubelet, so an application that re-reads its configuration file can pick up new values without a restart. Environment-variable injection and subPath mounts do not update at runtime, and immutable ConfigMaps cannot change at all, so the volume-mount approach is the only one that satisfies the scenario.

Exam trap

The trap here is believing that envFrom variables refresh automatically, when they are fixed at container start and never update.

Practice this question →

392

Multi-Selecthard

A platform engineer is designing a multi-tenant cluster and must ensure that Pods in different namespaces cannot communicate with each other by default, while allowing specific traffic within each namespace. Which two Kubernetes features are required to achieve this? (Choose two.)

Select 2 answers

A.Service mesh with mTLS enabled

B.ResourceQuota per namespace

C.A CNI plugin that supports NetworkPolicy enforcement

D.PodSecurityPolicy restricted to the namespace

E.NetworkPolicy with a default deny-all ingress rule in each namespace

AnswersC, E

NetworkPolicy resources are only enforced if the cluster's CNI plugin implements them. Plugins like Calico, Cilium, and Weave Net enforce policies, while some basic plugins like Flannel do not. Without a supporting CNI, NetworkPolicy objects are created but have no effect, leaving Pods unrestricted.

Why this answer

To achieve default-deny between namespaces, you need a NetworkPolicy that denies all ingress in each namespace and a CNI plugin that enforces NetworkPolicy. Without the policy, traffic is allowed by default; without a supporting CNI, the policy has no effect. Together they provide the required isolation and allow specific traffic via additional allow policies.

Exam trap

The trap here is assuming that creating a NetworkPolicy is sufficient, when in fact the cluster's CNI plugin must also support and enforce NetworkPolicy for the rules to take effect.

Practice this question →

393

MCQeasy

Which component of the Kubernetes control plane stores the cluster state?

A.etcd

B.kube-controller-manager

C.kube-scheduler

D.kube-apiserver

AnswerA

etcd is the control plane's distributed key-value store, persisting every Kubernetes object and cluster state. The API server is the only component that reads and writes it directly, making etcd the authoritative backing store for the cluster.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire Kubernetes cluster. It stores all cluster state data, including configuration, secrets, and the desired state of every object (Pods, Deployments, Services, etc.). The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes go through a consistent, versioned API.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the state store because it is the only component that interacts with etcd and serves the Kubernetes API, but the actual persistence layer is etcd itself.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller processes that reconcile the current cluster state with the desired state stored in etcd; it does not store state itself. Option C (kube-scheduler) is wrong because it assigns Pods to Nodes based on resource availability and constraints, reading state from the API server but never persisting state. Option D (kube-apiserver) is wrong because while it is the front-end that validates and processes all REST requests and acts as the gateway to etcd, it does not store the cluster state—it delegates persistence to etcd.

Practice this question →

394

MCQeasy

Which Kubernetes control plane component is responsible for storing the cluster state and configuration data?

A.kube-controller-manager

B.etcd

C.kube-apiserver

D.kube-scheduler

AnswerB

etcd is the distributed key-value store holding all cluster state, including object definitions, configuration and secrets, and is the only component the API server reads from and writes to. Losing etcd means losing the cluster's authoritative state, making it the control plane's backing store.

Why this answer

etcd is the distributed key-value store that serves as Kubernetes' single source of truth for all cluster state and configuration data. It stores objects like Pods, Services, Deployments, and Secrets, and is the only component that holds persistent state. The kube-apiserver reads from and writes to etcd, but etcd itself is the storage backend.

Exam trap

The exam often tests the misconception that kube-apiserver stores the cluster state because it is the central API endpoint, but the trap is that the API server is stateless and relies entirely on etcd for persistence.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state via the API server and makes changes to move the current state toward the desired state, but it does not store any data itself. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes RESTful requests, but it delegates all persistent storage to etcd and does not store cluster state locally. Option D is wrong because kube-scheduler is responsible for assigning Pods to Nodes based on resource availability and constraints, and it has no role in storing cluster configuration or state.

Practice this question →

395

Multi-Selectmedium

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

Select 2 answers

A.Assigning pods to nodes based on resource requirements

B.Ensuring the correct number of pod replicas are running

C.Implementing network rules for Services

D.Monitoring node health and responding to node failures

E.Storing the cluster state

AnswersB, D

The kube-controller-manager runs the ReplicaSet controller, which continuously reconciles the observed replica count against the desired count declared in the ReplicaSet spec, creating or deleting pods to close any gap. This directly satisfies the stem's requirement to maintain the correct number of running pod replicas.

Why this answer

Option B is correct because the kube-controller-manager runs the ReplicationController/ReplicaSet controller, which continuously reconciles the desired replica count in a workload's spec with the actual number of running pods, creating or deleting pods as needed. Option D is correct because the kube-controller-manager includes the node controller, which monitors node heartbeats/status and reacts to node failures by marking nodes NotReady and evicting or rescheduling their pods (subject to tolerations). Option A is not a kube-controller-manager responsibility; pod-to-node assignment is performed by the kube-scheduler.

Option C is not correct because Service network rules are implemented by the kube-proxy component (and/or CNI/iptables/IPVS), not the kube-controller-manager. Option E is not correct because cluster state is stored in etcd, the distributed key-value store, not by the kube-controller-manager.

Exam trap

The trap here is that candidates often confuse the kube-controller-manager's role in node health monitoring with the kube-scheduler's role in pod placement, or they mistakenly think the controller-manager handles network rules, which is actually done by kube-proxy.

Practice this question →

396

MCQmedium

A Deployment is configured with 'replicas: 4' and 'strategy.type: RollingUpdate'. You update the container image. What behavior does the Deployment exhibit?

A.The Deployment creates 8 Pods total, 4 old and 4 new

B.All 4 Pods are deleted immediately and then 4 new Pods are created

C.New Pods are created before old ones are terminated, one at a time

D.The update is paused until manually resumed

AnswerC

RollingUpdate replaces Pods incrementally, so the Deployment creates new Pods before terminating old ones, honouring the default maxSurge and maxUnavailable settings. This satisfies the requirement that the update proceeds without downtime, scaling the new ReplicaSet up gradually while the old ReplicaSet scales down, one Pod at a time.

Why this answer

With a RollingUpdate strategy, the Deployment controller replaces old Pods with new ones incrementally to ensure zero downtime. By default, it creates new Pods before terminating old ones (maxSurge=25%, maxUnavailable=25%), so one new Pod is created first, then one old Pod is terminated, repeating until all 4 Pods run the new image.

Exam trap

The trap here is that candidates confuse RollingUpdate with Recreate (Option B) or assume all Pods are replaced simultaneously (Option A), failing to recognize the incremental, surge-based behavior controlled by maxSurge and maxUnavailable defaults.

How to eliminate wrong answers

Option A is wrong because a RollingUpdate does not create 8 Pods simultaneously; it creates at most 1 extra Pod (maxSurge=25% of 4 = 1) beyond the desired 4, so the total is 5, not 8. Option B is wrong because deleting all Pods immediately is a Recreate strategy, not RollingUpdate, which would cause downtime. Option D is wrong because the update is not paused; a paused update requires explicitly setting 'paused: true' in the Deployment spec, which is not mentioned in the question.

Practice this question →

397

MCQmedium

Your application requires persistent storage that must be available across pod restarts and rescheduling. What is the recommended approach?

A.Store data in the container's writable layer

B.Use hostPath volume

C.Use an emptyDir volume

D.Use a PersistentVolumeClaim (PVC) and mount it into the pod

AnswerD

A PersistentVolumeClaim decouples storage lifecycle from the pod, binding to a PersistentVolume that survives restarts and rescheduling. This satisfies the requirement for persistent storage across pod lifecycles, unlike emptyDir or container filesystem storage, which are ephemeral and tied to the pod's lifetime.

Why this answer

PersistentVolumeClaim (PVC) is the recommended approach because it decouples storage provisioning from pod lifecycle, ensuring data persists across pod restarts and rescheduling. PVCs request storage from a PersistentVolume (PV) that is backed by a physical storage system (e.g., NFS, cloud block storage), and the pod mounts this volume, allowing the data to survive even if the pod is deleted and recreated on a different node.

Exam trap

The trap here is that candidates often confuse emptyDir or hostPath as persistent storage because they survive container restarts within the same pod, but they fail to recognize that these volumes do not survive pod deletion or rescheduling to a different node.

How to eliminate wrong answers

Option A is wrong because the container's writable layer is ephemeral and tied to the container's lifecycle; data is lost when the container restarts or the pod is rescheduled. Option B is wrong because hostPath volumes tie storage to a specific node's filesystem, so if the pod is rescheduled to a different node, the data is not accessible, and it also poses security risks by exposing node filesystem. Option C is wrong because emptyDir volumes are created empty when a pod starts and are deleted when the pod is removed; they share data between containers in the same pod but do not persist across pod restarts or rescheduling.

Practice this question →

398

MCQmedium

You want to update a Deployment's container image to v2 and perform a rolling update using the simplest imperative command. Which kubectl command achieves this?

A.kubectl update deployment my-deployment --image=myapp:v2

B.kubectl replace -f updated-deployment.yaml

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

D.kubectl set image deployment/my-deployment my-container=myapp:v2 --record

AnswerD

`kubectl set image` patches the Deployment's pod template in place, triggering the rolling update strategy already defined on the Deployment. It satisfies the stem's imperative and simplest constraints, updating only the named container's image to v2 without editing YAML. The `--record` flag annotates the revision, aiding rollback history.

Why this answer

The `kubectl set image` command is the standard imperative way to update a container image in a Deployment, and it automatically triggers a rolling update. Option A is invalid; `kubectl update` is not a real command. Option B, `kubectl replace`, requires a full YAML file and is a declarative replacement operation, not a simple image update command.

Option C, `kubectl patch`, can be used but is overly complex and error-prone for a simple image update. The question asks for the simplest imperative command, making D the best answer.

Exam trap

A common pitfall is assuming that `kubectl update` is a valid command (it is not) or that `kubectl patch` is the simplest approach. While `kubectl patch` can update the image, it is not the simplest or most direct imperative command for this task.

How to eliminate wrong answers

Option A is wrong because `kubectl update` is not a valid kubectl command; the correct imperative command for updating a Deployment's image is `kubectl set image`. Option B is wrong because `kubectl replace -f updated-deployment.yaml` performs a full replacement of the Deployment object, which is a declarative approach that does not inherently trigger a rolling update; it replaces the entire resource definition, potentially causing downtime if not managed carefully. Option C is wrong because while `kubectl patch` can update the container image, it requires a complex JSON patch and does not automatically trigger a rolling update unless the patch modifies the pod template spec; however, it is less straightforward and not the recommended imperative command for this specific task.

Practice this question →

399

MCQmedium

A Service of type ClusterIP is created to expose a set of pods. How does the Service achieve load balancing to the pods?

A.The API server routes traffic directly to the pods

B.The kube-proxy component on each node sets up network rules to forward traffic to the pods

C.The kubelet configures the container runtime to route traffic

D.Using a cloud load balancer

AnswerB

Kube-proxy runs on every node and programs iptables or IPVS rules that intercept traffic destined for the ClusterIP, then forwards each connection to one of the backing pod endpoints. This satisfies the stem's load-balancing requirement, distributing traffic across pods without any external load balancer.

Why this answer

Kube-proxy on each node implements load balancing for ClusterIP Services by creating iptables or IPVS rules that distribute traffic from the Service's virtual IP to the backend pods. These rules use a random or round-robin selection (depending on the mode) to forward packets to healthy pods, ensuring no single pod is overwhelmed.

Exam trap

A common trap is confusing the control-plane role of the API server with the data-plane role of kube-proxy. The API server does not handle data-plane traffic for Services.

How to eliminate wrong answers

Option A is wrong because the API server does not handle data-plane traffic; it only manages the control plane and stores Service definitions in etcd, while actual packet forwarding is done by kube-proxy. Option C is wrong because kubelet is responsible for managing pod lifecycle and container runtime configuration, not for setting up network routing rules for Services. Option D is wrong because a cloud load balancer is used for Services of type LoadBalancer, not ClusterIP, which is an internal virtual IP only reachable within the cluster.

Practice this question →

400

Multi-Selectmedium

Which two of the following are Kubernetes controllers that run inside the kube-controller-manager? (Select TWO)

Select 2 answers

A.kubelet

B.Replication controller

C.etcd

D.Node controller

E.kube-scheduler

AnswersB, D

The replication controller is a legacy control loop bundled inside kube-controller-manager, which maintains the desired pod replica count for its selector. It satisfies the stem's requirement of running within that manager rather than as a standalone control plane component, unlike the scheduler or kubelet.

Why this answer

The Replication controller (B) is correct because it is a built-in controller that runs within the kube-controller-manager process, continuously reconciling the desired number of pod replicas with the actual state by creating or deleting pods. The Node controller (D) is also correct because it is another controller embedded in the kube-controller-manager, responsible for monitoring node health, applying taints like node.kubernetes.io/not-ready, and evicting pods from unreachable nodes. The kubelet (A) is not part of the kube-controller-manager; it is a node-level agent that runs on each worker node and manages pod lifecycle via the container runtime. etcd (C) is the distributed key-value store that persists cluster state, not a controller, and it runs as a separate process.

The kube-scheduler (E) is a separate control-plane component that assigns pods to nodes and runs independently of the kube-controller-manager.

Exam trap

The exam often tests the distinction between control plane components (kube-controller-manager, kube-scheduler, etcd) and node agents (kubelet). Many candidates mistakenly think kubelet is a controller because it manages pods locally, but it runs on each node as a separate binary, not inside the kube-controller-manager.

Practice this question →