Courseiva

CCNA Storage And Persistent Volumes Questions

67 questions · Storage And Persistent Volumes topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A developer deploys an application that mounts a PVC in read-only mode inside the pod specification. How is this configured in the Pod's volumeMounts?

A.Set accessModes to ReadOnlyMany on the PVC object.
B.Set readOnly: true in the container's volumeMounts entry.
C.Set volumeMode: ReadOnly in the PVC spec.
D.Annotate the PVC with 'volume.beta.kubernetes.io/readonly'.
AnswerB

Setting `readOnly: true` on the container's `volumeMounts` entry enforces read-only access at the mount point, satisfying the stem's requirement that the PVC be mounted read-only inside the pod. This is the per-container mount flag, distinct from the PersistentVolumeClaim's own access modes, which govern node-level attachment rather than filesystem writability.

Why this answer

Read-only mounting of a PVC inside a pod is set per-container via `readOnly: true` in the volumeMounts entry. This tells the kubelet to mount the volume read-only for that container, regardless of the PVC's access modes.

Exam trap

EX280 often tests whether candidates confuse PVC accessModes (volume capability) with the per-container volumeMounts.readOnly flag (mount behavior), leading them to pick ReadOnlyMany incorrectly.

How to eliminate wrong answers

Option A is wrong because accessModes (ReadOnlyMany) describe how the volume can be mounted by multiple nodes, not whether a specific container mounts it read-only. Option C is wrong because volumeMode is either Filesystem or Block, not ReadOnly. Option D is wrong because there is no such annotation `volume.beta.kubernetes.io/readonly` — it is fabricated.

Practice this question →
2
Multi-Selectmedium

Which TWO characteristics describe StorageClasses in OpenShift?

Select 2 answers
A.They specify the provisioner plugin responsible for creating volumes.
B.They store the actual application data files.
C.They are namespace-scoped and unique to each project.
D.They can only be created by unprivileged developer users.
E.They are cluster-scoped resources.
AnswersA, E

Each StorageClass names a provisioner plugin, such as a CSI driver, that dynamically creates the underlying volume when a PVC references it. This provisioner field is what determines which storage backend fulfils the claim, satisfying the characteristic described.

Why this answer

Option A is correct because a StorageClass defines the provisioner field (for example kubernetes.io/aws-ebs, ebs.csi.aws.com, or a custom CSI driver) that tells OpenShift which plugin dynamically creates the PersistentVolume backing a PVC. Option E is correct because StorageClasses are cluster-scoped resources, not namespaced, so they are visible across all projects and can be referenced by PVCs in any namespace. Options B, C, and D are incorrect: StorageClasses do not hold application data (that resides on the PersistentVolume), they are not namespace-scoped or project-unique, and creating them typically requires cluster-admin privileges rather than unprivileged developer access.

Exam trap

EX280 often tests the misconception that StorageClasses are namespace-scoped, but they are cluster-scoped, and candidates must also remember that they define provisioners, not store data.

Practice this question →
3
MCQeasy

Where are PersistentVolumeClaims located in terms of OpenShift's API scope?

A.They are node-scoped resources.
B.They are namespaced resources.
C.They are global resources shared across all clusters in a fleet.
D.They are cluster-scoped resources.
AnswerB

PersistentVolumeClaims are namespaced resources, meaning each claim exists within a single project and is visible only to workloads in that namespace. This scoping satisfies OpenShift's API constraint that claims bind to storage within their own project boundary.

Why this answer

PersistentVolumeClaims (PVCs) are namespaced resources in OpenShift, meaning they exist within a specific project (namespace) and are scoped to that namespace. This allows different projects to have their own PVCs with the same name.

Exam trap

EX280 often tests the confusion between namespaced and cluster-scoped resources, and candidates may incorrectly think PVCs are cluster-scoped like PVs.

How to eliminate wrong answers

Option A is wrong because PVCs are not node-scoped; they are not tied to a specific node. Option C is wrong because PVCs are not global resources shared across clusters; they are limited to a single cluster and namespace. Option D is wrong because cluster-scoped resources are accessible across all namespaces, but PVCs are namespaced.

Practice this question →
4
MCQhard

A developer needs to mount an existing PersistentVolumeClaim into a pod, but the application requires that the volume be mounted read-only to prevent accidental writes. The PVC was created with accessMode ReadWriteOnce. Which configuration in the pod's volumeMounts is correct?

A.Set readOnly: true in the volumeMounts section for that volume.
B.Set readOnly: true in the PersistentVolume's spec.
C.Change the PVC's accessMode to ReadOnlyMany.
D.Set readOnly: true in the pod's volumes section for that volume.
AnswerA

The readOnly field in volumeMounts controls whether the volume is mounted read-only for that specific container. Even if the PVC was created with ReadWriteOnce, the pod can mount it read-only by setting readOnly: true. This enforces read-only access at the mount point, preventing writes from the container. It does not change the PVC's access mode, which remains ReadWriteOnce.

Why this answer

To mount a volume read-only in a pod, set readOnly: true in the volumeMounts entry for that volume within the container. This is independent of the PVC's access mode. The access mode governs how many nodes can mount the volume and whether they can write, but the pod-level readOnly flag enforces read-only at the mount point for that container.

Exam trap

The trap here is confusing the PVC access mode with the pod's volumeMount readOnly field; the access mode does not enforce read-only at the container level.

Practice this question →
5
MCQmedium

What is the effect of setting 'allowVolumeExpansion: true' in a StorageClass?

A.It automatically shrinks PVCs when storage usage drops below 50%.
B.It permits users to increase the storage size of PVCs created from this StorageClass.
C.It allows multiple pods to write to an RWO volume simultaneously.
D.It allows the cluster to automatically scale the number of worker nodes based on storage demand.
AnswerB

The allowVolumeExpansion field on the StorageClass enables the CSI driver's resize capability, letting users edit a PVC's requested storage upward. Without it, the API server rejects PVC size increases, so this setting satisfies the requirement to permit growing volumes provisioned from that class.

Why this answer

Setting allowVolumeExpansion: true in a StorageClass allows users to increase the size of PVCs created from that StorageClass. This enables online expansion of volumes, provided the underlying storage provider supports it.

Exam trap

EX280 often tests the misconception that allowVolumeExpansion enables automatic scaling or shrinking, when it only permits manual expansion of PVCs.

How to eliminate wrong answers

Option A is wrong because volume expansion does not automatically shrink PVCs; shrinking is not supported. Option C is wrong because allowVolumeExpansion does not change the access mode; RWO volumes still allow only one pod to write. Option D is wrong because allowVolumeExpansion does not trigger node scaling; that is handled by the cluster autoscaler.

Practice this question →
6
MCQhard

A cluster administrator needs to configure a generic ephemeral inline volume in a Pod specification. Where is the volume defined?

A.In the namespace ResourceQuota configuration.
B.In the StorageClass definition under the ephemeralTemplate field.
C.As a standalone PVC that is automatically annotated by the scheduler.
D.Directly in the Pod's spec.volumes array using the ephemeral volume source type.
AnswerD

Generic ephemeral inline volumes are declared within the Pod's own spec.volumes array using the ephemeral volume source, so the volume lifecycle is tied to the Pod. This satisfies the stem's requirement for where the volume is defined.

Why this answer

A generic ephemeral inline volume is defined directly in the Pod's spec.volumes array using the ephemeral volume source type. This allows the volume to be created and destroyed alongside the Pod, with the underlying storage managed by a PersistentVolumeClaim template embedded in the Pod spec. The ephemeral volume source references a volumeClaimTemplate that specifies the StorageClass and size, enabling dynamic provisioning without a separate PVC object.

Exam trap

EX280 often tests the distinction between persistent and ephemeral storage, and candidates may confuse generic ephemeral volumes with standalone PVCs or assume they are defined in StorageClass, leading to incorrect answers.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption in a namespace, not to define volumes. Option B is wrong because StorageClass definitions do not contain an ephemeralTemplate field; ephemeral volumes are defined in the Pod spec, not in the StorageClass. Option C is wrong because a standalone PVC is a separate resource and is not automatically annotated by the scheduler for ephemeral use; generic ephemeral volumes are inline and do not require a pre-created PVC.

Practice this question →
7
MCQmedium

What is the primary function of a CSI (Container Storage Interface) Driver Operator in OpenShift?

A.To deploy, upgrade, and manage the CSI driver components (controller and node plugins) in the cluster.
B.To automatically back up etcd data onto persistent volumes.
C.To act as an NFS server running directly on control plane nodes.
D.To convert emptyDir volumes into encrypted block devices.
AnswerA

The CSI Driver Operator automates lifecycle management of CSI driver components, deploying and upgrading the controller and node plugins across the OpenShift cluster. This satisfies the requirement for consistent, operator-managed storage driver installation rather than manual DaemonSet and Deployment configuration.

Why this answer

A CSI Driver Operator in OpenShift is responsible for deploying, upgrading, and managing the lifecycle of a CSI driver's components — specifically the controller plugin (Deployment) and node plugin (DaemonSet) — in the cluster. It packages the driver as an Operator so that installation, configuration, and upgrades are handled declaratively via the Operator Lifecycle Manager (OLM).

Exam trap

EX280 often tests the misconception that a CSI Driver Operator is the storage backend itself — candidates may pick answers about NFS servers or encryption, but the operator's job is lifecycle management of the CSI driver components (controller and node plugins), not providing the storage or encrypting volumes.

How to eliminate wrong answers

Option B is wrong because etcd backup is handled by the etcd Operator and cluster-backup.sh, not by CSI Driver Operators; CSI drivers provide storage, not control-plane backup. Option C is wrong because a CSI Driver Operator does not run an NFS server on control plane nodes — it deploys storage driver pods (controller/node plugins) that consume storage backends, and NFS is just one possible backend. Option D is wrong because emptyDir volumes are ephemeral node-local storage and are not converted into encrypted block devices by CSI; encryption is a property of the underlying storage backend or a StorageClass parameter (e.g., encrypted: 'true' on AWS EBS).

Practice this question →
8
MCQmedium

You want to restore an existing VolumeSnapshot into a new PersistentVolumeClaim. Which field in the PVC specification must reference the VolumeSnapshot?

A.claimRef
B.snapshotName
C.dataSource
D.volumeName
AnswerC

The dataSource field names the VolumeSnapshot as the source for provisioning, so the CSI driver restores its contents into the new PVC. Setting dataSource to a VolumeSnapshot kind satisfies the requirement to restore an existing snapshot rather than bind an empty volume.

Why this answer

In Kubernetes/OpenShift, restoring a VolumeSnapshot into a new PVC is done by setting the PVC's spec.dataSource field to reference the VolumeSnapshot object (apiGroup: snapshot.storage.k8s.io, kind: VolumeSnapshot, name: <snapshot-name>). This tells the CSI provisioner to create the new volume from the snapshot's contents rather than provisioning an empty volume. The dataSource field is the standard, GA mechanism for both snapshot restore and volume cloning.

Exam trap

EX280 often tests whether candidates confuse PVC dataSource (for snapshot/clone restore) with PV claimRef (for binding) or PVC volumeName (for static binding), so pick dataSource whenever the question mentions restoring from a snapshot.

How to eliminate wrong answers

Option A is wrong because claimRef is a PersistentVolume field used to bind a PV to a specific PVC, not a PVC field for sourcing data. Option B is wrong because snapshotName is not a valid PVC spec field — the snapshot reference must be nested under dataSource, not a top-level key. Option D is wrong because volumeName statically binds a PVC to an existing PersistentVolume by name; it does not trigger snapshot-based provisioning.

Practice this question →
9
MCQeasy

An application pod requires concurrent read and write access to the same storage volume from multiple worker nodes simultaneously. Which access mode must be specified in the PersistentVolumeClaim to satisfy this requirement?

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

ReadWriteMany permits a volume to be mounted read-write by many nodes concurrently, matching the requirement for simultaneous access from multiple worker nodes. ReadWriteOnce and ReadWriteOncePod restrict access to a single node, so they cannot satisfy this constraint.

Why this answer

ReadWriteMany (RWX) allows a volume to be mounted as read-write by many nodes simultaneously, which is required when multiple pods on different worker nodes need concurrent read/write access. It is supported by shared filesystems like NFS, CephFS, or GlusterFS, but not by block storage such as EBS or most local volumes.

Exam trap

EX280 often tests access mode semantics — candidates confuse ReadOnlyMany with ReadWriteMany or assume RWO permits multi-node access.

How to eliminate wrong answers

Option B is wrong because ReadWriteOnce (RWO) allows read-write mounting by only a single node at a time, so pods on multiple nodes cannot concurrently write. Option C is wrong because ReadOnlyMany (ROX) permits multi-node mounting but only read-only, not read-write. Option D is wrong because WriteOncePod restricts the volume to a single pod cluster-wide, the strictest mode, and does not allow multi-node concurrency.

Practice this question →
10
Multi-Selecthard

Which THREE actions are required when manually setting up a pre-provisioned PersistentVolume backed by an existing storage asset?

Select 3 answers
A.Set allowVolumeExpansion to false on all namespaces.
B.Specify spec.accessModes to match expected claim requirements.
C.Provide the specific volume source configuration (e.g., csi or nfs parameters).
D.Define spec.capacity.storage matching the underlying storage size.
E.Create a matching VolumeSnapshotClass before defining the PV.
AnswersB, C, D

