Courseiva

CCNA Storage Questions

31 questions · Storage · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

A.A hostPath volume
B.A PersistentVolume with access mode ReadWriteOnce
C.A PersistentVolume with access mode ReadWriteMany
D.An emptyDir volume
AnswerC

A PersistentVolume with access mode ReadWriteMany allows multiple pods across different nodes to simultaneously read and write to the same storage volume, satisfying the stem’s requirement for concurrent access from pods scheduled on distinct nodes. This access mode directly addresses the constraint of multi-node, multi-pod stateful workloads, whereas ReadWriteOnce would restrict access to a single node.

Why this answer

ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, but RWO restricts access to a single node, not a single pod, so multiple pods on the same node can share an RWO volume, but pods on different nodes cannot, making it unsuitable for the stated requirement.

How to eliminate wrong answers

Option A is wrong because a hostPath volume mounts a directory from the host node's filesystem into the pod, which does not support multi-node access; pods scheduled on different nodes would see different host directories, and it is not a persistent storage abstraction managed by Kubernetes. Option B is wrong because a PersistentVolume with access mode ReadWriteOnce (RWO) can only be mounted as read-write by a single node at a time, preventing concurrent access from pods on different nodes. Option D is wrong because an emptyDir volume is ephemeral and tied to the pod's lifecycle; it is created empty when a pod starts and is deleted when the pod is removed, providing no persistent storage across pod restarts or multi-node access.

Practice this question →
2
MCQeasy

Which of the following volume types is designed to store sensitive information such as passwords or tokens?

A.emptyDir
B.hostPath
C.secret
D.configMap
AnswerC

The Secret volume type is specifically designed to store and deliver sensitive data such as passwords, OAuth tokens, and SSH keys to containers. Secret objects are persisted in etcd, subject to RBAC authorization, and can be encrypted at rest via EncryptionConfiguration. When mounted as volumes, they are exposed as files in a tmpfs-backed directory rather than written to persistent disk, reducing data-loss exposure. This makes Secret the intended and secure choice for the 'sensitive data' scenario in the question.

Why this answer

The Secret volume type is specifically designed to store sensitive data such as passwords, tokens, or SSH keys. Secrets are stored in the cluster's etcd (optionally encrypted at rest) and are injected into pods as files or environment variables, with in-memory (tmpfs) mounting to avoid writing sensitive data to disk.

Exam trap

A common pitfall in the CKA exam is confusing ConfigMap with Secret. Candidates often think ConfigMap can store sensitive data because it also holds key-value pairs, but ConfigMap lacks encryption and tmpfs mounting, which are essential for security. Secrets are specifically designed for sensitive information.

How to eliminate wrong answers

Option A is wrong because emptyDir is a temporary volume that shares data between containers in the same pod and is deleted when the pod is removed, with no built-in mechanism for storing sensitive data securely. Option B is wrong because hostPath mounts a file or directory from the host node's filesystem into the pod, which is not designed for secrets and poses security risks by exposing node-level data. Option D is wrong because ConfigMap is intended for non-sensitive configuration data (e.g., environment variables, config files) and does not provide encryption or access control for secrets.

Practice this question →
3
Multi-Selecthard

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Select 2 answers
A.The PVC must be currently mounted by at least one pod.
B.The underlying PersistentVolume must be deleted first.
C.The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.
D.The PersistentVolume's reclaim policy must be Recycle.
E.The PVC must be bound to a PersistentVolume.
AnswersC, E

The allowVolumeExpansion field on the StorageClass is the key enabling factor for volume growth. When set to true, the storage provisioner and the external controller permit the PVC's requested size to be increased beyond its original value; without this flag, any edit to the PVC's storage request is rejected, since the storage class provider has not opted into supporting resizing. This setting is per storage class, so if the class lacks it, expansion is impossible regardless of the volume plugin.

Why this answer

The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Exam trap

The CKA exam often tests the misconception that a PVC must be mounted or that the PV must be deleted before expansion, but the actual requirement is the StorageClass setting and the PVC being bound to a PV.

Practice this question →
4
MCQhard

You create a StorageClass with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but remains in 'Pending' state. The PVC expects a node with label 'disktype=ssd'. A suitable node exists. What is the MOST likely reason the PVC is still Pending?

A.The node selector on the PVC is incorrect.
B.The PVC requests a storage size larger than available.
C.No pod has been created that uses this PVC.
D.The persistentVolumeReclaimPolicy is set to Retain.
AnswerC

No pod has been created that uses this PVC, which is the defining characteristic of WaitForFirstConsumer. The storage controller intentionally defers PV binding and dynamic provisioning until a pod is scheduled, because it needs to know the pod's node and zone to select an appropriately local volume. Until that consumer exists, the PVC correctly remains in the Pending state.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the PVC will not be bound to a PV until a pod that uses the PVC is scheduled. The PVC remains Pending because no pod has been created that references it, even though a matching node exists. The scheduler defers volume binding to ensure the PV is provisioned on the same node where the pod lands.

Exam trap

The trap here is that candidates assume a PVC will bind immediately if a matching node exists, overlooking that WaitForFirstConsumer deliberately delays binding until a pod consumes the PVC.

How to eliminate wrong answers

Option A is wrong because the node selector on the PVC is correct (a node with 'disktype=ssd' exists), so the PVC's selector is not the issue. Option B is wrong because there is no indication that the requested storage size exceeds available capacity; the PVC is Pending due to the binding mode, not capacity. Option D is wrong because persistentVolumeReclaimPolicy (Retain, Delete, or Recycle) affects what happens to a PV after a PVC is released, not whether a PVC can bind to a PV.

Practice this question →
5
Multi-Selectmedium

Which TWO of the following are valid reclaim policies for a PersistentVolume? (Select TWO)

Select 2 answers
A.Retain
B.Delete
C.Recycle
D.Preserve
E.Archive
AnswersA, B

The Retain reclaim policy directs Kubernetes to leave the underlying storage volume and its data completely untouched when a bound PersistentVolumeClaim is deleted. The PV then transitions to the Released phase, and an administrator must manually inspect, clean up, or repurpose the storage asset before the PV can be made Available again. This is the safest choice for data that must be preserved for compliance or recovery, but it requires deliberate manual intervention to reclaim the volume.

Why this answer