Specifying `spec.accessModes` ensures the PersistentVolume advertises exactly the access the underlying storage asset supports, such as ReadWriteOnce or ReadWriteMany. This satisfies the stem's requirement to match expected claim requirements, so a PersistentVolumeClaim binding to this pre-provisioned volume succeeds rather than failing on incompatible access mode constraints.

Why this answer

When manually creating a pre-provisioned PersistentVolume, you must define the storage capacity in spec.capacity.storage (option D) so the PV advertises the correct size that a PVC can request and bind to. You must also set spec.accessModes (option B) such as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany so the PV's supported modes match the PVC's requested access mode for binding. Finally, you must provide the volume source configuration (option C), e.g., csi with driver/volumeHandle or nfs with server/path, because this tells Kubernetes which existing storage asset to attach and how to mount it.

Option A is wrong because allowVolumeExpansion is a StorageClass field, not a per-namespace setting, and it is irrelevant to a manually created PV. Option E is wrong because VolumeSnapshotClass is only needed for snapshot operations, not for defining a pre-provisioned PV.

Exam trap

EX280 often tests the required fields of a manually created PV, tricking candidates into selecting StorageClass or snapshot-related options that are irrelevant to pre-provisioned volume setup.

Practice this question →
11
MCQeasy

Which component in OpenShift is responsible for watching PersistentVolumeClaims and dynamically provisioning PersistentVolumes when supported by a StorageClass?

A.kube-scheduler
B.crio
C.etcd
D.kube-controller-manager
AnswerD

The kube-controller-manager runs the PersistentVolume controller, which watches PersistentVolumeClaims and triggers dynamic provisioning through the StorageClass's provisioner when no matching PersistentVolume exists. This satisfies the stem's requirement for the component that watches PVCs and provisions PersistentVolumes dynamically.

Why this answer

The kube-controller-manager runs the PersistentVolume controller, which watches for PersistentVolumeClaims that reference a StorageClass with a provisioner and dynamically creates matching PersistentVolumes. This is the component that implements dynamic provisioning in both Kubernetes and OpenShift. Without it, PVCs would remain Pending unless an admin manually pre-provisioned a PV.

Exam trap

EX280 often tests whether candidates attribute dynamic provisioning to the scheduler or etcd — the correct answer is always kube-controller-manager, which hosts the PersistentVolume controller.

How to eliminate wrong answers

Option A is wrong because kube-scheduler only decides which node a pod runs on — it does not create or bind storage volumes. Option B is wrong because CRI-O is the container runtime that pulls images and runs containers; it has no role in storage provisioning. Option C is wrong because etcd is the distributed key-value store that persists cluster state — it stores PV/PVC objects but does not act on them.

Practice this question →
12
MCQhard

An administrator needs to prune or reclaim dangling VolumeSnapshotContent objects whose parent VolumeSnapshots have already been deleted, but the reclaim policy was set incorrectly. How can this be resolved?

A.Recreate the deleted VolumeSnapshot with the exact same UID.
B.Restart the snapshot-controller deployment.
C.Run 'oc prune snapshots --force'.
D.Manually delete the orphaned VolumeSnapshotContent object or remove its finalizers if stuck.
AnswerD

When a VolumeSnapshot is deleted but its VolumeSnapshotContent retains a Retain reclaim policy, the content object becomes orphaned. Deleting it directly, or stripping finalizers when deletion hangs, reclaims the dangling resource and clears the stuck state.

Why this answer

Orphaned VolumeSnapshotContent objects left behind when their parent VolumeSnapshot is deleted (due to a misconfigured deletionPolicy of Retain instead of Delete) must be cleaned up manually. You delete the VolumeSnapshotContent object directly, or if it is stuck due to finalizers, remove the finalizers (e.g., snapshot.storage.kubernetes.io/volumesnapshotcontent-bound-protection) and then delete it.

Exam trap

EX280 often tests finalizer behavior — candidates assume restarting controllers or recreating objects fixes orphaned resources instead of manually clearing finalizers.

How to eliminate wrong answers

Option A is wrong because recreating a VolumeSnapshot with the same UID is impossible — UIDs are system-assigned and immutable, and the original snapshot is gone. Option B is wrong because restarting the snapshot-controller does not remove orphaned content objects; it only re-syncs state and will not delete retained content. Option C is wrong because oc prune snapshots --force is not a valid OpenShift command; there is no such prune subcommand for snapshots.

Practice this question →
13
MCQeasy

Which access mode specifies that a volume can be mounted as read-write by a single node?

A.WriteOnceMany
B.ReadOnlyMany
C.ReadWriteOnce
D.ReadWriteMany
AnswerC

ReadWriteOnce permits a volume to be mounted as read-write by a single node at a time, which is exactly the constraint the stem specifies. Unlike ReadWriteMany, which allows concurrent read-write mounts across multiple nodes, ReadWriteOnce scopes write access to one node, making it the precise match for this requirement.

Why this answer

ReadWriteOnce (RWO) is the access mode that allows a PersistentVolume to be mounted as read-write by a single node at a time. This is the most common mode for block-backed storage such as AWS EBS, GCE PD, and Ceph RBD, where the underlying device cannot be safely shared across nodes. It does not restrict the number of pods on that node — multiple pods on the same node can share the volume.

Exam trap

EX280 often tests the distinction between 'single node' and 'single pod' — candidates incorrectly assume RWO limits the volume to one pod, when it actually limits it to one node, allowing multiple pods on that node to share it.

How to eliminate wrong answers

Option A is wrong because 'WriteOnceMany' is not a valid Kubernetes access mode — the four valid modes are RWO, ROX, RWX, and RWOP. Option B is wrong because ReadOnlyMany allows many nodes to mount the volume read-only, which is the opposite of read-write single-node. Option D is wrong because ReadWriteMany allows many nodes to mount the volume read-write simultaneously, which requires shared filesystem storage like NFS or CephFS, not block storage.

Practice this question →
14
MCQeasy

An administrator needs to inspect all StorageClasses available in an OpenShift cluster using the OpenShift CLI. Which command should be executed?

A.oc describe storageclasses
B.oc get pvc
C.oc get sc
D.oc get pv
AnswerC

`oc get sc` queries the cluster's StorageClass API resource, returning every StorageClass definition cluster-wide. The `sc` short name maps directly to `storageclasses.storage.k8s.io`, satisfying the requirement to inspect all available StorageClasses via the OpenShift CLI without namespace scoping, since StorageClasses are cluster-scoped objects.

Why this answer

The command 'oc get sc' is the correct and concise way to list all StorageClasses in an OpenShift cluster. 'sc' is the standard abbreviation for 'storageclasses' in the OpenShift CLI, and 'oc get' retrieves the list of resources. This command provides a quick overview of available StorageClasses, which is essential for administrators managing persistent storage.

Exam trap

EX280 often tests the difference between similar resource types like StorageClasses, PersistentVolumes, and PersistentVolumeClaims. Candidates may confuse the abbreviations or select 'oc get pv' thinking it lists StorageClasses, but 'pv' stands for PersistentVolumes.

How to eliminate wrong answers

Option A is wrong because 'oc describe storageclasses' requires a specific StorageClass name to describe; without a name, it will error or list all with verbose details, but it is not the standard command for listing. Option B is wrong because 'oc get pvc' lists PersistentVolumeClaims, not StorageClasses. Option D is wrong because 'oc get pv' lists PersistentVolumes, not StorageClasses.

Practice this question →
15
MCQmedium

A cluster administrator wants to restrict a specific storage class so that only members of a designated OpenShift project can create PVCs referencing it. How is this typically enforced in OpenShift?

A.By assigning RBAC RoleBindings to the StorageClass object directly.
B.By setting accessMode: Restricted in the StorageClass metadata.
C.Using admission control policies or validation webhooks to restrict StorageClass usage by namespace.
D.By adding a namespaces array directly in the StorageClass spec.
AnswerC

Admission control policies and validating webhooks intercept PVC creation requests, evaluating the requesting namespace against rules tied to the StorageClass. This enforces namespace-scoped restrictions that RBAC alone cannot express, limiting usage to the designated OpenShift project.

Why this answer

OpenShift does not natively support per-namespace StorageClass restrictions in the StorageClass spec itself, so enforcement is typically done through admission control — either a ValidatingAdmissionPolicy, a custom validating webhook, or OPA/Gatekeeper constraints that inspect PVC creation requests and reject those referencing a restricted StorageClass from unauthorised namespaces. This is the standard pattern for multi-tenant storage isolation.

Exam trap

EX280 often tests whether candidates invent non-existent StorageClass fields (like 'namespaces' or 'accessMode: Restricted') instead of recognising that OpenShift relies on admission control for this kind of policy — the trap is assuming a declarative field exists when it does not.

How to eliminate wrong answers

Option A is wrong because RBAC RoleBindings cannot be attached to StorageClass objects — StorageClass is a cluster-scoped resource and RBAC does not support per-object bindings of this kind. Option B is wrong because 'accessMode: Restricted' is not a valid StorageClass metadata field; access modes belong on PVs and PVCs, not on the StorageClass metadata. Option D is wrong because the StorageClass spec has no 'namespaces' array — there is no built-in field for namespace scoping, which is precisely why admission control is needed.

Practice this question →
16
MCQeasy

A PersistentVolumeClaim is stuck in Pending state. The administrator checks and finds that the requested StorageClass does not exist. What is the most likely cause?

A.The PVC's requested capacity exceeds the maximum allowed by the default StorageClass.
B.The cluster has no nodes with sufficient capacity to host the volume.
C.The PVC's storageClassName field references a non-existent StorageClass, so no provisioner can satisfy the claim.
D.The PVC's access mode is not supported by any available PersistentVolume.
AnswerC

If the storageClassName in the PVC does not match any existing StorageClass, the PersistentVolume controller cannot find a provisioner to dynamically create a volume. As a result, the PVC remains Pending. The administrator should verify the StorageClass name and create it if missing, or correct the PVC's storageClassName.

Why this answer

A PVC that references a non-existent StorageClass cannot be dynamically provisioned and remains Pending. The controller looks for a StorageClass with the specified name to determine the provisioner and parameters. If none exists, no provisioning occurs.

The administrator must create the StorageClass or update the PVC to use an existing one.

Exam trap

The trap here is assuming that node capacity or access modes cause the Pending state, when the explicit missing StorageClass is the direct cause.

Practice this question →
17
MCQhard

A developer's pod is stuck in ContainerCreating because its PersistentVolumeClaim is bound to a PersistentVolume that was previously attached to a node that has since gone offline without graceful detach. The CSI driver reports the volume as still attached to the failed node. Which action should the administrator take to allow the pod to start on a healthy node?

A.Cordon the healthy node and drain it to force the scheduler to place the pod on another node.
B.Delete the PersistentVolumeClaim and re-create it so a new PersistentVolume is provisioned.
C.Create a VolumeAttachment object for the healthy node to override the existing attachment.
D.Delete the stale VolumeAttachment object associated with the failed node to force the CSI driver to detach and allow reattachment.
AnswerD

The CSI external-attacher represents each volume attachment as a VolumeAttachment object. Removing the stale object tied to the offline node prompts the driver to release the attachment, after which the pod can attach the volume on a healthy node. This is the targeted remediation for an orphaned attachment.

Why this answer

A stale VolumeAttachment pointing at an offline node prevents the CSI driver from attaching the volume elsewhere. Deleting that orphaned VolumeAttachment object forces the external-attacher to reconcile the state, releasing the volume so it can attach to a healthy node and let the pod start.

Exam trap

The trap here is deleting the PVC to resolve the stuck pod, which risks data loss rather than clearing the stale attachment object that actually blocks reattachment.

Practice this question →
18
MCQhard

An administrator is configuring ephemeral storage limits for containers in a namespace. Where must these limits be defined to enforce maximum local scratch space usage per container?

A.ResourceQuota
B.StorageClass
C.LimitRange
D.PersistentVolumeClaim
AnswerC

LimitRange enforces per-container resource bounds within a namespace, including ephemeral-storage requests and limits. Defining the maximum local scratch space there caps each container's writable layer and emptyDir usage, which is exactly the per-container enforcement the administrator needs.

Why this answer

LimitRange objects define per-container (and per-pod) default, minimum, and maximum resource constraints — including ephemeral-storage — within a namespace. To enforce a maximum local scratch space per container, you set the ephemeral-storage max in a LimitRange, which the API server enforces at admission time. ResourceQuota, by contrast, caps aggregate namespace usage, not per-container limits.

Exam trap

EX280 often tests the LimitRange vs ResourceQuota distinction — candidates pick ResourceQuota for per-container limits when the question specifically asks about maximum per-container scratch space, which is a LimitRange responsibility.

How to eliminate wrong answers

Option A is wrong because ResourceQuota enforces total namespace-wide consumption (e.g., sum of all ephemeral-storage requests/limits), not per-container maximums. Option B is wrong because StorageClass defines how persistent volumes are dynamically provisioned, not ephemeral storage limits. Option D is wrong because PersistentVolumeClaim is a request for persistent storage and has no role in limiting container ephemeral (local) storage.

Practice this question →
19
MCQmedium

An administrator is reviewing PersistentVolumes and notices several PVs stuck in a Terminating state. What is the most common reason a PV cannot be deleted immediately?

A.etcd disk space is full.
B.The volume attachment object still holds an active lock, or a finalizer prevents deletion until unmounted.
C.The project quota has been exceeded.
D.The apiserver cache is corrupted and requires a cluster reboot.
AnswerB

A PersistentVolume stays in Terminating because its finalizer, `kubernetes.io/pv-protection`, blocks removal while the volume remains bound or attached. The VolumeAttachment object must release its lock once the node confirms unmounting; only then does the controller clear the finalizer and allow deletion.

Why this answer

A PersistentVolume in a Terminating state is almost always waiting on the Kubernetes volume lifecycle controller to finish detaching the volume from any node that still has it mounted. The VolumeAttachment object holds a lock, and the PV carries the `kubernetes.io/pv-protection` finalizer, which the controller removes only after the volume is fully unmounted and detached. Until that happens, the API server cannot complete deletion, so the PV remains stuck in Terminating.

Exam trap

EX280 often tests whether candidates understand that PV deletion is gated by volume detachment and finalizers, not by generic cluster health issues like etcd space or apiserver cache corruption.

How to eliminate wrong answers

Option A is wrong because a full etcd disk would cause cluster-wide write failures and API server errors, not a targeted PV stuck in Terminating. Option C is wrong because project quota limits the number of objects and resource consumption in a namespace; it does not block PV deletion and would surface as quota admission errors, not a Terminating PV. Option D is wrong because apiserver cache corruption is not a real condition that requires a cluster reboot — the apiserver cache is rebuilt from etcd, and no supported Kubernetes operation requires rebooting the cluster to fix a PV.

Practice this question →
20
MCQeasy

An administrator needs to deploy a StorageClass that automatically provisions volumes only when a PersistentVolumeClaim is created and consumed by a Pod. Which StorageClass parameter determines this behavior?

A.reclaimPolicy: Retain
B.provisioningMode: Immediate
C.volumeBindingMode: WaitForFirstConsumer
D.allowVolumeExpansion: true
AnswerC

WaitForFirstConsumer defers volume provisioning until a Pod using the PVC is scheduled, satisfying the stem's requirement that provisioning occur only on Pod consumption. Immediate mode would provision at PVC creation instead, so this binding mode is the deciding parameter.

Why this answer

'volumeBindingMode: WaitForFirstConsumer' in a StorageClass delays dynamic provisioning and PV binding until a Pod using the PVC is scheduled. This ensures the volume is created in the same topology zone/node as the Pod, which is essential for local storage and topology-constrained cloud volumes. 'Immediate' (the default) provisions as soon as the PVC is created, which can cause scheduling failures if the volume lands in an incompatible zone.

Exam trap

EX280 often tests the exact StorageClass field name and value — candidates pick plausible-sounding but non-existent fields like 'provisioningMode: Immediate' instead of the real 'volumeBindingMode: WaitForFirstConsumer'.

How to eliminate wrong answers

Option A is wrong because reclaimPolicy: Retain controls what happens to the PV after the PVC is deleted (keep vs delete), not when provisioning occurs. Option B is wrong because 'provisioningMode: Immediate' is not a valid StorageClass field — the correct field is volumeBindingMode with values Immediate or WaitForFirstConsumer. Option D is wrong because allowVolumeExpansion: true only permits resizing PVCs after creation; it has nothing to do with provisioning timing.

Practice this question →
21
MCQmedium

You are examining a PersistentVolume in OpenShift and notice its status is Released. What does this indicate?

A.The PV is currently bound to an active PVC and is in use by a running pod.
B.The PV has failed its health check and has been quarantined by the CSI driver.
C.The PV is available for binding by any new incoming PVC request.
D.The PVC associated with the PV has been deleted, but the volume has not yet been reclaimed.
AnswerD

A Released status means the bound PersistentVolumeClaim was deleted, leaving the PersistentVolume without a claim. The volume retains its data and remains unavailable for new claims until an administrator manually reclaims it, either by deleting and recreating the PV or clearing its claimRef, depending on the configured persistentVolumeReclaimPolicy.

Why this answer

A PersistentVolume in Released state means its bound PersistentVolumeClaim was deleted, but the PV has not yet been reclaimed or recycled. The PV still holds the data and remains unavailable for new claims until an administrator manually intervenes (e.g., deletes and recreates the PV, or clears the claimRef). This is distinct from Available (ready for binding) and Bound (actively attached to a PVC).

Exam trap

EX280 often tests the distinction between Available, Bound, and Released PV phases — candidates confuse Released with Available and assume the volume is immediately reusable.

How to eliminate wrong answers

Option A is wrong because a PV actively bound to a PVC and used by a pod shows status Bound, not Released. Option B is wrong because there is no 'quarantined' PV status in Kubernetes/OpenShift; CSI failures surface as Failed or via events, not a Released state. Option C is wrong because Available is the status indicating a PV is free for binding by a new PVC; Released means the claim was deleted but the volume has not been reclaimed.

Practice this question →
22
MCQhard

A developer deploys a pod with an emptyDir volume. The application running inside writes temporary files. What happens to these files when the container crashes and restarts within the same pod?

A.The files are backed up to the cluster control plane automatically.
B.The files are preserved because emptyDir lifetime is tied to the pod, not individual containers.
C.The files are deleted immediately because the container filesystem is ephemeral.
D.The volume is unmounted and reattached via the CSI driver.
AnswerB

emptyDir volumes are scoped to the pod's lifetime, not the container's, so a container crash and restart within the same pod leaves the directory intact. Data is only destroyed when the pod itself is deleted or rescheduled to another node.

Why this answer

An emptyDir volume in Kubernetes is created when a pod is assigned to a node and exists for the lifetime of that pod. If a container within the pod crashes and restarts, the emptyDir volume and its data persist because the pod itself has not been deleted. The files are preserved as long as the pod remains on the node.

Exam trap

EX280 often tests the misconception that emptyDir data is lost when a container restarts, but it actually persists until the pod is deleted, so candidates must distinguish between container restarts and pod deletion.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are not backed up to the control plane; they are local to the node and ephemeral. Option C is wrong because while the container filesystem is ephemeral, the emptyDir volume is separate and persists across container restarts within the same pod. Option D is wrong because emptyDir volumes do not use CSI drivers; they are node-local and managed by kubelet, not by a CSI plugin.

Practice this question →
23
Multi-Selectmedium

Which TWO methods can be used to populate data into a newly created PersistentVolumeClaim during provisioning?

Select 2 answers
A.Setting volumeMode to Populate in the PVC spec.
B.Mounting a container image registry directly via PVC metadata.
C.Referencing an existing PersistentVolumeClaim in the PVC dataSource field for cloning.
D.Referencing a VolumeSnapshot in the PVC dataSource field.
E.Specifying an emptyDir template in the PVC spec.
AnswersC, D

Cloning satisfies the provisioning-time population requirement by using the dataSource field to reference a source PVC, letting the CSI driver copy its contents into the new volume. This works only where the storage class and driver support volume cloning, and the source PVC must reside in the same namespace as the target.

Why this answer

Option C is correct because Kubernetes supports PVC cloning: a new PVC can specify an existing PVC in its spec.dataSource field (dataSource.kind: PersistentVolumeClaim), and the CSI driver then provisions the new volume with a copy of the source PVC's data. Option D is correct because a PVC can reference a VolumeSnapshot via spec.dataSource (dataSource.kind: VolumeSnapshot, apiGroup: snapshot.storage.k8s.io), which restores the snapshot's contents into the newly provisioned volume. Both mechanisms are standard ways to pre-populate a freshly created PVC at provisioning time.

Option A is wrong because volumeMode only accepts Filesystem or Block and has nothing to do with populating data. Option B is wrong because PVC metadata cannot mount or pull from a container image registry. Option E is wrong because emptyDir is a pod-level ephemeral volume type and cannot be specified as a template inside a PVC spec.

Exam trap

EX280 often tests whether candidates confuse Pod-level volume types (emptyDir, configMap, secret) with PVC-level data population mechanisms, or invent non-existent fields like volumeMode: Populate.

Practice this question →
24
MCQmedium

An administrator needs to back up application data stored on an OpenShift PVC. Which object must be created to initiate the snapshot process via the CSI driver?

A.VolumeSnapshot
B.BackupCR
C.VolumeSnapshotContent
D.StorageSnapshot
AnswerA

VolumeSnapshot is the CSI snapshot custom resource that references a PersistentVolumeClaim and triggers the driver's CreateSnapshot call. Creating it initiates the snapshot; VolumeSnapshotContent is the resulting cluster-scoped object, and VolumeSnapshotClass defines the driver and deletion policy.

Why this answer

The VolumeSnapshot object is the user-facing custom resource that requests a snapshot of a PersistentVolumeClaim (PVC) when using a CSI driver that supports snapshotting. It is created by the administrator to initiate the snapshot process, and it triggers the creation of a VolumeSnapshotContent object that represents the actual snapshot on the storage backend. This is part of the Kubernetes CSI snapshot API, which OpenShift supports.

Exam trap

EX280 often tests the distinction between user-facing and cluster-scoped resources in the CSI snapshot API, causing candidates to confuse VolumeSnapshot with VolumeSnapshotContent.

How to eliminate wrong answers

Option B is wrong because BackupCR is not a standard Kubernetes or OpenShift object for initiating volume snapshots; it might be confused with backup solutions like Velero, but it is not part of the CSI snapshot mechanism. Option C is wrong because VolumeSnapshotContent is a cluster-scoped resource that represents the actual snapshot on the storage system, but it is not created by the user to initiate a snapshot; it is dynamically provisioned by the CSI driver when a VolumeSnapshot is created. Option D is wrong because StorageSnapshot is not a valid Kubernetes or OpenShift object; it is a distractor that sounds plausible but does not exist in the CSI snapshot API.

Practice this question →
25
Multi-Selecthard

Which THREE items can be inspected using 'oc describe' when troubleshooting a failing storage attachment in OpenShift?

Select 3 answers
A.The cluster image registry configuration
B.The PersistentVolumeClaim (to check binding status and provisioner errors)
C.The Pod (to see scheduling or volume mount failure events)
D.The OAuth client credentials secret
E.The PersistentVolume (to verify node attachments and reclaim policies)
AnswersB, C, E

Describing the PVC reveals its binding phase, bound PV, and provisioner or CSI errors recorded as events, directly exposing why attachment stalled. This satisfies the scenario's need to inspect claim-level status during a failing storage attachment.

Why this answer

Option B is correct because 'oc describe pvc <name>' shows the PersistentVolumeClaim's status, bound volume, and provisioner-related events, which directly reveal binding failures or dynamic provisioning errors during a storage attachment problem. Option C is correct because 'oc describe pod <name>' surfaces scheduling decisions and volume mount events (such as FailedMount or FailedAttachVolume), pinpointing why a pod cannot attach or mount its storage. Option E is correct because 'oc describe pv <name>' reports the PersistentVolume's status, claim reference, reclaim policy, and node affinity/attachment details, helping verify whether the volume is available and attachable to the target node.

Option A is not applicable because the cluster image registry configuration is inspected via registry operator resources or configs (for example 'oc get configs.imageregistry.operator.openshift.io'), not as a storage attachment object. Option D is not applicable because OAuth client credentials are stored in a Secret and relate to authentication, not to diagnosing storage attachment failures.

Exam trap

EX280 often tests whether candidates confuse cluster-scoped operator configuration objects (like image registry config) with the specific namespaced resources that actually carry storage status and events.

Practice this question →
26
MCQhard

An administrator wants to verify which CSI driver plugins are registered and active in an OpenShift cluster. Which cluster-scoped resource should they query?

A.csidrivers.storage.k8s.io
B.volumesnapshotclasses.snapshot.storage.k8s.io
C.storageclasses.storage.k8s.io
D.csinodes.storage.k8s.io
AnswerA

Querying `csidrivers.storage.k8s.io` lists every registered CSI driver across the cluster, satisfying the cluster-scoped requirement in the stem. Each object records the driver's name and attached volume lifecycle operations, so the administrator can confirm which plugins are active without inspecting individual nodes or pods.

Why this answer

The cluster-scoped resource that lists registered CSI drivers is csidrivers.storage.k8s.io. This resource represents the CSI drivers that are registered with the Kubernetes cluster and provides information about their capabilities, such as whether they support attach/detach operations. Querying this resource shows which CSI drivers are active and available for use.

Exam trap

EX280 often tests the distinction between cluster-scoped and node-scoped CSI resources, and candidates may confuse CSIDriver with CSINode, leading them to choose the wrong resource.

How to eliminate wrong answers

Option B is wrong because volumesnapshotclasses.snapshot.storage.k8s.io defines classes for volume snapshots, not the CSI drivers themselves. Option C is wrong because storageclasses.storage.k8s.io defines storage classes that map to provisioners, but it does not list the CSI drivers directly; it only references them. Option D is wrong because csinodes.storage.k8s.io provides information about the CSI drivers available on each node, but it is not the cluster-scoped resource that lists all registered CSI drivers; it is node-specific.