A is correct because the Retain reclaim policy is one of the two valid policies for PersistentVolumes in Kubernetes. When a PersistentVolume is released from its claim, the Retain policy leaves the volume and its data intact, requiring manual administrator intervention to reclaim the storage. This is defined in the PersistentVolume spec under the `persistentVolumeReclaimPolicy` field.

Exam trap

The trap here is that candidates may recall Recycle as a valid policy from older Kubernetes documentation or experience, but the CKA exam focuses on current Kubernetes versions (1.27+) where Recycle is no longer supported, making Retain and Delete the only correct choices.

Practice this question →
6
MCQmedium

A developer creates a YAML manifest for a pod that uses a PersistentVolumeClaim. The PVC requests 5Gi of storage but the only available PV has 10Gi. What will happen when the pod is created?

A.The PV will be resized to 5Gi to match the PVC.
B.The PVC will bind to the PV and the pod will run.
C.The PVC will not bind and the pod will remain Pending.
D.The PVC will bind but the pod will be OOMKilled.
AnswerB

The PVC binds to the PV because the PV's capacity is greater than the requested storage, which Kubernetes allows. Once bound, the pod's volume mount is fulfilled and the pod can schedule and run normally. The PV capacity just needs to be equal to or larger than the PVC request, along with satisfying access modes and storage class.

Why this answer

PersistentVolumeClaims (PVCs) bind to PersistentVolumes (PVs) based on satisfying the requested storage size and access modes. Kubernetes allows a PVC to bind to a PV that has equal or greater capacity than requested; the PVC will consume only its requested amount (5Gi) from the larger PV (10Gi). Once bound, the pod referencing the PVC can start successfully because the storage claim is satisfied.

Exam trap

The trap here is that candidates often assume the PVC must match the PV exactly in size, leading them to incorrectly choose that the PVC will not bind and the pod will remain Pending.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not dynamically resize PVs to match PVC requests; PVs are static resources and their capacity is immutable after creation. Option C is wrong because a PVC can bind to a PV with larger capacity, so the binding will succeed and the pod will not remain Pending due to storage. Option D is wrong because OOMKilled is a pod termination due to memory exhaustion, which is unrelated to storage binding; the PVC binding does not cause out-of-memory errors.

Practice this question →
7
Multi-Selectmedium

Which TWO statements about emptyDir volumes are correct?

Select 2 answers
A.An emptyDir volume is created empty when a Pod is assigned to a node.
B.An emptyDir volume can be shared between Pods on different nodes.
C.An emptyDir volume persists across pod restarts.
D.An emptyDir volume is deleted when the Pod is removed from the node.
E.An emptyDir volume requires a PersistentVolume.
AnswersA, D

When the kubelet binds a Pod to a node, it creates the emptyDir as a genuinely empty directory in the Pod's sandbox before any container starts. No PersistentVolume, storage class, or pre-populated data is involved; the volume is simply a local directory whose entire lifecycle is the Pod's lifetime on that node. For memory-backed emptyDir, it is an empty tmpfs mount instead.

Why this answer

An emptyDir volume is created as an empty directory on the node when a Pod is first assigned to that node. It requires no pre-existing storage and is provisioned on the node's local filesystem (or memory if type is 'Memory').

Exam trap

The trap here is confusing 'container restart' with 'Pod removal' — candidates often think emptyDir is deleted on container restart, but it persists across container restarts and is only deleted when the Pod is deleted from the node.

Practice this question →
8
Multi-Selectmedium

Which TWO of the following are valid reclaim policies for a PersistentVolume?

Select 2 answers
A.Snapshot
B.Reuse
C.Retain
D.Delete
E.Archive
AnswersC, D

Retain is correct because it instructs Kubernetes to keep the PersistentVolume and its underlying data after the PVC is deleted. The PV remains in the Released phase and is not automatically available for a new PVC, which protects the data from accidental deletion. An administrator must manually clean up the volume, remove or update the claimRef, and then decide whether to reuse or destroy it.

Why this answer

The `Retain` reclaim policy is one of the three valid policies for a PersistentVolume in Kubernetes. When a PersistentVolumeClaim is deleted, a PV with `Retain` policy will not be automatically reclaimed; instead, the volume remains in a `Released` state, preserving its data for manual administrator intervention.

Exam trap

The trap here is that candidates confuse the `Retain` policy with backup or archival concepts, or mistakenly think `Snapshot` or `Archive` are valid reclaim policies, when Kubernetes only supports `Retain`, `Delete`, and the deprecated `Recycle`.

Practice this question →
9
Multi-Selectmedium

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Select 2 answers
A.Retain: The PV remains in the cluster and must be manually reclaimed.
B.Retain: The underlying storage asset is automatically deleted.
C.Recycle: The PV is automatically cleaned and made available for a new claim.
D.Delete: The PV must be manually deleted by the administrator.
E.Delete: The PV and the associated storage asset are automatically deleted.
AnswersA, E

Retain is correct because the PersistentVolume object remains in the cluster after its PVC is released, transitioning to the Released phase rather than being automatically removed. The underlying storage asset is preserved intact, and an administrator must manually reclaim it, typically by deleting the PV or clearing the claimRef so the volume can be reused under a new claim.

Why this answer

The Retain reclaim policy leaves the PersistentVolume (PV) in the cluster in a 'Released' state after the PersistentVolumeClaim (PVC) is deleted. The underlying storage asset (e.g., an EBS volume or NFS export) is not touched by Kubernetes, and the administrator must manually delete the PV object and then handle the storage asset (e.g., reuse or delete it) outside of Kubernetes.

Exam trap

The trap here is that candidates confuse Retain with automatic cleanup or think Recycle is still a valid, active policy, when in fact it has been deprecated and removed in recent Kubernetes versions.

Practice this question →
10
MCQmedium

An application requires a persistent volume that can be shared across multiple Pods running on different nodes, with read-write access from all Pods simultaneously. Which access mode should be specified in the PersistentVolumeClaim?

A.ReadWriteOncePod
B.ReadOnlyMany
C.ReadWriteOnce
D.ReadWriteMany
AnswerD

ReadWriteMany (RWX) is the access mode that allows the volume to be mounted as read-write on many nodes simultaneously, enabling any number of Pods across the cluster to access it concurrently. This matches the requirement of a persistent volume that can be shared: all replicas can read and write the same data without a single-node limitation. Storage backends like NFS, SMB, or certain cloud volumes support RWX.

Why this answer

The correct access mode is ReadWriteMany (RWX), which allows the volume to be mounted as read-write by multiple Pods across different nodes simultaneously. This matches the requirement for shared concurrent read-write access from all Pods.

Exam trap

The trap here is that candidates often confuse ReadWriteMany with ReadWriteOnce, assuming that 'once' means 'one Pod' rather than 'one node', or they forget that ReadOnlyMany does not grant write access despite allowing multi-Pod mounting.

How to eliminate wrong answers

Option A is wrong because ReadWriteOncePod restricts the volume to a single Pod on a single node, preventing sharing. Option B is wrong because ReadOnlyMany allows multiple Pods to mount the volume but only in read-only mode, not read-write. Option C is wrong because ReadWriteOnce allows only a single node to mount the volume as read-write, blocking multi-node sharing.

Practice this question →
11
MCQmedium

A user creates a PersistentVolumeClaim with a storage class 'ssd' that does not exist in the cluster. What will happen when the PVC is created?

A.The PVC will be deleted automatically after a timeout.
B.The PVC will be automatically bound to any available PV.
C.The PVC will remain in Pending state.
D.The cluster will create the storage class automatically.
AnswerC

When a PersistentVolumeClaim (PVC) is created referencing a StorageClass that does not exist within the cluster, the dynamic provisioning mechanism cannot proceed. The Kubernetes control plane is unable to locate a provisioner associated with the specified, non-existent StorageClass to create a new PersistentVolume (PV). Consequently, the PVC will remain in a `Pending` state indefinitely, waiting for a matching PV to become available or for the specified StorageClass to be created.

Why this answer

When a PersistentVolumeClaim (PVC) references a StorageClass that does not exist in the cluster, the PVC cannot be dynamically provisioned because the provisioner associated with that StorageClass is missing. Without a matching StorageClass, the system cannot create a new PersistentVolume (PV) for the PVC, and since no existing PV matches the claim (or the PVC is set to use dynamic provisioning), the PVC will remain in a Pending state indefinitely until the StorageClass is created or the PVC is deleted.

Exam trap

The trap here is that candidates often assume Kubernetes will fall back to a default StorageClass or automatically bind to an existing PV, but the system strictly requires the specified StorageClass to exist for dynamic provisioning and will not bypass this check.

How to eliminate wrong answers

Option A is wrong because PVCs are not automatically deleted after a timeout; they remain in Pending state until the underlying issue (missing StorageClass) is resolved or the PVC is manually deleted. Option B is wrong because a PVC that specifies a non-existent StorageClass cannot be bound to any available PV unless there is a PV that exactly matches the PVC's storage class label (which would require the StorageClass to exist), and the default binding behavior does not override a missing StorageClass. Option D is wrong because Kubernetes does not automatically create StorageClasses; they must be explicitly defined by a cluster administrator, and the system will not generate a StorageClass on the fly.

Practice this question →
12
MCQmedium

A StorageClass named 'fast-ssd' uses the provisioner 'kubernetes.io/gce-pd' and has volumeBindingMode: WaitForFirstConsumer. A PVC 'my-pvc' requests 100Gi storage from this StorageClass. A pod using the PVC is scheduled to a node in zone 'us-central1-a'. When is the PV provisioned?

A.When the pod is scheduled to a node
B.Immediately when the PVC is created
C.When the pod starts running
D.The PV is never provisioned automatically; it must be pre-created
AnswerA

With volumeBindingMode: WaitForFirstConsumer, a PVC remains unbound and unprovisioned until the Kubernetes scheduler selects a node for a pod that references the PVC. At that scheduling moment, the scheduler evaluates the pod's storage topology requirements (such as zone or region) as a hard constraint, and only then does the storage backend dynamically provision the PV and bind it to the PVC. This is why the correct answer is 'when the pod is scheduled to a node,' not any earlier or later point in the pod lifecycle.

Why this answer

The StorageClass 'fast-ssd' has volumeBindingMode set to WaitForFirstConsumer. This mode delays volume binding and provisioning until a pod using the PVC is scheduled to a node. When the pod is scheduled to a node in zone 'us-central1-a', the scheduler triggers the provisioning of a PV in that specific zone, ensuring the volume is created in the same zone as the pod.

Exam trap

The trap here is that candidates often confuse 'when the pod starts running' with 'when the pod is scheduled', but the PV provisioning is triggered by the scheduling decision, not by the container runtime starting the pod.

How to eliminate wrong answers

Option B is wrong because with WaitForFirstConsumer, provisioning does not happen immediately when the PVC is created; it is deferred until a pod consumes the PVC. Option C is wrong because provisioning occurs when the pod is scheduled to a node, not when the pod starts running; the PV is bound and provisioned during the scheduling phase, before the pod actually starts. Option D is wrong because the PV is provisioned automatically by the dynamic provisioner (kubernetes.io/gce-pd) when the WaitForFirstConsumer condition is met; it does not need to be pre-created.

Practice this question →
13
MCQmedium

A pod needs to share data between two containers during their lifecycle, but the data does not need to persist after the pod is deleted. Which volume type is most appropriate?

A.emptyDir
B.PersistentVolumeClaim
C.hostPath
D.configMap
AnswerA

An emptyDir volume is provisioned when a Pod is assigned to a node, initially empty. It provides a temporary, shared directory accessible by all containers within that specific Pod, making it ideal for inter-container communication or temporary data storage. Crucially, its contents are deleted permanently when the Pod terminates, crashes, or is removed from the node, ensuring data isolation and cleanup. This ephemeral nature perfectly suits the requirement for data sharing that only needs to persist for the duration of the pod's existence.

Why this answer

The emptyDir volume type is the correct choice because it creates an empty directory when a pod is assigned to a node, and it exists as long as the pod runs. Containers within the same pod can read and write to this shared volume, making it ideal for temporary data exchange (e.g., sidecar log shipping or file-based IPC). When the pod is deleted, the emptyDir and its contents are permanently removed, matching the requirement that data does not need to persist.

Exam trap

The trap here is that candidates often confuse emptyDir with hostPath, thinking both are ephemeral, but hostPath data persists on the node even after the pod is deleted, which violates the 'no persistence after pod deletion' requirement.

How to eliminate wrong answers

Option B (PersistentVolumeClaim) is wrong because it requests persistent storage that outlives the pod's lifecycle, which contradicts the requirement that data does not persist after pod deletion. Option C (hostPath) is wrong because it mounts a file or directory from the host node's filesystem into the pod, making data persist on the node even after the pod is deleted, and it also introduces node-specific coupling and potential security risks. Option D (configMap) is wrong because it is designed to inject configuration data (e.g., key-value pairs, files) into containers, not to serve as a writable shared volume for runtime data exchange between containers.