Practice this question →
27
MCQhard

An administrator wants to use raw block storage (Block Volume Mode) rather than a mounted filesystem for a high-performance database running on OpenShift. How should the volume mode be specified in the PersistentVolumeClaim?

A.mountOptions: [ "raw" ]
B.accessMode: RawBlock
C.storageType: Unformatted
D.volumeMode: Block
AnswerD

Setting `volumeMode: Block` in the PVC spec requests a raw block device, so OpenShift binds a PersistentVolume and presents it to the pod as an unformatted block device rather than mounting a filesystem. This satisfies the stem's requirement for raw block storage, letting the database manage its own I/O directly.

Why this answer

Raw block storage is requested by setting 'volumeMode: Block' in the PersistentVolumeClaim spec. This tells the CSI driver and kubelet to expose the volume as an unformatted block device (e.g., /dev/xvda) inside the pod rather than mounting a filesystem, which is required for databases that manage their own I/O and formatting.

Exam trap

EX280 often tests whether candidates know the exact field name 'volumeMode: Block' — distractors like 'accessMode: RawBlock' or 'mountOptions: ["raw"]' exploit confusion between access modes, mount options, and volume modes.

How to eliminate wrong answers

Option A is wrong because 'mountOptions: ["raw"]' is not a valid Kubernetes field for requesting block mode — mountOptions only apply to filesystem mounts and 'raw' is not a recognized mount option. Option B is wrong because 'accessMode: RawBlock' is invalid; accessModes are ReadWriteOnce, ReadOnlyMany, ReadWriteMany, and ReadWriteOncePod, none of which is 'RawBlock'. Option C is wrong because 'storageType: Unformatted' is not a Kubernetes PVC field at all — it's a fabricated key.

Practice this question →
28
Multi-Selectmedium

Which TWO conditions will prevent a pod from successfully mounting a PersistentVolumeClaim?

Select 2 answers
A.The pod is running in the default project.
B.The PVC is in a Pending state because it failed to bind or provision.
C.The volume is already attached to another node and cannot be multi-attached (RWO constraint).
D.The StorageClass has allowVolumeExpansion set to true.
E.The pod namespace has excess CPU limits.
AnswersB, C

A Pending PVC has no bound PersistentVolume, so the kubelet cannot resolve the claim to a volume source when constructing the pod's volume mounts. The mount therefore fails, satisfying the stem's requirement that the pod cannot successfully mount the claim. Binding must complete before any pod referencing that claim can start.

Why this answer

Option B is correct because a PersistentVolumeClaim must be Bound before a pod can mount it; if the PVC remains Pending due to a binding or dynamic provisioning failure (e.g., no matching PV, missing StorageClass, or provisioner error), the kubelet cannot attach and mount the volume, so the pod stays in ContainerCreating. Option C is correct because a ReadWriteOnce (RWO) PersistentVolume can only be attached to a single node at a time; if the volume is already attached to another node, the new pod's mount fails with a Multi-Attach error until the volume is detached. Option A is wrong because running in the default namespace does not by itself prevent PVC mounting—namespaces only affect which PVCs/PVs are visible, and a valid PVC in the same namespace works fine.

Option D is wrong because allowVolumeExpansion=true merely permits resizing a PVC after creation and has no negative effect on mounting. Option E is wrong because CPU limits are a scheduling/resource concern and do not block volume attach or mount operations.

Exam trap

EX280 often tests whether candidates confuse PVC binding state and access mode constraints with unrelated factors like namespace, CPU limits, or StorageClass expansion settings.

Practice this question →
29
MCQhard

A cluster administrator has created a VolumeSnapshotClass and a VolumeSnapshot object targeting an active PVC. However, the VolumeSnapshot status never shows ready to use, and the underlying storage provider logs indicate snapshot creation failed due to missing cluster permissions. Which core OpenShift operator is primarily responsible for managing volume snapshot controllers and CRDs in OpenShift 4.14?

A.The Ingress Operator
B.The Cluster Storage Operator
C.The Authentication Operator
D.The Machine Config Operator
AnswerB

The Cluster Storage Operator installs and manages the CSI drivers, VolumeSnapshotClass and VolumeSnapshot CRDs, and their snapshot controllers across the cluster. Missing cluster permissions for snapshot creation therefore trace back to this operator's RBAC and controller management, not the CSI driver alone.

Why this answer

The Cluster Storage Operator is responsible for deploying and managing the CSI drivers, snapshot controllers, and associated CRDs (VolumeSnapshotClass, VolumeSnapshot, VolumeSnapshotContent) in OpenShift 4.x. When snapshot creation fails due to missing cluster permissions, the Cluster Storage Operator's deployed controller is the component that requires the RBAC to create snapshots via the CSI driver.

Exam trap

EX280 often tests confusion between storage operators and other cluster operators, tricking candidates into selecting the Machine Config Operator because it sounds infrastructure-related.

How to eliminate wrong answers

Option A is wrong because the Ingress Operator manages router and ingress controller components, not storage snapshot controllers. Option C is wrong because the Authentication Operator handles OAuth and identity providers, unrelated to volume snapshots. Option D is wrong because the Machine Config Operator manages node configuration and OS-level updates, not CSI snapshot CRDs or controllers.

Practice this question →
30
MCQeasy

What is the primary difference between PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs)?

A.PVs represent actual cluster storage resources, while PVCs represent user requests for storage.
B.PVs only support block mode, while PVCs only support filesystem mode.
C.PVs are created by developers, while PVCs are created by cluster administrators.
D.PVs are namespace-scoped, while PVCs are cluster-scoped.
AnswerA

A PersistentVolume is the cluster-scoped, provisioned storage object itself, whereas a PersistentVolumeClaim is a namespaced request that binds to a matching PV. This satisfies the stem's demand for the primary difference: PVs supply capacity, PVCs consume it, decoupling pod specifications from the underlying storage implementation.

Why this answer

PersistentVolumes (PVs) are cluster-level storage objects that represent the actual backing storage (NFS, iSCSI, cloud disk, etc.) provisioned by an admin or dynamically by a StorageClass. PersistentVolumeClaims (PVCs) are namespace-scoped requests from a user/pod for a certain size and access mode, which the control plane binds to a matching PV. This separation of 'supply' (PV) from 'demand' (PVC) is the core abstraction in Kubernetes/OpenShift storage.

Exam trap

EX280 often tests the direction of the PV/PVC relationship — candidates confuse which object is the 'supply' (cluster-scoped PV) versus the 'request' (namespace-scoped PVC), or assume one is admin-only and the other developer-only without realizing dynamic provisioning blurs that line.

How to eliminate wrong answers

Option B is wrong because both PVs and PVCs support Filesystem and Block volume modes (set via volumeMode), not a block-only vs filesystem-only split. Option C is wrong because it reverses the roles: cluster administrators typically create PVs (or StorageClasses for dynamic provisioning), while developers/users create PVCs. Option D is wrong because it inverts the scopes: PVs are cluster-scoped, while PVCs are namespace-scoped.

Practice this question →
31
MCQhard

A team maintains a StatefulSet named `orders` with three replicas in the `sales` namespace. Each replica must receive its own 20Gi PersistentVolumeClaim that survives Pod restarts and rescheduling, and the storage backend supports the ReadWriteOnce access mode. The administrator needs to define the storage requirement so that every replica automatically gets an independent, stable PVC bound before the Pod starts. Which approach should the administrator use?

A.Define the volume inline in the StatefulSet Pod template using `emptyDir: {medium: Memory}` and set `sizeLimit: 20Gi` so each replica receives its own isolated 20Gi scratch volume.
B.Add a `volumeClaimTemplates` entry in the StatefulSet spec defining a 20Gi claim with the required access mode and StorageClass, and mount it with a `volumeMounts` reference matching the template name.
C.Create three separate PersistentVolumeClaims manually with names `orders-0`, `orders-1`, and `orders-2`, then add three distinct volume entries to the Pod template, each referencing one of those claim names.
D.Create a single standalone PersistentVolumeClaim named `orders-data` in the `sales` namespace and reference it from each replica using a volume entry with `persistentVolumeClaim.claimName: orders-data`.
AnswerB

The `volumeClaimTemplates` field instructs the StatefulSet controller to generate one PVC per replica, named with the pattern `<template-name>-<statefulset-name>-<ordinal>`. Each replica therefore receives a dedicated 20Gi claim bound before the Pod is scheduled, and the claim persists across restarts and rescheduling, satisfying the independent and stable storage requirement.

Why this answer

StatefulSets provide per-replica stable storage through `volumeClaimTemplates`, which the controller expands into one PVC per ordinal. This guarantees each replica gets its own 20Gi ReadWriteOnce claim bound before the Pod starts, and the claim persists across restarts and rescheduling. Standalone claims, inline emptyDir volumes, or manually named claims cannot deliver the independent, automatically provisioned identity-based storage the scenario requires.

Exam trap

The trap here is assuming that any PVC referenced in the Pod template gives each replica its own volume, when only `volumeClaimTemplates` generates distinct claims per ordinal.

Practice this question →
32
MCQmedium

A cluster administrator wants to create a VolumeSnapshot of a database PVC. Which API group must the VolumeSnapshotClass belong to?

A.snapshot.storage.k8s.io
B.storage.k8s.io
C.csi.storage.k8s.io
D.volumesnapshot.openshift.io
AnswerA

VolumeSnapshotClass resources are defined in the snapshot.storage.k8s.io API group, which the external-snapshotter project provides. This satisfies the stem's requirement for snapshotting a database PVC, since the CSI snapshot CRDs (VolumeSnapshot, VolumeSnapshotClass, VolumeSnapshotContent) all live in that group, not in storage.k8s.io or v1.

Why this answer

VolumeSnapshotClass resources are part of the Kubernetes CSI snapshot API group 'snapshot.storage.k8s.io'. This API group defines the VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass custom resources. Therefore, the VolumeSnapshotClass must belong to this API group to be recognized by the CSI snapshot controller.

Exam trap

EX280 often tests the correct API group for custom resources. Candidates might confuse 'snapshot.storage.k8s.io' with 'storage.k8s.io' or 'csi.storage.k8s.io', but only the former is used for VolumeSnapshotClass.

How to eliminate wrong answers

Option B is wrong because 'storage.k8s.io' is the API group for StorageClass, VolumeAttachment, and CSIDriver, but not for VolumeSnapshotClass. Option C is wrong because 'csi.storage.k8s.io' is used for CSI driver-specific resources like CSINode, but not for snapshot classes. Option D is wrong because 'volumesnapshot.openshift.io' is not a standard API group; OpenShift uses the upstream Kubernetes snapshot API group.

Practice this question →
33
MCQmedium

A developer wants to ensure that a pod's temporary storage does not exceed 2Gi and that the pod is terminated or throttled if it exceeds this limit. Where should this ephemeral storage limit be declared?

A.In the container's spec.resources.limits under 'ephemeral-storage'.
B.In the emptyDir volume specification under 'sizeLimit'.
C.In the StorageClass under 'parameters.ephemeralLimit'.
D.In the persistentVolumeClaim under 'spec.ephemeral'.
AnswerA

Ephemeral storage is governed by the container-level resources.limits field, where ephemeral-storage requests and limits are declared alongside CPU and memory. Placing the 2Gi limit there satisfies the stem's requirement to cap and evict pods exceeding that threshold.

Why this answer

Ephemeral storage limits are declared in the container's spec.resources.limits under the 'ephemeral-storage' key, just like CPU and memory. This causes the kubelet to enforce the limit by evicting the pod when local ephemeral storage usage exceeds the configured value. The limit applies to the container's writable layer, emptyDir volumes, and logs, making it the correct place for a 2Gi cap.

Exam trap

EX280 often tests the distinction between emptyDir sizeLimit and container ephemeral-storage limits, tricking candidates into choosing the volume-level cap when the question asks for pod termination on exceeding the limit.

How to eliminate wrong answers

Option B is wrong because emptyDir's sizeLimit only caps that specific volume's size and does not terminate or throttle the pod when exceeded — it just prevents further writes to that volume. Option C is wrong because StorageClass parameters are for dynamic provisioning of persistent volumes and have no 'ephemeralLimit' parameter. Option D is wrong because PVCs do not have a 'spec.ephemeral' field; ephemeral storage is a container resource, not a PVC attribute.

Practice this question →
34
Multi-Selectmedium

An administrator is configuring a new StorageClass in OpenShift Container Platform 4.14. Which TWO parameters or fields are valid and commonly used specifications within a StorageClass manifest? (Choose TWO)

Select 2 answers
A.podSecurityContext
B.nodeAffinityRules
C.reclaimPolicy
D.maximumSnapshotLimit
E.volumeBindingMode
AnswersC, E

ReclaimPolicy is a valid StorageClass field controlling volume behaviour after PVC deletion, accepting Delete or Retain. It satisfies the stem's requirement for commonly used specifications within a StorageClass manifest, governing whether underlying storage is automatically removed or preserved for manual reclamation.

Why this answer