Practice this question →
14
MCQmedium

Which of the following volume types provides ephemeral storage that shares the pod's lifecycle and is initially empty?

A.secret
B.emptyDir
C.configMap
D.hostPath
AnswerB

emptyDir is ephemeral and starts empty.

Why this answer

B is correct because an `emptyDir` volume is created empty when a Pod is assigned to a node and exists as long as that Pod is running. It provides ephemeral storage that shares the Pod's lifecycle, meaning it is deleted when the Pod is removed, and it is initially empty, making it ideal for scratch space, caching, or temporary data.

Exam trap

The trap here is that candidates often confuse `emptyDir` with `hostPath` or `configMap`, mistakenly thinking that any volume that is initially empty must be a `configMap` or that `hostPath` provides ephemeral storage, when in fact `emptyDir` is the only volume type that is both ephemeral and initially empty by design.

How to eliminate wrong answers

Option A is wrong because a `secret` volume is used to inject sensitive data (e.g., passwords, tokens) into a Pod, not for ephemeral storage; it is populated from the Kubernetes API and is not initially empty. Option C is wrong because a `configMap` volume provides configuration data from ConfigMap objects, not ephemeral storage; it is also pre-populated with key-value pairs and shares the Pod's lifecycle but is not initially empty. Option D is wrong because a `hostPath` volume mounts a file or directory from the host node's filesystem into the Pod, persisting beyond the Pod's lifecycle and not being initially empty; it is not ephemeral and does not share the Pod's lifecycle.

Practice this question →
15
MCQeasy

You are a cluster administrator managing a production Kubernetes cluster that hosts a stateful application using StatefulSets with PersistentVolumeClaims (PVCs) backed by a cloud provider's persistent disk. A developer reports that a new pod in the StatefulSet is stuck in 'Pending' state. You describe the StatefulSet and see that it has 3 replicas. Two pods are Running, but the third pod (pod-2) is Pending. You check the PVC for pod-2 and see it is 'Pending'. The StorageClass uses 'WaitForFirstConsumer' volume binding mode. The node where pod-2 should run has sufficient resources. Other PVCs in the same namespace bound successfully. What is the most likely cause of the pending PVC and pod?

A.The PV that should bind to the PVC has a nodeAffinity that does not match any available node.
B.The CSI driver is not installed on the node where pod-2 is scheduled.
C.The PVC's requested storage size exceeds the available capacity in the cloud provider's quota.
D.The PVC's access mode is ReadWriteOnce, but the pod requires ReadWriteMany.
AnswerA

When a PersistentVolumeClaim (PVC) uses the WaitForFirstConsumer binding mode, the selection or provisioning of a PersistentVolume (PV) is delayed until a pod requiring that PVC is scheduled. If the selected PV has nodeAffinity rules that do not match the node where pod-2 was scheduled, the volume attachment will fail. This mismatch prevents the volume from being mounted, causing pod-2 to remain in a Pending state, unable to start its containers.

Why this answer

With 'WaitForFirstConsumer' volume binding mode, the PVC binding is deferred until a pod using it is scheduled. The PV that should bind to the PVC has a nodeAffinity that does not match any available node, preventing the scheduler from binding the PVC and scheduling the pod. This results in both the PVC and pod remaining in 'Pending' state, even though the node has sufficient resources.

Exam trap

The trap here is that candidates often assume a Pending PVC is always due to insufficient storage capacity or quota, ignoring the impact of volume binding modes and nodeAffinity constraints on scheduling.

How to eliminate wrong answers

Option B is wrong because the CSI driver must be installed on all nodes that can run pods using the CSI driver; if it were missing on the scheduled node, the pod would fail with a different error (e.g., 'FailedMount'), not remain Pending due to an unbounded PVC. Option C is wrong because if the requested storage size exceeded the cloud provider's quota, the PVC would likely fail with a specific error (e.g., 'ProvisioningFailed') rather than remain Pending, and other PVCs in the same namespace bound successfully, indicating quota is not the issue. Option D is wrong because ReadWriteOnce is the default access mode for most cloud persistent disks and is compatible with StatefulSet pods; ReadWriteMany would be required only if multiple pods need to write simultaneously to the same volume, which is not the case here.

Practice this question →
16
MCQeasy

Which reclaim policy will cause the underlying storage to be deleted when the associated PersistentVolume is released from a PersistentVolumeClaim?

A.Delete
B.Recycle
C.Retain
D.Archive
AnswerA

The "Delete" reclaim policy is the correct choice because it ensures that when a PersistentVolumeClaim (PVC) is deleted, Kubernetes automatically de-provisions both the PersistentVolume (PV) object and the actual underlying storage resource. This automation removes the storage asset, such as an AWS EBS volume or a GCP Persistent Disk, from the external infrastructure, preventing orphaned resources and incurring unnecessary costs.

Why this answer

The Delete reclaim policy instructs the system to remove the underlying storage asset (e.g., an AWS EBS volume, GCE Persistent Disk, or NFS export) when the PersistentVolume is released from a PersistentVolumeClaim. This is the only policy that automatically cleans up the physical storage, ensuring no orphaned resources remain.

Exam trap

The trap here is that candidates may confuse 'Recycle' with 'Delete' because both involve automatic cleanup, but Recycle only scrubs data without removing the storage asset, and it is no longer supported in modern Kubernetes versions.

How to eliminate wrong answers

Option B (Recycle) is wrong because Recycle was a legacy policy that performed a basic scrub (e.g., 'rm -rf /thevolume') and made the volume available again, but it did not delete the underlying storage; it was deprecated in Kubernetes 1.15 and removed in 1.20. Option C (Retain) is wrong because Retain leaves the PersistentVolume and its underlying storage intact after the PVC is released, requiring manual administrator intervention to reclaim or delete the storage. Option D (Archive) is wrong because Archive is not a valid Kubernetes PersistentVolume reclaim policy; the only three defined policies are Retain, Recycle (deprecated), and Delete.

Practice this question →
17
MCQeasy

Which of the following commands will list all PersistentVolumeClaims in a cluster?

A.kubectl get pv
B.kubectl get pvc
C.kubectl get claims
D.kubectl get persistent-volume-claims
AnswerB

Correct. `kubectl get pvc` is the standard shorthand command to list all PersistentVolumeClaims.

Why this answer

`kubectl get pvc` is the correct command to list PersistentVolumeClaims using the official short name. Option A lists PersistentVolumes (`pv`). Option C (`claims`) and Option D (`persistent-volume-claims` with hyphens) are invalid resource names and will result in an error.

Exam trap

Candidates often confuse the shorthand `pv` for PersistentVolume with `pvc` for PersistentVolumeClaim, or mistakenly believe that `kubectl get claims` is valid.

How to eliminate wrong answers

Option A is wrong because `kubectl get pv` lists PersistentVolumes, not PersistentVolumeClaims; these are distinct resources where PVs represent actual storage volumes and PVCs represent requests for storage. Option C is wrong because `kubectl get claims` is not a valid kubectl command; Kubernetes does not recognize 'claims' as a resource abbreviation, and this will result in an error.

Practice this question →
18
MCQmedium

A cluster administrator wants to expand an existing PersistentVolumeClaim (PVC) that is bound to a PersistentVolume (PV) with reclaim policy Delete and storage class 'fast'. The PV was dynamically provisioned. Which condition is required for the PVC expansion to succeed?

A.The PV must be in Released state.
B.The StorageClass 'fast' must have allowVolumeExpansion: true.
C.The reclaim policy must be changed to Retain before expansion.
D.The PVC must be using access mode ReadWriteOnce.
AnswerB

This statement is correct because volume expansion is a feature that must be explicitly enabled at the StorageClass level. The `allowVolumeExpansion: true` parameter within the StorageClass definition signals to Kubernetes and the underlying storage provisioner that volumes provisioned by this class are capable of being resized. Without this setting, any attempt to expand a PersistentVolumeClaim (PVC) will be rejected by the API server, regardless of the underlying storage system's capabilities.

Why this answer

For PVC expansion to succeed with a dynamically provisioned PV, the StorageClass must have the `allowVolumeExpansion: true` field set. This field explicitly enables volume expansion for all PVCs using that StorageClass. Without it, the PVC expansion request will be rejected even if other conditions are met.

Exam trap

The trap here is that candidates often confuse PV reclaim policy (Delete/Retain) with expansion capabilities, or assume the PV must be in a specific state like Released, when in fact the StorageClass setting is the sole gatekeeper for volume expansion.

How to eliminate wrong answers

Option A is wrong because the PV must be in Bound state (not Released) to allow PVC expansion; a Released PV indicates the PVC was deleted, and expansion is not possible. Option C is wrong because the reclaim policy (Delete/Retain) does not affect the ability to expand a PVC; expansion is controlled by the StorageClass setting, not the reclaim policy. Option D is wrong because PVC expansion is supported for all access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) as long as the underlying volume plugin supports it; ReadWriteOnce is not a requirement.

Practice this question →
19
MCQeasy

Which access mode allows multiple pods to read and write to a PersistentVolume simultaneously when all pods are on the same node?

A.ReadWriteOnce
B.ReadOnlyMany
C.ReadWriteMany
D.ReadWriteOncePod
AnswerA

The ReadWriteOnce (RWO) access mode permits a PersistentVolume to be mounted as read-write by a single node at any given time. Crucially, once mounted by that node, any number of pods scheduled onto that specific node can concurrently access the volume for both reading and writing operations. This perfectly satisfies the question's requirement for multiple pods to read and write, provided they are co-located on the same host.

Why this answer

ReadWriteOnce (RWO) allows a PersistentVolume to be mounted as read-write by a single node, but multiple pods on that same node can all access the volume simultaneously. This is because the access mode restriction is per node, not per pod, so all pods scheduled on the same node share the same mount and can read and write concurrently.

Exam trap

The trap here is that candidates often confuse 'node-level' access with 'pod-level' access, mistakenly thinking ReadWriteOnce means only one pod can use the volume, when in fact it allows multiple pods on the same node to read and write concurrently.

How to eliminate wrong answers

Option B (ReadOnlyMany) is wrong because it only permits read-only access, not read-write, and the question explicitly requires both reading and writing. Option C (ReadWriteMany) is wrong because it allows read-write access from multiple nodes, not just multiple pods on the same node, and it requires a distributed filesystem (e.g., NFS, GlusterFS) that supports concurrent node access, which is broader than the scenario described. Option D (ReadWriteOncePod) is wrong because it restricts the volume to a single pod on a single node, preventing multiple pods from accessing it simultaneously even on the same node.

Practice this question →
20
MCQeasy

Which volume type in Kubernetes allows a Pod to share data between its containers, with the data being deleted when the Pod is removed?

A.hostPath
B.emptyDir
C.configMap
D.secret
AnswerB

emptyDir is created when the Pod is assigned to a node and exists as long as that Pod is running. It is used for sharing data between containers and is deleted when the Pod is removed.

Why this answer

The emptyDir volume type is created when a Pod is assigned to a node and exists as long as the Pod is running. It provides a shared writable directory for all containers within the same Pod, and its contents are deleted when the Pod is removed from the node. This makes it the correct choice for ephemeral data sharing between containers.

Exam trap

The trap here is that candidates often confuse emptyDir with hostPath, thinking hostPath also provides ephemeral storage, but hostPath data persists on the node even after the Pod is deleted, which violates the requirement of data deletion upon Pod removal.

How to eliminate wrong answers

Option A is wrong because hostPath mounts a file or directory from the host node's filesystem into the Pod, and the data persists on the node even after the Pod is deleted, which does not match the requirement of data being deleted with the Pod. Option C is wrong because configMap is used to inject configuration data into Pods as files or environment variables, and it is not designed for sharing writable data between containers; its data is read-only by default and persists independently of the Pod lifecycle. Option D is wrong because secret is used to store sensitive information like passwords or tokens, and while it can be mounted into containers, it is read-only and not intended for ephemeral data sharing between containers.

Practice this question →
21
MCQhard

A cluster has a PersistentVolumeClaim (PVC) named 'data-claim' bound to a PersistentVolume (PV) with reclaim policy 'Retain'. The PVC is deleted. The PV now shows status 'Released'. What must be done so that the PV can be reused by a new PVC?

A.Nothing; the PV will automatically become Available after some time.
B.Delete and recreate the PersistentVolume.
C.Create a new PVC with the same name.
D.Change the reclaim policy to Delete.
AnswerB