Option C (reclaimPolicy) is correct because a StorageClass manifest supports the reclaimPolicy field, which determines what happens to a PersistentVolume after its PersistentVolumeClaim is deleted—valid values are Delete and Retain, with Delete being the default for dynamically provisioned volumes. Option E (volumeBindingMode) is correct because it is a standard StorageClass field that controls when volume binding and dynamic provisioning occur, with valid values Immediate and WaitForFirstConsumer, the latter being essential for topology-aware scheduling. The other options are not StorageClass fields: podSecurityContext (A) is a Pod/container security setting, nodeAffinityRules (B) is not a valid StorageClass parameter (node affinity belongs to PersistentVolume nodeAffinity or Pod scheduling), and maximumSnapshotLimit (D) is not a recognized StorageClass specification in OpenShift 4.14.

Exam trap

EX280 often tests whether candidates can distinguish StorageClass fields from Pod-level or PV-level fields, since similarly named constructs like nodeAffinity and securityContext appear in other Kubernetes objects.

Practice this question →
35
Multi-Selectmedium

An administrator must grant a service account permission to create and manage PersistentVolumeClaims in the project 'analytics', while allowing it to view but not modify PersistentVolumes cluster-wide. Which two actions satisfy these requirements? (Choose two.)

Select 2 answers
A.Bind the 'edit' ClusterRole to the service account using a ClusterRoleBinding.
B.Bind the 'cluster-reader' ClusterRole to the service account using a ClusterRoleBinding.
C.Bind the 'edit' ClusterRole to the service account in the 'analytics' namespace using a RoleBinding.
D.Bind the 'view' ClusterRole to the service account in the 'analytics' namespace using a RoleBinding.
E.Create a ClusterRole granting get, list, and watch on persistentvolumes, and bind it to the service account with a ClusterRoleBinding.
AnswersC, E

The edit ClusterRole includes permissions to create, delete, and modify PersistentVolumeClaims within a namespace. Binding it with a RoleBinding scopes those rights to the analytics project, granting the service account full PVC management exactly as required, without extending any cluster-wide write access to PersistentVolumes.

Why this answer

PVCs are namespaced, so the edit ClusterRole bound via a RoleBinding in analytics grants create and manage rights scoped to that project. PersistentVolumes are cluster-scoped, so read-only access requires a ClusterRole with get, list, and watch bound by a ClusterRoleBinding. Together these satisfy management of claims and read-only visibility of volumes.

Exam trap

The trap here is assuming a namespaced RoleBinding can grant access to the cluster-scoped PersistentVolume resource, which requires a ClusterRoleBinding instead.

Practice this question →
36
MCQmedium

A pod fails to start, and the event log shows a Multi-Attach error for volume 'pvc-xyz'. What is the root cause of this error?

A.A ReadWriteOnce volume is attempting to be attached to a second node while still attached to the first.
B.The PVC storage class has volumeBindingMode set to Immediate.
C.The storage backend has run out of physical disk capacity.
D.The CSI driver pod has crashed on the master node.
AnswerA

A ReadWriteOnce volume permits attachment to only one node at a time. When a second node tries to attach it while the first still holds it, the CSI driver reports Multi-Attach. This satisfies the stem's stated error condition.

Why this answer

The Multi-Attach error occurs when a ReadWriteOnce (RWO) volume is already attached to one node and a pod on another node tries to attach it. RWO volumes can only be attached to a single node at a time. This is common with block storage like AWS EBS or GCE PD.

Exam trap

The trap is confusing Multi-Attach with other volume errors, such as provisioning failures or capacity issues, when the root cause is the RWO access mode and node affinity.

How to eliminate wrong answers

Option B is wrong because volumeBindingMode Immediate affects when a volume is provisioned, not multi-attach errors. Option C is wrong because running out of disk capacity would cause a different error, such as 'no space left'. Option D is wrong because a crashed CSI driver would prevent any volume operations, not specifically cause a multi-attach error.

Practice this question →
37
MCQeasy

Which YAML key in a StorageClass definition specifies the CSI plugin responsible for provisioning the storage?

A.storagePlugin
B.plugin
C.driverName
D.provisioner
AnswerD

provisioner defines the driver plugin name (e.g., ebs.csi.aws.com).

Why this answer

The provisioner field in a StorageClass identifies the CSI driver (or in-tree provisioner) responsible for dynamically provisioning PersistentVolumes. For CSI-based storage, its value is the driver name registered by the CSI plugin, such as ebs.csi.aws.com or csi.ceph.com. Without a valid provisioner, the StorageClass cannot create PVs.

Exam trap

EX280 often tests exact YAML key names — candidates confuse provisioner with driverName because CSI terminology uses 'driver' elsewhere.

How to eliminate wrong answers

Option A is wrong because storagePlugin is not a valid StorageClass field in the storage.k8s.io/v1 API. Option B is wrong because plugin is not a recognized key; it resembles legacy or invented terminology. Option C is wrong because driverName is a field used inside CSI volume attributes or CSIDriver objects, not the top-level StorageClass key that names the provisioner.

Practice this question →
38
MCQhard

An administrator creates a StorageClass with volumeBindingMode: WaitForFirstConsumer. A user creates a PVC using this StorageClass. What will be the initial phase of the PVC?

A.Provisioning
B.Bound
C.Pending
D.Available
AnswerC

WaitForFirstConsumer defers provisioning until a pod using the PVC is scheduled, so no PersistentVolume is bound at creation. The PVC therefore sits in Pending, satisfying the stem's constraint that binding waits for a consumer, rather than immediately entering Bound as with Immediate mode.

Why this answer

When a StorageClass has volumeBindingMode: WaitForFirstConsumer, the PVC will remain in the Pending phase until a pod that uses it is scheduled. This is because the volume binding is delayed until the pod's scheduling requirements are known, allowing the volume to be provisioned in the same zone as the pod.

Exam trap

EX280 often tests the misconception that a PVC is immediately Bound when using WaitForFirstConsumer, when it actually stays Pending until a pod is scheduled.

How to eliminate wrong answers

Option A is wrong because 'Provisioning' is not a valid PVC phase; the phases are Pending, Bound, Lost, etc. Option B is wrong because the PVC cannot be Bound until a pod is scheduled and the volume is provisioned. Option D is wrong because 'Available' is a phase for PersistentVolumes, not PVCs.

Practice this question →
39
MCQhard

An administrator configures a Pod with a volume type of hostPath. What is a key security risk or operational limitation of using hostPath in a production multi-tenant OpenShift cluster?

A.Pods using hostPath can access node filesystems, breaking container isolation and posing security risks.
B.hostPath volumes automatically expire and delete data after 24 hours.
C.hostPath requires an external CSI driver to be installed.
D.hostPath is incompatible with Linux nodes and only works on Windows worker nodes.
AnswerA

hostPath mounts a directory from the node's filesystem into the Pod, so a compromised container can read or modify node files and potentially escape isolation. This breaks the tenant boundary expected in a multi-tenant OpenShift cluster.

Why this answer

A hostPath volume mounts a directory or file from the node's filesystem directly into the pod. This breaks the container isolation boundary because the pod can read or write node-level files — including /etc, /var/lib/kubelet, or the container runtime socket — enabling privilege escalation, data exfiltration, or node compromise. In multi-tenant clusters this is a serious security risk.

Exam trap

EX280 often tests whether candidates recognize hostPath as a node-isolation break — the exam expects you to know it is blocked by the restricted SCC and is a multi-tenant security anti-pattern.

How to eliminate wrong answers

Option B is wrong because hostPath volumes have no expiration or TTL — data persists on the node until manually deleted, which is actually the opposite of the stated behavior. Option C is wrong because hostPath is a built-in Kubernetes volume type that requires no CSI driver; it is implemented directly by the kubelet. Option D is wrong because hostPath works on Linux nodes (it is the primary use case) and is not Windows-only — the claim inverts reality.

Practice this question →
40
MCQmedium

An administrator is defining a StorageClass that should use the CSI driver 'csi.example.com' and allow volume expansion. The StorageClass must also have a parameter 'type: fast'. Which YAML snippet correctly defines this StorageClass?

A.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: kubernetes.io/csi allowVolumeExpansion: true parameters: driver: csi.example.com type: fast
B.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: csi.example.com allowVolumeExpansion: true parameters: type: fast volumeBindingMode: WaitForFirstConsumer
C.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: csi.example.com allowVolumeExpansion: true parameters: type: fast reclaimPolicy: Delete
D.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-storage provisioner: csi.example.com allowVolumeExpansion: true parameters: type: fast
AnswerD

This snippet correctly sets the provisioner to csi.example.com, enables allowVolumeExpansion, and includes the parameter type: fast. The apiVersion and kind are appropriate for a StorageClass. This definition will allow dynamic provisioning using the specified CSI driver and permit expansion of PVCs created from this class.

Why this answer

A StorageClass for a CSI driver must set the provisioner field to the CSI driver name. The allowVolumeExpansion field enables PVC expansion, and parameters pass driver-specific settings. The correct snippet includes these without extraneous fields that could alter behavior or are not requested.

Exam trap

The trap here is using kubernetes.io/csi as the provisioner and specifying the driver in parameters, which is incorrect for CSI-based StorageClasses.

Practice this question →
41
Multi-Selecthard

An administrator is troubleshooting a storage performance issue on an OpenShift cluster using Container Storage Interface (CSI) drivers. Which THREE actions or diagnostic commands are effective for investigating CSI driver health and provisioner issues? (Choose THREE)

Select 3 answers
A.Verify the CSI driver configuration by checking the CSIDriver and CSINode cluster resources.
B.Inspect events on the pending PersistentVolumeClaim using oc describe pvc <pvc-name>.
C.Modify the kubelet configuration file on control plane nodes to increase storage timeout values.
D.Run systemctl restart csi-driver on every worker node to force reconnection to the storage array.
E.Check the logs of the external CSI provisioner deployment running in the driver's namespace.
AnswersA, B, E

Checking CSIDriver and CSINode resources confirms whether the driver is registered and whether its node plugins are present on each node, directly satisfying the stem's need to investigate CSI driver health. Missing CSINode entries reveal node-plugin registration failures that block provisioning, isolating the fault before deeper provisioner log analysis.

Why this answer

Option A is correct because the CSIDriver and CSINode cluster resources define how the CSI driver is registered and which nodes it is available on; inspecting them with oc get csidriver and oc get csinode (or oc describe) reveals misconfigurations such as missing node registration or incorrect attach/detach behavior that cause provisioning failures. Option B is correct because oc describe pvc <pvc-name> surfaces Kubernetes events on the pending PVC, including provisioner errors, topology/volume binding failures, and storage class issues, which are the fastest way to identify why a volume is not being dynamically provisioned. Option E is correct because the external CSI provisioner (typically the csi-provisioner sidecar in the driver controller deployment) emits logs that show gRPC errors, storage backend API failures, and leader-election or RBAC problems directly tied to provisioning issues.

Option C is not correct because kubelet storage timeout values are not the standard diagnostic or remediation for CSI provisioner problems, and modifying control plane kubelet config does not address CSI controller-side provisioning. Option D is not correct because there is no systemctl unit named csi-driver on worker nodes; CSI drivers run as DaemonSets/Deployments in OpenShift, so restarting pods via oc rollout restart or oc delete pod is the proper approach.

Exam trap

EX280 often tests the difference between valid diagnostic commands and invalid or harmful actions, and candidates may choose options that seem plausible but involve unsupported or risky procedures like modifying kubelet configs or restarting systemd services.

Practice this question →
42
MCQmedium

An OpenShift administrator needs to allow users to expand the storage capacity of existing PersistentVolumeClaims without restarting their applications. Which action must be taken first to enable this capability?

A.Restart the csi-provisioner controller deployment in the openshift-cluster-storage-operator namespace.
B.Edit the StorageClass to set allowVolumeExpansion: true.
C.Add the expansion-enabled annotation directly to each active Pod object.
D.Convert all existing static PersistentVolumes into dynamically provisioned volumes.
AnswerB

Setting allowVolumeExpansion: true on the StorageClass is the prerequisite that permits CSI resizing of bound PVCs. Without it, the API rejects expansion requests outright, so applications keep running while the PVC spec's resources.requests.storage is increased.

Why this answer

Online volume expansion in Kubernetes/OpenShift is gated by the StorageClass field allowVolumeExpansion. Until that field is set to true on the StorageClass backing the PVC, the API server will reject any attempt to increase the PVC's requested storage, so it must be enabled first.

Exam trap

EX280 often tests whether candidates know that allowVolumeExpansion is a StorageClass-level setting, not a PVC annotation or a controller restart, and that it must be enabled before any resize attempt.

How to eliminate wrong answers

Option A is wrong because restarting the csi-provisioner does not change the StorageClass policy — expansion remains blocked by the missing allowVolumeExpansion flag. Option C is wrong because Pods have no expansion-enabled annotation; expansion is a PVC/StorageClass concern, not a Pod annotation. Option D is wrong because converting static PVs to dynamic provisioning is unrelated to expansion capability and is not a prerequisite — expansion works on both statically and dynamically provisioned volumes as long as the driver and StorageClass allow it.

Practice this question →
43
MCQmedium

A cluster administrator needs to inspect the current bindings and capacities of all PersistentVolumes across the entire OpenShift cluster. Which CLI command should be used?

A.oc get pvc --all-namespaces
B.oc get pv
C.oc describe storage
D.oc get volume
AnswerB