Deleting and recreating the PersistentVolume resource is a standard and clean way to make the underlying storage available for new claims. Because the reclaim policy is Retain, deleting the Kubernetes PV object does not destroy the actual data on the external storage provider. Recreating the PV with the same storage details allows a new PVC to bind to it successfully.

Why this answer

When a PVC is deleted and the PV has a reclaim policy of 'Retain', the PV enters a 'Released' state, meaning it still contains the data but is no longer bound to the original PVC. The PV cannot be directly reused by a new PVC because its claim reference is still set to the deleted PVC's UID. To make the PV available again, you must manually delete and recreate the PV (or at least delete it and re-create it with a clean claimRef), which resets its status to 'Available'.

Exam trap

The CKA exam often tests the misconception that a 'Released' PV will automatically become 'Available' over time, but the 'Retain' policy requires explicit administrative action to clear the claim reference.

How to eliminate wrong answers

Option A is wrong because a PV with reclaim policy 'Retain' does not automatically transition from 'Released' to 'Available'; manual intervention is required. Option C is wrong because creating a new PVC with the same name does not clear the existing PV's claimRef; the PV remains 'Released' and will not bind to the new PVC unless the PV is manually cleaned. Option D is wrong because changing the reclaim policy to 'Delete' would cause the PV to be deleted (and its underlying storage potentially removed), not make it 'Available' for reuse; the correct action is to delete and recreate the PV.

Practice this question →
22
MCQeasy

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

A.ReadWriteMany (RWX)
B.ReadWriteOnce (RWO)
C.ReadWriteOncePod (RWOP)
D.ReadOnlyMany (ROX)
AnswerA

RWX allows multiple nodes to mount the volume as read-write.

Why this answer

ReadWriteMany (RWX) is the correct access mode because it allows a PersistentVolume to be mounted as read-write by multiple pods simultaneously, even when those pods are scheduled on different nodes. This is the only access mode that supports concurrent read-write access across nodes, which is essential for shared storage solutions like NFS, GlusterFS, or CephFS.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with the ability to mount across nodes, not realizing RWO is per-node, not per-pod, and that ReadWriteMany (RWX) is the only mode that explicitly allows multi-node read-write access.

How to eliminate wrong answers

Option B (ReadWriteOnce, RWO) is wrong because it restricts the volume to be mounted as read-write by only a single pod on a single node; any additional pods attempting to mount the same volume will fail. Option C (ReadWriteOncePod, RWOP) is wrong because it further restricts the volume to be mounted by only one pod cluster-wide, regardless of node, and is a Kubernetes 1.22+ feature for preventing concurrent access entirely. Option D (ReadOnlyMany, ROX) is wrong because it allows multiple pods to mount the volume, but only in read-only mode, not read-write.

Practice this question →
23
MCQmedium

A cluster administrator needs to create a PersistentVolume that can be mounted as a block device (not a filesystem) by a Pod. Which field in the PersistentVolume spec must be set to enable this?

A.persistentVolumeReclaimPolicy: Retain
B.volumeMode: Filesystem
C.accessModes: ReadWriteOnce
D.volumeMode: Block
AnswerD

Setting `volumeMode: Block` in a PersistentVolume definition instructs Kubernetes to expose the underlying storage resource as a raw block device directly to the consuming pod. This bypasses the traditional filesystem layer, allowing applications to perform direct I/O operations on the unformatted volume. This capability is crucial for high-performance applications like databases or custom storage engines that require fine-grained control over storage, making it the correct choice for providing a raw block device.

Why this answer

Setting `volumeMode: Block` in the PersistentVolume spec specifies that the volume is to be presented as a raw block device, without a filesystem. This allows a Pod to mount the volume as a block device (e.g., `/dev/sdb`) rather than a mounted directory, which is required for applications that need direct access to the underlying storage, such as databases or custom storage engines.

Exam trap

The trap here is that candidates often confuse `volumeMode` with `accessModes` or `persistentVolumeReclaimPolicy`, assuming that access modes or reclaim policies control the block device behavior, when in fact only `volumeMode: Block` enables raw block volume mounting.

How to eliminate wrong answers

Option A is wrong because `persistentVolumeReclaimPolicy: Retain` controls what happens to the PV when the PVC is released (e.g., retain, recycle, delete), not how the volume is presented to the Pod. Option B is wrong because `volumeMode: Filesystem` is the default mode that creates a filesystem on the volume, which is the opposite of what is needed for a block device mount. Option C is wrong because `accessModes: ReadWriteOnce` defines the access mode (e.g., single node read-write), not the volume mode; it does not enable block device mounting.

Practice this question →
24
MCQhard

A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?

A.The PVC is not bound to a PV because no PV exists.
B.The CSI driver is not installed or malfunctioning.
C.The pod does not have the correct node selector.
D.The StorageClass uses 'Immediate' binding mode.
AnswerB

The StorageClass references a CSI provisioner (e.g., csi.contoso.com), and Kubernetes relies on the external-provisioner sidecar to send CreateVolume RPCs to the CSI driver controller. If that driver controller is not installed, the DaemonSet pods are CrashLooping, or the CSI socket is unavailable, the provisioner cannot create the backend volume, so no PV is bound and the PVC remains Pending with events like 'Failed to provision volume with storage class'. Inspecting the csi-controller logs and the driver DaemonSet status will confirm the malfunction.

Why this answer

When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.

Exam trap

The trap here is that candidates may assume 'WaitForFirstConsumer' delays binding indefinitely or that a missing PV is the root cause, rather than recognizing that dynamic provisioning requires a functioning CSI driver to create the PV after scheduling.

How to eliminate wrong answers

Option A is wrong because dynamic provisioning creates a PV on demand; the absence of a pre-existing PV is expected and not a problem. Option C is wrong because the pod's node selector does not affect the CSI driver's ability to provision the PV; the issue is with the driver itself. Option D is wrong because the StorageClass explicitly uses 'WaitForFirstConsumer' binding mode, not 'Immediate', so this option describes a configuration that is not present.

Practice this question →
25
MCQeasy

A developer accidentally runs 'kubectl delete pvc data-claim'. What is the immediate effect on the PersistentVolume pv-data?

A.The PV pv-data is automatically deleted.
B.The PV pv-data remains Bound to the deleted PVC.
C.The PV pv-data immediately becomes Available and can be reused.
D.The PV pv-data enters the Released state and is not deleted.
AnswerD

With the Retain reclaim policy configured, deleting the bound PVC causes the PV to enter the Released state rather than being deleted or recycled. This means the PV still exists and its underlying storage resources—such as disk data—remain intact, but it is no longer bound to any claim. The PV will remain in Released status until an administrator manually intervenes, typically by deleting the PV and recreating it or by editing its claimRef to allow rebinding. This preserves data for recovery but leaves the PV unused until explicit manual action is taken.

Why this answer

When a PVC is deleted, the associated PV enters the 'Released' state, not 'Available'. This is because the PV still contains data from the previous claim (the retain policy is 'Retain' by default), and Kubernetes does not automatically delete or reuse it. The PV remains in 'Released' until an administrator manually clears the claimRef or deletes the PV.

Exam trap

The trap here is that candidates assume the PV's reclaim policy is 'Delete' by default, or that deleting a PVC automatically makes the PV 'Available' for reuse, when in fact the default policy is 'Retain' and the PV enters 'Released'.

How to eliminate wrong answers

Option A is wrong because the PV is not automatically deleted when the PVC is deleted; the PV's lifecycle is independent and depends on its reclaim policy (default is 'Retain'). Option B is wrong because the PV does not remain 'Bound' to the deleted PVC; the binding is removed, and the PV transitions to 'Released'. Option C is wrong because the PV does not immediately become 'Available'; it enters 'Released' and cannot be reused until the claimRef is manually cleared by an administrator.

Practice this question →
26
MCQhard

A cluster administrator is configuring a Pod to use a PersistentVolumeClaim (PVC) that is dynamically provisioned using a StorageClass with volumeBindingMode: WaitForFirstConsumer. The PVC is created before the Pod. When the Pod is created, which node will the PV be provisioned on?

A.The PV is provisioned immediately on the node specified in the StorageClass's allowedTopologies.
B.The node where the Pod is scheduled.
C.Any node in the cluster that has sufficient resources for the PV.
D.The control plane node.
AnswerB

This option is correct. When a StorageClass uses the WaitForFirstConsumer volume binding mode, the Kubernetes scheduler plays a crucial role. It first finds a suitable node for the Pod, considering all its requirements, including the PVC. Once the Pod is scheduled to a specific node, the PersistentVolume is then dynamically provisioned on that very node, ensuring optimal data locality and performance for the Pod.

Why this answer

When a StorageClass uses volumeBindingMode: WaitForFirstConsumer, the PersistentVolume (PV) is not provisioned until a Pod that uses the PersistentVolumeClaim (PVC) is scheduled. The PV is then provisioned on the exact node where the Pod is scheduled, ensuring that the volume is created in the same zone or topology as the Pod. This avoids unnecessary cross-zone data transfer and ensures the PV is available locally to the Pod's node.

Exam trap

The trap here is that candidates assume PV provisioning happens immediately when the PVC is created, or that it is tied to a specific node defined in the StorageClass, rather than understanding that WaitForFirstConsumer delays provisioning until Pod scheduling and ties it to the Pod's node.

How to eliminate wrong answers

Option A is wrong because allowedTopologies in a StorageClass is used with Immediate binding mode to restrict provisioning to specific zones, but with WaitForFirstConsumer, the PV is provisioned on the node where the Pod is scheduled, not necessarily on a node matching allowedTopologies unless the scheduler enforces it. Option C is wrong because the PV is not provisioned on 'any node with sufficient resources'; it is specifically provisioned on the node where the Pod is scheduled, and the scheduler considers topology constraints from the PVC and StorageClass. Option D is wrong because the control plane node is not involved in PV provisioning for WaitForFirstConsumer; the PV is provisioned on the worker node where the Pod runs, not on the control plane.

Practice this question →
27
MCQhard

You need to allow a pod to use a specific device from the host node (e.g., /dev/sdb) as a raw block device. Which volume mode should you set in the PVC?

A.Device
B.Raw
C.Block
D.Filesystem
AnswerC

Setting volumeMode: Block on a volume causes Kubernetes to present the backing storage as an unformatted raw block device inside the container. You must attach it through the container's volumeDevices list, providing a devicePath (e.g., /dev/xvdb), rather than using volumeMounts and a mountPath. This is required for workloads such as databases or storage engines that manage their own on-disk layout and want to bypass the filesystem layer entirely. Only Block mode supports this raw device access model.

Why this answer

To use a host device like /dev/sdb as a raw block device inside a pod, the PersistentVolumeClaim (PVC) must specify `volumeMode: Block`. This tells Kubernetes to expose the volume as a raw block device (e.g., /dev/xxx) inside the container, rather than mounting a filesystem. Only the `Block` volume mode supports this behavior, as defined in the Kubernetes PersistentVolume API.

Exam trap

The trap here is that candidates confuse the 'Block' volume mode with the deprecated 'Raw' or 'Device' terminology from other systems, or assume 'Filesystem' is the only option, missing that raw block access requires explicit mode selection.

How to eliminate wrong answers

Option A is wrong because 'Device' is not a valid volume mode in Kubernetes; the valid modes are 'Filesystem' and 'Block'. Option B is wrong because 'Raw' is not a recognized volume mode; the correct term is 'Block' for raw block device access. Option D is wrong because 'Filesystem' is the default volume mode, which mounts a filesystem (e.g., ext4) and does not expose the device as a raw block device.

Practice this question →
28
MCQmedium

A cluster administrator creates a StorageClass with the following YAML: apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete volumeBindingMode: Immediate A developer creates a PVC using this StorageClass. The PVC is created and remains in Pending state. What is the most likely cause?

A.The volumeBindingMode is Immediate, which requires a different access mode.
B.The cluster is not running on AWS or the AWS cloud provider is not configured.
C.The PVC does not specify an access mode.
D.The reclaim policy is Delete, which prevents binding.
AnswerB

The `kubernetes.io/aws-ebs` provisioner is specifically designed to interact with the AWS EC2 API to create EBS volumes. For this provisioner to function correctly, the Kubernetes cluster must be running within an AWS environment, and the `kube-controller-manager` must be configured with the AWS cloud provider integration. If the cluster is not on AWS, or if the cloud provider integration is misconfigured or missing, the provisioner cannot authenticate or make API calls to AWS, leading to the PVC remaining in a `Pending` state indefinitely as it cannot provision the underlying storage.

Why this answer