oc get pv lists PersistentVolume objects cluster-wide, showing each volume's capacity, access modes, reclaim policy and current binding status. It satisfies the requirement to inspect bindings and capacities across the entire cluster without specifying a namespace, unlike project-scoped alternatives.

Why this answer

PersistentVolumes (PVs) are cluster-scoped resources in OpenShift/Kubernetes, so 'oc get pv' lists every PV in the cluster along with its capacity, access modes, reclaim policy, status, and claim binding. Because PVs are not namespaced, no --all-namespaces flag is needed or accepted. This single command gives the administrator the complete cluster-wide view of bindings and capacities requested.

Exam trap

EX280 often tests the distinction between cluster-scoped PVs and namespaced PVCs, tricking candidates into adding --all-namespaces to a PV query or confusing the two resource types.

How to eliminate wrong answers

Option A is wrong because 'oc get pvc --all-namespaces' lists PersistentVolumeClaims, which are namespaced requests for storage, not the PV objects themselves, so it does not show cluster-wide PV capacity or binding state. Option C is wrong because 'storage' is not a valid OpenShift resource type — there is no 'oc describe storage' command; storage is managed via PV, PVC, and StorageClass resources. Option D is wrong because 'volume' is not a top-level OpenShift resource kind; volumes exist only as pod spec fields or as PV/PVC objects, so 'oc get volume' returns an error.

Practice this question →
44
Multi-Selecthard

Which THREE factors influence whether a pod requesting a storage volume can be successfully scheduled to a specific worker node when using topology-aware storage?

Select 3 answers
A.The cluster OAuth token expiration time
B.Volume accessibility constraints reported by the CSI driver
C.The number of container image layers in the pod spec
D.The volumeBindingMode set to WaitForFirstConsumer on the StorageClass
E.Node topology labels (such as failure-domain.beta.kubernetes.io/zone)
AnswersB, D, E

The CSI driver publishes topology keys describing which nodes can reach a given volume. The scheduler filters out nodes failing those accessibility constraints, so a pod cannot land on a worker that cannot attach the requested storage.

Why this answer

Option B is correct because topology-aware scheduling depends on the accessibility constraints the CSI driver reports through CSI topology keys (for example, via the CSINode object and CSIStorageCapacity), which tell the scheduler which nodes can actually reach the volume. Option D is correct because a StorageClass with volumeBindingMode: WaitForFirstConsumer delays PersistentVolume binding until the pod is scheduled, allowing the scheduler to co-locate the pod with the volume's topology instead of binding prematurely. Option E is correct because node topology labels such as topology.kubernetes.io/zone (or the older failure-domain.beta.kubernetes.io/zone) are the actual topology domains the scheduler matches against the volume's node affinity requirements.

Option A is not relevant because OAuth token expiration affects API authentication, not volume topology or scheduling decisions. Option C is not relevant because the number of image layers affects image pull time and storage, not whether a topology-constrained volume can be scheduled to a node.

Exam trap

EX280 often tests the misconception that storage scheduling is purely about capacity — candidates overlook that volumeBindingMode and CSI topology constraints are what actually gate node selection.

Practice this question →
45
Multi-Selecthard

Which THREE parameters or fields are valid when configuring a StorageClass object in OpenShift 4.14+?

Select 3 answers
A.containerRuntime
B.provisioner
C.volumeBindingMode
D.nodeSelector
E.reclaimPolicy
AnswersB, C, E

The provisioner field is mandatory in a StorageClass, naming the CSI driver plugin (for example ebs.csi.aws.com) that dynamically provisions PersistentVolumes. Without it, OpenShift cannot determine which storage backend to call, so the object is rejected.

Why this answer

Option B (provisioner) is correct because every StorageClass must specify the provisioner field, which identifies the volume plugin (e.g., kubernetes.io/aws-ebs, ebs.csi.aws.com, or kubernetes.io/no-provisioner) used to dynamically provision PersistentVolumes. Option C (volumeBindingMode) is correct because it is a valid StorageClass field that controls when volume binding and dynamic provisioning occur, with supported values Immediate and WaitForFirstConsumer. Option E (reclaimPolicy) is correct because StorageClass supports the reclaimPolicy field to define the default PersistentVolume reclaim behavior for dynamically provisioned volumes, with valid values Delete and Retain.

Option A (containerRuntime) is not a StorageClass parameter; it relates to container runtime configuration (e.g., CRI-O) and is not part of the storage.k8s.io/v1 StorageClass schema. Option D (nodeSelector) is not a StorageClass field; node selection for storage is handled via allowedTopologies or in PersistentVolume nodeAffinity, not a nodeSelector key on StorageClass.

Exam trap

EX280 often tests whether candidates confuse StorageClass fields with Pod scheduling fields (nodeSelector) or node-level runtime settings (containerRuntime), which are not part of the StorageClass API.

Practice this question →
46
MCQhard

An administrator is configuring topology-aware storage provisioning. A StorageClass uses volumeBindingMode: WaitForFirstConsumer. When is the PersistentVolume actually created?

A.When the scheduler places the pod referencing the PVC onto a specific worker node.
B.When the PVC object is successfully created in the namespace.
C.When the user executes 'oc adm pv create'.
D.When the CSI driver operator starts up during cluster bootstrap.
AnswerA

With WaitForFirstConsumer, the scheduler delays binding until a pod using the PVC is placed, then provisions the PersistentVolume in the topology zone of that chosen worker node. This satisfies the topology-aware constraint, ensuring storage lands where the pod actually runs rather than being pre-bound to an arbitrary zone.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the PV is not provisioned when the PVC is created. Instead, the scheduler delays binding until a pod using the PVC is scheduled, so it can pick a node and provision the volume in the correct topology zone. The PV is created at that point, ensuring the volume lands in the same zone as the pod.

Exam trap

EX280 often tests whether candidates assume PVC creation immediately triggers PV provisioning, forgetting that WaitForFirstConsumer deliberately defers it until a pod is scheduled.

How to eliminate wrong answers

Option B is wrong because with WaitForFirstConsumer, PVC creation alone does not trigger provisioning — the PVC stays Pending until a consumer pod appears. Option C is wrong because 'oc adm pv create' is not how dynamic provisioning works; PVs are created by the CSI provisioner, not manually. Option D is wrong because CSI driver startup during bootstrap has nothing to do with when a specific PV is provisioned for a given PVC.

Practice this question →
47
MCQeasy

Which resource represents the physical or cloud storage provisioned in the cluster by an administrator, independent of any user namespace claims?

A.StorageClass
B.PersistentVolumeClaim
C.PodVolume
D.PersistentVolume
AnswerD

A PersistentVolume is cluster-scoped storage provisioned by an administrator, existing independently of namespace-bound claims. This directly satisfies the stem's requirement: it represents the actual physical or cloud storage resource itself, not a user's request. PersistentVolumeClaims, by contrast, are namespaced and consume PersistentVolumes rather than defining the underlying provisioned storage.

Why this answer

A PersistentVolume (PV) is the cluster-scoped resource that represents actual storage provisioned by an administrator — an NFS export, EBS volume, or Ceph RBD image — and exists independently of any namespace. It is bound to a PersistentVolumeClaim (PVC) when a user requests storage, but the PV itself is not owned by or scoped to a user namespace.

Exam trap

The trap here is confusing the PV (admin-provisioned, cluster-scoped, the actual storage) with the PVC (user-requested, namespaced, the claim), since both contain 'Volume' and 'Persistent' in their names.

How to eliminate wrong answers

Option A is wrong because StorageClass is a template that describes how to dynamically provision PVs (provisioner, parameters, reclaim policy) — it does not represent actual provisioned storage. Option B is wrong because PersistentVolumeClaim is a namespaced user request for storage that gets bound to a PV; it is the consumer, not the provisioned resource. Option C is wrong because PodVolume is not a standalone Kubernetes API object — volumes are declared inline within a Pod spec (e.g., volumes: under spec), not as a separate cluster resource.

Practice this question →
48
Multi-Selectmedium

Which TWO of the following are valid volume modes supported by PersistentVolumes and PersistentVolumeClaims in OpenShift?

Select 2 answers
A.Object
B.Block
C.Database
D.Filesystem
E.Stream
AnswersB, D

Block volume mode presents storage as a raw block device, bypassing a filesystem layer entirely. This satisfies the stem's requirement for valid PersistentVolume modes, since OpenShift supports both Filesystem and Block, with Block suited to databases and applications managing their own I/O directly.

Why this answer

In OpenShift/Kubernetes, the PersistentVolume spec.volumeMode field accepts exactly two values: Block and Filesystem. Option B (Block) is correct because a PV/PVC with volumeMode: Block exposes the volume as a raw block device with no filesystem, which is required for workloads like databases that manage their own storage layout. Option D (Filesystem) is correct because it is the default volumeMode, where the volume is formatted with a filesystem and mounted into a directory inside the pod.

Options A (Object), C (Database), and E (Stream) are not valid volumeMode values — they are not recognized by the Kubernetes/OpenShift API for PersistentVolumes or PersistentVolumeClaims, so they would be rejected.

Exam trap

EX280 often tests the exact enumeration of volumeMode values, baiting candidates with plausible-sounding but non-existent modes like Object, Stream, or Database.

Practice this question →
49
MCQhard

An application running in OpenShift requires scratch space that lives and dies strictly with the Pod lifecycle, but needs to be mounted from a high-performance cluster-managed storage backend rather than local ephemeral node storage. Which feature should an administrator configure?

A.HostPath volumes mapped to a local directory on the worker node
B.A standard dynamically provisioned PVC with reclaimPolicy set to Delete
C.emptyDir with medium: Memory
D.Generic ephemeral inline volumes via a volume template in the Pod specification
AnswerD

Generic ephemeral volumes let a Pod template request a cluster-managed backend, such as a CSI driver, whose lifecycle is tied to the Pod. This satisfies both constraints: scratch space dies with the Pod, yet storage comes from a high-performance cluster backend rather than node-local disk.

Why this answer

Generic ephemeral inline volumes allow a Pod to specify a volume template that dynamically provisions a PersistentVolumeClaim (PVC) for the Pod's lifetime. The resulting PVC and its backing PersistentVolume (PV) are automatically deleted when the Pod is deleted, satisfying the 'lives and dies with the Pod' requirement. Because the volume is backed by a cluster-managed StorageClass, it can use high-performance storage backends (e.g., NVMe, Ceph RBD) rather than local node storage.

This is the only option that combines Pod-lifecycle-bound ephemeral semantics with cluster-managed persistent storage.

Exam trap

EX280 often tests the distinction between Pod-lifecycle-bound ephemeral storage and cluster-managed persistent storage, tricking candidates into choosing emptyDir or a standard PVC when the requirement explicitly demands both ephemeral lifecycle and a high-performance cluster storage backend.

How to eliminate wrong answers

Option A is wrong because HostPath volumes bind to a directory on the node's filesystem, which is local ephemeral node storage, not a cluster-managed high-performance backend, and the data persists on the node after the Pod is deleted (unless manually cleaned). Option B is wrong because a standard dynamically provisioned PVC with reclaimPolicy Delete is a standalone resource that is not automatically deleted when the Pod is deleted; it must be explicitly removed, so it does not strictly live and die with the Pod lifecycle. Option C is wrong because emptyDir with medium: Memory uses node RAM as ephemeral storage, which is local to the node and not a cluster-managed storage backend, and it is limited by node memory.

Practice this question →
50
MCQeasy

Which field in a PersistentVolumeClaim specifies the minimum amount of storage space required by the workload?

A.spec.storageSize
B.spec.capacity.storage
C.spec.volumeSize
D.spec.resources.requests.storage
AnswerD

spec.resources.requests.storage declares the minimum storage the PVC demands, which the scheduler uses to bind a PersistentVolume with at least that capacity. This directly satisfies the stem's requirement for specifying minimum required space, unlike limits.storage, which caps usage rather than requesting capacity.

Why this answer

In a PVC, the requested storage size is specified under spec.resources.requests.storage, following the standard Kubernetes resource requirements schema. This value is matched against a PV's capacity during binding, and the resulting PV must be at least this size. It is the same pattern used for CPU and memory requests in pod specs.

Exam trap

EX280 often tests exact YAML paths — candidates confuse PVC request fields with PV capacity fields or invent keys like storageSize.

How to eliminate wrong answers

Option A is wrong because spec.storageSize is not a valid PVC field; it resembles a made-up shorthand. Option B is wrong because spec.capacity.storage belongs to a PersistentVolume's status/spec capacity, not a PVC request. Option C is wrong because spec.volumeSize is not a recognized Kubernetes API field.

Practice this question →
51
MCQhard

An administrator needs to increase the size of an existing PVC bound to a gp3 storage class in an OpenShift cluster. What is the mandatory first step before editing the PVC spec?

A.Ensure allowVolumeExpansion: true is set on the corresponding StorageClass.
B.Manually update the underlying cloud provider disk size via the AWS console.
C.Delete the PV and recreate it with the new size.
D.Scale down all pods using the PVC to zero replicas.
AnswerA

Volume expansion only proceeds when the StorageClass permits it, so `allowVolumeExpansion: true` must be present on the gp3 StorageClass before the PVC spec can be edited. Without this field, the API server rejects the resize request, making it the mandatory prerequisite for this scenario.

Why this answer

Before a PVC can be expanded, the StorageClass that provisioned it must have 'allowVolumeExpansion: true' set. Without this field, the PVC's spec.resources.requests.storage cannot be increased — the API server will reject the edit or the resize will never complete. This is the mandatory first step.

Exam trap

EX280 often tests the misconception that you can simply edit the PVC size — candidates forget that the StorageClass must have allowVolumeExpansion: true, and that without it the edit is rejected or never completes. The exam expects you to know this is the mandatory first step.

How to eliminate wrong answers

Option B is wrong because manually resizing the underlying cloud disk bypasses Kubernetes' CSI resize workflow and can leave the PV/PVC status inconsistent; the correct path is to edit the PVC and let the CSI driver handle the resize. Option C is wrong because deleting and recreating the PV would destroy data and is not required — online expansion is supported for gp3 via the EBS CSI driver. Option D is wrong because scaling pods to zero is not a prerequisite for volume expansion; most CSI drivers support online expansion while pods are running, and even offline expansion does not require scaling to zero.

Practice this question →
52
MCQeasy

Which object defines the parameters used by a storage provider to take snapshots of persistent volumes in OpenShift?

A.SnapshotterConfiguration
B.StorageClass
C.VolumeSnapshotContent
D.VolumeSnapshotClass
AnswerD

VolumeSnapshotClass supplies the driver and deletion-policy parameters a CSI storage provider needs when creating a VolumeSnapshot, satisfying the stem's requirement for the object defining snapshot parameters. Unlike VolumeSnapshot, which requests a specific snapshot, the class holds the reusable configuration the driver consumes.

Why this answer

VolumeSnapshotClass is the cluster-scoped object that defines the CSI driver and deletion policy used when taking snapshots of PersistentVolumes. It plays the same role for snapshots that a StorageClass plays for provisioning — it tells the snapshot controller which driver to invoke and how to handle the resulting VolumeSnapshotContent.

Exam trap

EX280 often tests the parallel between StorageClass (provisioning) and VolumeSnapshotClass (snapshotting), so candidates who pattern-match 'class defines parameters' to StorageClass pick the wrong object.

How to eliminate wrong answers

Option A is wrong because SnapshotterConfiguration is not a real Kubernetes/OpenShift API object — it is a fabricated name that sounds plausible but does not exist in the snapshot.storage.k8s.io API group. Option B is wrong because StorageClass defines how PersistentVolumes are dynamically provisioned (provisioner, reclaim policy, parameters), not how snapshots are taken. Option C is wrong because VolumeSnapshotContent represents the actual snapshot on the storage backend (the cluster-scoped counterpart to a VolumeSnapshot), not the class that parameterizes snapshot creation.

Practice this question →
53
MCQeasy

Which command allows an administrator to view details, including events and current binding status, of a specific PersistentVolume named 'pv-data01'?

A.oc status pv-data01
B.oc get pv pv-data01 -o yaml
C.oc describe pv pv-data01
D.oc logs pv/pv-data01
AnswerC

oc describe pv pv-data01 queries the cluster for that PersistentVolume and renders its specification, status, events and current binding to a PersistentVolumeClaim. The describe subcommand exposes exactly the events and binding status the question requires.

Why this answer

The 'oc describe pv pv-data01' command retrieves detailed information about the PersistentVolume, including its status, capacity, access modes, reclaim policy, and associated events, which is exactly what the administrator needs. The describe subcommand aggregates the object's spec, status, and recent events into a human-readable format.

Exam trap

EX280 often tests the difference between 'get -o yaml' and 'describe', where candidates incorrectly assume YAML output includes events and binding status summaries.

How to eliminate wrong answers

Option A is wrong because 'oc status' provides a high-level overview of the current project and does not accept a PV name as an argument. Option B is wrong because 'oc get pv pv-data01 -o yaml' outputs the raw YAML manifest, which does not include events or a summarized binding status. Option D is wrong because 'oc logs' retrieves container logs from pods and does not work on PersistentVolume resources.

Practice this question →
54
Multi-Selectmedium

Which TWO volume types are considered ephemeral storage patterns native to Kubernetes and OpenShift?

Select 2 answers
A.Generic ephemeral inline volumes
B.NFS network shares
C.PersistentVolumeClaim
D.emptyDir
E.AWS EBS volumes
AnswersA, D

Generic ephemeral inline volumes embed a volume template directly in the pod spec, letting the pod own the lifecycle of dynamically provisioned storage. Kubernetes and OpenShift treat this as a native ephemeral pattern, distinct from persistent PVC-backed volumes.

Why this answer

Generic ephemeral inline volumes (A) are a native Kubernetes ephemeral storage pattern: they are declared inline in the pod spec via the ephemeral.volumeClaimTemplate field, and the lifecycle of the generated PVC is tied to the pod, so the storage is created and deleted with the pod. emptyDir (D) is the classic native ephemeral volume type, created when a pod is assigned to a node and deleted permanently when the pod is removed, which is exactly the definition of ephemeral storage in Kubernetes/OpenShift. NFS network shares (B) are persistent external storage, not an ephemeral pattern, and they survive pod deletion. PersistentVolumeClaim (C) represents durable, independently managed storage whose lifecycle is decoupled from the pod, so it is not ephemeral.

AWS EBS volumes (E) are persistent block storage (via the aws-ebs CSI driver) that outlives the pod and is not a native ephemeral pattern.

Exam trap

EX280 often tests ephemeral vs persistent storage classification — candidates mistakenly include PVC or network storage as ephemeral because they can be mounted by pods.

Practice this question →
55
Multi-Selectmedium

An administrator is configuring a PersistentVolume to be used by multiple pods across different nodes. The storage backend supports ReadWriteMany. Which two steps are required to ensure the volume is mounted correctly in all pods? (Choose two.)

Select 2 answers
A.Set the Pod's volumeMounts readOnly field to false.
B.Set the PersistentVolume's accessModes to ReadWriteMany.
C.Set the StorageClass's volumeBindingMode to WaitForFirstConsumer.
D.Set the PersistentVolume's reclaimPolicy to Retain.
E.Set the PersistentVolumeClaim's accessModes to ReadWriteMany.
AnswersB, E

The PersistentVolume's accessModes must include ReadWriteMany to indicate that the underlying storage supports simultaneous read-write access from multiple nodes. This is a prerequisite for the volume to be bound to a PVC requesting ReadWriteMany. Without this, the volume cannot satisfy the claim's access mode, and binding will fail.

Why this answer

To use a PersistentVolume with ReadWriteMany across multiple nodes, both the PersistentVolume and the PersistentVolumeClaim must specify ReadWriteMany in their accessModes. The PV indicates the storage's capability, and the PVC requests that capability. The pod's readOnly flag and reclaim policy do not affect the access mode compatibility.

Exam trap

The trap here is thinking that pod-level readOnly or reclaim policy settings are needed for ReadWriteMany, when the access modes on the PV and PVC are the determining factors.

Practice this question →
56
MCQeasy

Which command is used to delete a PersistentVolumeClaim named 'my-app-pvc' in the current project?

A.oc remove pvc my-app-pvc
B.oc delete pvc my-app-pvc
C.oc destroy pvc my-app-pvc
D.oc prune pvc my-app-pvc
AnswerB

`oc delete pvc my-app-pvc` targets the resource type by its short name, PersistentVolumeClaim, and the object name within the active project namespace, satisfying the stem's "current project" constraint. OpenShift resolves `pvc` as the standard abbreviation, so no `-n` flag is needed.

Why this answer

'oc delete pvc my-app-pvc' is the correct syntax to remove a PersistentVolumeClaim in the current project. The 'oc delete' verb works uniformly across resource types, and 'pvc' is the accepted short name for PersistentVolumeClaim. The current namespace is used unless -n is specified.

Exam trap

EX280 often tests whether candidates invent plausible-sounding verbs like 'remove', 'destroy', or 'prune' instead of the universal 'oc delete' that applies to every resource type.

How to eliminate wrong answers

Option A is wrong because 'oc remove' is not a valid OpenShift subcommand — the verb is 'delete'. Option C is wrong because 'oc destroy' does not exist in the oc CLI. Option D is wrong because 'oc prune' is used for cleaning up unused images, builds, and deployments, not for deleting arbitrary resources like PVCs.

Practice this question →
57
MCQhard

An OpenShift cluster uses a CSI driver that supports volume cloning. A user wants to clone an existing PVC named 'data-pvc' into a new PVC named 'clone-pvc'. How should the dataSource be specified?

A.dataSource: { apiGroup: "snapshot.storage.k8s.io", kind: "VolumeSnapshot", name: "data-pvc" }
B.spec.cloneSource: "data-pvc"
C.dataSource: { apiGroup: "", kind: "PersistentVolumeClaim", name: "data-pvc" }
D.spec.volumeName: "data-pvc"
AnswerC

For a same-namespace PVC clone, the dataSource uses an empty apiGroup with kind PersistentVolumeClaim and the source name, since core v1 resources belong to no API group. This satisfies the cloning requirement by referencing data-pvc correctly.

Why this answer

To clone an existing PVC named 'data-pvc' into a new PVC named 'clone-pvc' using a CSI driver that supports volume cloning, the dataSource field must specify the source PVC. The correct specification is dataSource: { apiGroup: "", kind: "PersistentVolumeClaim", name: "data-pvc" }. The apiGroup is empty because PersistentVolumeClaim is a core Kubernetes resource.

This tells the CSI driver to clone the volume from the specified PVC.

Exam trap

EX280 often tests the confusion between volume cloning and snapshot restoration, leading candidates to incorrectly specify a VolumeSnapshot as the data source.

How to eliminate wrong answers

Option A is wrong because it specifies a VolumeSnapshot as the data source, which is used for restoring from a snapshot, not for cloning a PVC directly. Option B is wrong because 'spec.cloneSource' is not a valid field in a PVC specification; the correct field is 'dataSource'. Option D is wrong because 'spec.volumeName' is used to bind a PVC to a specific pre-existing PV, not for cloning.

Practice this question →
58
MCQeasy

A cluster administrator is preparing a PersistentVolume for a database that must survive node failures and be reattached to a rescheduled pod. The storage backend is a CSI driver that supports topology-aware provisioning. Which access mode should the administrator specify in the PersistentVolumeClaim to allow the volume to be mounted as read-write by a single node at a time?

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

ReadWriteOnce allows the volume to be mounted as read-write by a single node. The CSI driver enforces node-level attachment, so when the pod is rescheduled to another node the volume is detached and reattached there. This matches a database workload that must not be written concurrently from multiple nodes while still tolerating node failure.

Why this answer

ReadWriteOnce grants read-write access to a single node, letting the CSI driver detach and reattach the volume when the pod moves to a healthy node. This balances write exclusivity with failure recovery, unlike ReadOnlyMany, ReadWriteMany, or the pod-scoped ReadWriteOncePod, which either forbid writes or over-constrain attachment.

Exam trap

The trap here is confusing node-level exclusivity with pod-level exclusivity, where ReadWriteOncePod sounds similar but restricts to one pod rather than one node.

Practice this question →
59
MCQmedium

A cluster administrator has deleted a PersistentVolumeClaim, but the underlying PersistentVolume still exists in the cluster with a Released status and its data remains intact on the storage backend. What is the most likely cause of this behavior?

A.The StorageClass associated with the PV has allowVolumeExpansion set to false.
B.The volume access mode was configured as ReadWriteMany instead of ReadWriteOnce.
C.The persistentVolumeReclaimPolicy of the PersistentVolume was set to Retain.
D.The PVC was protected by a finalizer that prevented immediate deletion.
AnswerC

Retain reclaim policy deliberately preserves the PersistentVolume and its backend data after the bound claim is deleted, transitioning the volume to Released rather than deleting it. This exactly matches the stem's constraint: the PVC is gone yet the PV survives with data intact, which Delete or Recycle would not produce.

Why this answer

When a PVC is deleted, the PersistentVolume's reclaim policy determines what happens to the underlying storage. If the PV's persistentVolumeReclaimPolicy is set to Retain, the PV transitions to Released status and the data on the backend is preserved; the PV must be manually reclaimed or deleted by an administrator. This exactly matches the described behavior.

Exam trap

EX280 often tests whether candidates confuse PVC finalizers (which delay deletion while in use) with PV reclaim policies (which govern post-deletion data retention) — the Released status with intact data is the signature of Retain.

How to eliminate wrong answers

Option A is wrong because allowVolumeExpansion controls whether a PVC can be resized, not what happens to a PV after PVC deletion; it has no effect on reclaim behavior. Option B is wrong because access modes (ReadWriteOnce, ReadWriteMany, ReadOnlyMany) govern how many nodes can mount a volume concurrently, not the post-deletion lifecycle of the PV. Option D is wrong because while PVCs can have finalizers (kubernetes.io/pvc-protection) that delay deletion while a pod is using them, once the PVC is actually deleted, the PV's fate is governed by reclaimPolicy, not by a finalizer.

Practice this question →
60
MCQmedium

A user creates a PVC, but the storage backend fails to provision the volume. Where can the administrator look to find detailed error messages emitted by the external provisioner controller?