The StorageClass uses the provisioner `kubernetes.io/aws-ebs`, which is specific to the AWS cloud provider. If the cluster is not running on AWS or the AWS cloud provider is not properly configured (e.g., missing IAM roles, cloud-controller-manager not running), the provisioner cannot create the underlying EBS volume, leaving the PVC in a Pending state indefinitely.

Exam trap

The trap here is that candidates may focus on PVC spec details like access modes or reclaim policies, but the core issue is that the provisioner is incompatible with the underlying infrastructure, which is a common real-world misconfiguration tested in the CKA Storage domain.

How to eliminate wrong answers

Option A is wrong because `volumeBindingMode: Immediate` does not require a specific access mode; it simply means binding and provisioning happen as soon as the PVC is created, regardless of pod scheduling. Option C is wrong because the PVC can still be created and bound even if it does not specify an access mode; the access mode is a required field in the PVC spec, but its absence would cause a validation error, not a Pending state after creation. Option D is wrong because the `reclaimPolicy: Delete` does not prevent binding; it only determines what happens to the PV when the PVC is deleted, and has no effect on the initial binding process.

Practice this question →
29
MCQmedium

You want to dynamically provision storage for a PVC using a StorageClass named 'fast-ssd'. Which field in the PVC YAML specifies the StorageClass?

A.class
B.storageClass
C.className
D.storageClassName
AnswerD

The field storageClassName is the correct, canonical way to reference a StorageClass in a PersistentVolumeClaim. It tells the Kubernetes scheduler which StorageClass should be used to dynamically provision a PersistentVolume for this claim. If the StorageClass exists and is available, the provisioner associated with it creates the underlying storage, and the PV is bound to the PVC. If storageClassName is not specified, the cluster's default StorageClass is used, but explicit specification ensures the desired class is selected. This field is part of the PVC spec and is crucial for controlling storage characteristics like performance, reclaim policy, and provisioner.

Why this answer

In Kubernetes, the field that specifies which StorageClass to use for dynamic provisioning in a PersistentVolumeClaim (PVC) is `storageClassName`. When this field is set to a valid StorageClass name (e.g., 'fast-ssd'), the system will dynamically provision a PersistentVolume using the provisioner and parameters defined in that StorageClass. If omitted, the default StorageClass (if one exists) is used.

Exam trap

The trap here is that candidates often confuse the field name `storageClassName` with similar-sounding terms like `storageClass` or `className`, or they assume a generic `class` field exists, leading them to pick a plausible but incorrect option.

How to eliminate wrong answers

Option A is wrong because `class` is not a valid field in a PVC spec; it is a legacy term from earlier versions and is not recognized by the Kubernetes API. Option B is wrong because `storageClass` (camelCase) is not the correct field name; the API uses `storageClassName` (all lowercase with 'Name' appended). Option C is wrong because `className` is not a field in the PVC spec; it might be confused with a field in other Kubernetes resources (e.g., Ingress) but does not apply to PVCs.

Practice this question →
30
MCQeasy

A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?

A.Use the ConfigMap to set environment variables instead of a volume mount.
B.Use the 'items' field in the ConfigMap volume definition to specify which keys to include.
C.Mount the entire ConfigMap and use a startup script to remove unwanted files.
D.Create a new ConfigMap with only the needed keys.
AnswerB

The `items` field within a ConfigMap volume definition is the precise and recommended method for selectively exposing specific keys as files inside a container. By specifying `key` and `path` for each desired entry, only the relevant data from the ConfigMap is mounted into the pod's filesystem, preventing unnecessary data exposure. This approach ensures minimal resource usage and adheres to the principle of least privilege by only providing what is strictly required. For example, `items: [{key: "app-config.yaml", path: "config.yaml"}]` mounts only the `app-config.yaml` key as `config.yaml`.

Why this answer

The `items` field in a ConfigMap volume definition allows you to selectively project only specific keys from the ConfigMap into the pod's filesystem. This is the native Kubernetes mechanism for controlling which keys appear as files, avoiding the need to mount the entire ConfigMap or create a separate ConfigMap.

Exam trap

The trap here is that candidates often confuse the `items` field with the `optional` field or assume that mounting a ConfigMap always exposes all keys, leading them to choose the wasteful approach of creating a new ConfigMap (Option D) instead of using the built-in selective projection mechanism.

How to eliminate wrong answers

Option A is wrong because using environment variables is a different mechanism that does not address the requirement to mount a ConfigMap as a volume; it also exposes all keys as environment variables unless you manually specify each key, which is not the best approach for selective file projection. Option C is wrong because mounting the entire ConfigMap and then using a startup script to remove unwanted files is an anti-pattern that wastes resources, adds complexity, and violates the principle of declarative configuration. Option D is wrong because creating a new ConfigMap with only the needed keys duplicates data and increases management overhead, whereas the `items` field achieves the same goal without creating additional objects.

Practice this question →
31
MCQeasy

Which access mode allows multiple pods on different nodes to mount a PersistentVolume as read-write?

A.ReadWriteMany (RWX)
B.ReadWriteOncePod (RWOP)
C.ReadWriteOnce (RWO)
D.ReadOnlyMany (ROX)
AnswerA

ReadWriteMany (RWX) is the correct access mode because it explicitly allows a PersistentVolume to be mounted as read-write by multiple nodes simultaneously. This capability enables multiple pods, potentially distributed across different Kubernetes nodes, to concurrently access and modify the shared storage, directly fulfilling the question's requirement for "multiple pods on different nodes" needing read-write access. This mode is typically supported by network file systems like NFS or distributed storage solutions.

Why this answer

ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to mount a PersistentVolume as read-write simultaneously. This is achieved through shared filesystem protocols such as NFS, GlusterFS, or CephFS, which support concurrent access from multiple clients. The RWX mode is essential for workloads like clustered databases or shared storage applications where multiple instances need to write to the same volume.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, assuming 'Once' means one pod at a time, but it actually means one node at a time, so multiple pods on the same node can share it, but not across nodes.

How to eliminate wrong answers

Option B (ReadWriteOncePod) is wrong because it restricts the volume to a single pod on a single node, preventing any other pod from mounting it, even on the same node. Option C (ReadWriteOnce) is wrong because it allows only a single node to mount the volume as read-write, meaning multiple pods on different nodes cannot access it concurrently. Option D (ReadOnlyMany) is wrong because it permits multiple nodes to mount the volume, but only in read-only mode, not read-write.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Storage questions.

Start 20-question session