A.Run 'oc adm diagnostics storage'.
B.Inspect the container image registry logs.
C.Review the logs of the CSI external provisioner controller pod in its management namespace.
D.Check /var/log/messages on the control plane nodes.
AnswerC

The external provisioner controller performs dynamic provisioning, so its pod logs record the storage backend's API errors and failure reasons. Checking that pod's logs in its management namespace reveals why the PVC's volume could not be created.

Why this answer

When a PVC fails to provision, the external provisioner sidecar (e.g., csi-provisioner) running alongside the CSI driver controller is the component that actually calls the storage backend's CreateVolume API and logs the resulting errors. In OpenShift, CSI controller pods run in the driver's management namespace (typically openshift-cluster-csi-drivers or the operator's namespace), so reviewing that pod's logs reveals the detailed backend error messages.

Exam trap

EX280 often tests the misconception that generic node logs or diagnostics commands contain CSI provisioner errors, when the detailed backend error is only in the external-provisioner sidecar container logs.

How to eliminate wrong answers

Option A is wrong because 'oc adm diagnostics storage' runs general cluster storage health checks and does not surface the external provisioner's per-request error output. Option B is wrong because the container image registry is unrelated to CSI volume provisioning; its logs contain image push/pull events, not storage backend errors. Option D is wrong because /var/log/messages on control plane nodes contains kubelet and system daemon logs, not the CSI provisioner sidecar's application logs, which are captured by the container runtime and accessible via oc logs.

Practice this question →
61
MCQeasy

Which OpenShift CLI command is used to display all PersistentVolumeClaims in the current project along with their bound PersistentVolumes and storage classes?

A.oc get pvc
B.oc get pv
C.oc get sc
D.oc describe volume
AnswerA

Running oc get pvc lists every PersistentVolumeClaim in the current project, and its default output columns include the bound volume name and storage class, satisfying the requirement to show claims alongside their PersistentVolumes and storage classes without extra flags.

Why this answer

'oc get pvc' lists all PersistentVolumeClaims in the current project, and its default output includes the STATUS, VOLUME (the bound PV name), CAPACITY, ACCESS MODES, and STORAGECLASS columns. This single command gives the administrator the PVC-to-PV-to-StorageClass mapping requested.

Exam trap

The trap here is confusing the resource scopes: candidates may pick 'oc get pv' because PVs are the backing objects, but the question specifically asks for PVCs in the current project — 'oc get pvc' is the namespaced command that shows the PVC, its bound PV, and its StorageClass in one view.

How to eliminate wrong answers

Option B is wrong because 'oc get pv' lists PersistentVolumes (cluster-scoped) and shows which PVC claims them, but it does not enumerate PVCs by project and is not the direct answer to 'display all PVCs in the current project'. Option C is wrong because 'oc get sc' lists StorageClasses only — it shows provisioner and reclaim policy but no PVC or PV binding information. Option D is wrong because 'oc describe volume' is not a valid oc subcommand; volume inspection is done via 'oc describe pvc <name>' or 'oc get pvc'.

Practice this question →
62
Multi-Selecthard

A cluster operator is reviewing the volume snapshot implementation in an OpenShift 4.14 environment. Which THREE components or resources are required to successfully perform and manage volume snapshots? (Choose THREE)

Select 3 answers
A.A CSI driver that implements snapshot/restore GRPC services
B.VolumeSnapshotClass
C.A default ClusterRoleBinding for system:authenticated users
D.VolumeSnapshot object
E.NetworkPolicy resources restricting snapshot traffic
AnswersA, B, D

The CSI driver must implement the snapshot and restore gRPC services, since the external-snapshotter controller delegates all CreateSnapshot, DeleteSnapshot and restore operations to these CSI RPCs. Without them, no VolumeSnapshotContent can be provisioned or restored.

Why this answer

Option A is correct because volume snapshots in OpenShift depend on a CSI driver that implements the snapshot/restore gRPC services (the external-snapshotter sidecar and CSI snapshotter capability), which actually creates and restores the snapshots on the storage backend. Option B is correct because a VolumeSnapshotClass defines the CSI driver and deletion policy used when provisioning a VolumeSnapshot, and it must exist for the snapshot to be dynamically created. Option D is correct because the VolumeSnapshot object is the user-facing resource that requests the snapshot and tracks its status and restore point.

Option C is not required, since snapshot operations are governed by RBAC on the snapshot resources rather than a default ClusterRoleBinding for system:authenticated users. Option E is not required, as NetworkPolicy controls pod network traffic and is unrelated to provisioning or managing volume snapshots.

Exam trap

EX280 often tests the specific CRDs and driver capabilities required for snapshots — candidates add unrelated resources like NetworkPolicy or ClusterRoleBindings that are not part of the snapshot architecture.

Practice this question →
63
MCQmedium

A stateful application needs its PersistentVolume to be bound only after the pod requesting it is assigned to a specific worker node, to avoid topology mismatch issues. Which StorageClass parameter achieves this?

A.allowVolumeExpansion: true
B.volumeBindingMode: Immediate
C.bindingMode: Late
D.volumeBindingMode: WaitForFirstConsumer
AnswerD

volumeBindingMode: WaitForFirstConsumer delays PersistentVolume binding until a pod using the claim is scheduled, letting the provisioner create storage in the node's topology zone. This satisfies the requirement that binding occur only after node assignment, avoiding cross-zone mismatch.

Why this answer

The volumeBindingMode: WaitForFirstConsumer parameter in a StorageClass delays volume binding until a pod using the PVC is scheduled. This ensures that the PersistentVolume is provisioned in the same topology zone as the node where the pod runs, preventing topology mismatch. It is the correct setting for stateful applications that require node-local or zone-specific storage.

Exam trap

EX280 often tests whether candidates know the exact StorageClass parameter name and values, so the trap is selecting 'bindingMode: Late' (a non-existent field) or 'Immediate' (which causes the topology problem) instead of the correct 'volumeBindingMode: WaitForFirstConsumer'.

How to eliminate wrong answers

Option A (allowVolumeExpansion: true) is wrong because this parameter only enables resizing of PVCs after creation; it has no effect on when or where volumes are bound. Option B (volumeBindingMode: Immediate) is wrong because Immediate binding provisions and binds the volume as soon as the PVC is created, without waiting for a pod, which can lead to topology mismatch if the volume is provisioned in a different zone than the pod. Option C (bindingMode: Late) is wrong because 'bindingMode' is not a valid StorageClass parameter; the correct field is 'volumeBindingMode' with values 'Immediate' or 'WaitForFirstConsumer'.

Practice this question →
64
MCQmedium

An administrator needs to set a default StorageClass for the entire OpenShift cluster so that PVCs without a storageClassName specified automatically use it. How is this configured?

A.By modifying the kube-controller-manager operator configuration.
B.By adding the annotation storageclass.kubernetes.io/is-default-class: "true" to the StorageClass object.
C.By naming the StorageClass 'default-sc' exactly.
D.By setting defaultStorageClass: true in the cluster-config ConfigMap.
AnswerB

Annotating the StorageClass with `storageclass.kubernetes.io/is-default-class: "true"` satisfies the cluster-wide default requirement: the admission controller then assigns this class to any PVC omitting `storageClassName`. This is the sole supported mechanism for designating a default StorageClass, applying cluster-wide rather than per-namespace.

Why this answer

In Kubernetes and OpenShift, a StorageClass is marked as the cluster default by adding the annotation storageclass.kubernetes.io/is-default-class: "true" to its metadata. The PersistentVolumeClaim admission controller then automatically assigns that class to any PVC that omits storageClassName.

Exam trap

EX280 often tests the annotation-based defaulting mechanism — candidates incorrectly assume a StorageClass named 'default' or a ConfigMap setting controls defaulting.

How to eliminate wrong answers

Option A is wrong because the kube-controller-manager operator configuration controls controller behavior, not StorageClass defaulting; there is no field there for default storage class selection. Option C is wrong because the name 'default-sc' has no special meaning — Kubernetes does not infer default status from a StorageClass name. Option D is wrong because there is no cluster-config ConfigMap field called defaultStorageClass; defaulting is annotation-driven, not ConfigMap-driven.

Practice this question →
65
MCQmedium

A cluster administrator notices that a PVC stuck in the Pending state references a StorageClass with volumeBindingMode set to WaitForFirstConsumer. What action will cause the PVC to bind?

A.Delete the StorageClass and recreate it with Immediate binding mode.
B.Restart the kube-apiserver service on the control plane nodes.
C.Create and schedule a Pod that mounts the PVC.
D.Manually create a PV matching the exact size and labels of the PVC.
AnswerC

With WaitForFirstConsumer, the volume binding decision is deferred until a Pod using the PVC is scheduled, letting the scheduler pick a node and then provision storage in that node's topology zone. Creating and scheduling a Pod that mounts the PVC triggers this provisioning, satisfying the delayed-binding constraint and moving the PVC from Pending to Bound.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the storage provisioner delays binding until a pod using the PVC is scheduled, allowing the scheduler to pick a node and then provision storage in the correct topology zone. Creating and scheduling a pod that mounts the PVC triggers the provisioning and binding process. Until such a pod exists, the PVC remains Pending by design.

Exam trap

EX280 often tests whether candidates recognize that a Pending PVC with WaitForFirstConsumer is normal behavior, not a failure — the trap is assuming Pending always means a problem requiring intervention.

How to eliminate wrong answers

Option A is wrong because changing to Immediate binding mode alters cluster storage behavior and is unnecessary — WaitForFirstConsumer is intentional for topology-aware provisioning, and the PVC will bind once a consumer pod is created. Option B is wrong because restarting the kube-apiserver has no effect on volume binding, which is handled by the scheduler and the CSI provisioner, not the API server. Option D is wrong because manually creating a PV bypasses the dynamic provisioner and is not the intended mechanism; WaitForFirstConsumer expects the provisioner to create the PV after scheduling, and a manually created PV may not match topology constraints.

Practice this question →
66
MCQeasy

You need to provide temporary scratch space for a container that shares the pod's lifetime and is cleared when the pod is deleted. Which volume type should you configure in the Pod specification?

A.persistentVolumeClaim
B.hostPath
C.nfs
D.emptyDir
AnswerD

emptyDir creates a directory tied to the pod's lifecycle, shared by its containers and deleted permanently when the pod is removed. hostPath and persistent volumes outlive the pod, so they fail the stem's scratch-space and lifetime constraints.

Why this answer

An emptyDir volume is created when a pod is assigned to a node and exists for the lifetime of that pod. It is initially empty, provides scratch space for the container, and is deleted permanently when the pod is removed from the node. This exactly matches the requirement for temporary, pod-lifetime scratch space.

Exam trap

EX280 often tests the distinction between emptyDir (pod-lifetime, ephemeral) and hostPath (node-lifetime, persistent) — candidates pick hostPath thinking it provides temporary storage, but it actually persists and exposes host data.

How to eliminate wrong answers

Option A is wrong because persistentVolumeClaim provides durable storage that outlives the pod and is not cleared on pod deletion. Option B is wrong because hostPath mounts a directory from the host node, which persists beyond the pod and can expose host filesystem data, violating the temporary requirement. Option C is wrong because nfs mounts a remote network filesystem that persists independently of the pod and is not cleared on deletion.

Practice this question →
67
MCQhard

An administrator expands a PVC from 10Gi to 50Gi. The underlying cloud storage volume is successfully resized, but inside the running pod, 'df -h' still reports the size as 10Gi. What is the most likely reason?

A.The pod must be restarted to flush the Linux page cache.
B.The file system on the volume has not been expanded to occupy the new block storage capacity.
C.The StorageClass lacks the allowVolumeExpansion parameter.
D.PVC expansion is strictly read-only after creation and cannot be updated at the filesystem level.
AnswerB

Resizing the cloud volume expands the underlying block device, but the filesystem must then be grown separately to occupy that capacity. Until the filesystem is expanded, df -h inside the pod continues reporting the original 10Gi size.

Why this answer

When a PVC is expanded, the CSI driver resizes the underlying block volume, but the filesystem inside the volume must also be expanded to use the new space. For filesystems like ext4 or XFS, this requires a resize operation (resize2fs or xfs_growfs), which is typically triggered by the kubelet when the pod is restarted or when the CSI driver supports online expansion. If the filesystem resize hasn't occurred, 'df -h' inside the pod still reports the old size.

Exam trap

EX280 often tests the two-stage nature of volume expansion — candidates assume that resizing the cloud volume automatically resizes the filesystem, but the filesystem resize is a separate step that may require a pod restart or may be handled online depending on the CSI driver.

How to eliminate wrong answers

Option A is wrong because the Linux page cache does not control filesystem size reporting — restarting the pod alone won't change 'df -h' output unless the filesystem resize is triggered as part of the volume remount. Option C is wrong because if the StorageClass lacked 'allowVolumeExpansion: true', the PVC expansion would have been rejected by the API server, and the underlying cloud volume would not have been resized — but the question states the cloud volume was successfully resized. Option D is wrong because PVC expansion is supported (when allowVolumeExpansion is true) and is not read-only; the filesystem can be grown, though shrinking is not supported.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Storage And Persistent Volumes questions.

Start 20-question session
CCNA Storage And Persistent Volumes Questions | Courseiva