Bird
Raised Fist0
Kubernetesdevops~5 mins

PersistentVolumeClaim (PVC) definition in Kubernetes - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is a PersistentVolumeClaim (PVC) in Kubernetes?
A PersistentVolumeClaim (PVC) is a request for storage by a user. It allows pods to claim storage resources without knowing the details of the underlying storage.
Click to reveal answer
beginner
Which key fields are required in a basic PVC YAML definition?
apiVersion, kind, metadata (name), and spec (accessModes, resources.requests.storage).
Click to reveal answer
intermediate
What does the accessModes field in a PVC specify?
It specifies how the volume can be mounted. Common values are ReadWriteOnce, ReadOnlyMany, and ReadWriteMany.
Click to reveal answer
intermediate
How does a PVC relate to a PersistentVolume (PV)?
A PVC requests storage, and Kubernetes binds it to a matching PersistentVolume (PV) that provides the actual storage.
Click to reveal answer
intermediate
What happens if no matching PersistentVolume is available for a PVC?
The PVC stays in a pending state until a suitable PersistentVolume is available or dynamically provisioned.
Click to reveal answer
Which field in a PVC YAML defines the amount of storage requested?
Aspec.resources.requests.storage
Bmetadata.name
Cspec.accessModes
DapiVersion
What does the access mode ReadWriteOnce mean in a PVC?
AThe volume can be mounted as read-only by many nodes
BThe volume can be mounted as read-write by a single node
CThe volume can be mounted as read-write by many nodes
DThe volume is read-only and cannot be mounted
If a PVC is created but no matching PV exists, what is the PVC status?
AAvailable
BBound
CPending
DReleased
Which Kubernetes object does a PVC bind to?
APod
BConfigMap
CNamespace
DPersistentVolume (PV)
What is the kind value in a PVC YAML file?
APersistentVolumeClaim
BPersistentVolume
CStorageClass
DPod
Explain the purpose of a PersistentVolumeClaim in Kubernetes and how it interacts with PersistentVolumes.
Think of PVC as a storage order and PV as the storage supply.
You got /4 concepts.
    Describe the key fields in a PersistentVolumeClaim YAML and their roles.
    Focus on the YAML structure and what each part means.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main purpose of a PersistentVolumeClaim (PVC) in Kubernetes?
      easy
      A. To configure network policies
      B. To define a container image for a pod
      C. To schedule pods on specific nodes
      D. To request storage resources from the cluster

      Solution

      1. Step 1: Understand PVC role

        A PVC is used to request storage resources in Kubernetes, separating storage use from storage details.
      2. Step 2: Compare options

        Options A, B, and D relate to other Kubernetes features, not storage requests.
      3. Final Answer:

        To request storage resources from the cluster -> Option D
      4. Quick Check:

        PVC = Storage request [OK]
      Hint: PVC always requests storage, not images or network [OK]
      Common Mistakes:
      • Confusing PVC with Pod or Deployment definitions
      • Thinking PVC schedules pods
      • Mixing PVC with network policies
      2. Which of the following is the correct minimal YAML snippet to define a PVC requesting 5Gi of storage with ReadWriteOnce access mode?
      easy
      A. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadOnlyMany resources: requests: storage: 5Gi
      B. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi
      C. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteMany resources: limits: storage: 5Gi
      D. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: cpu: 5Gi

      Solution

      1. Step 1: Check accessModes and storage request

        apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi correctly uses ReadWriteOnce and requests 5Gi storage under resources.requests.
      2. Step 2: Identify errors in other options

        apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadOnlyMany resources: requests: storage: 5Gi uses ReadOnlyMany (not requested). apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteMany resources: limits: storage: 5Gi uses limits instead of requests. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: cpu: 5Gi incorrectly requests cpu instead of storage.
      3. Final Answer:

        Correct minimal PVC YAML with 5Gi and ReadWriteOnce -> Option B
      4. Quick Check:

        accessModes + storage request = apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi [OK]
      Hint: Use resources.requests.storage for size, accessModes for access [OK]
      Common Mistakes:
      • Using limits instead of requests for storage
      • Wrong accessModes value
      • Requesting cpu instead of storage
      3. Given this PVC YAML snippet, what will be the requested storage size and access mode?
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: data-pvc
      spec:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: 10Gi
        storageClassName: fast-storage
      medium
      A. 10Gi storage with ReadWriteMany access
      B. 10Gi storage with ReadWriteOnce access
      C. 5Gi storage with ReadWriteMany access
      D. 10Gi storage with ReadOnlyMany access

      Solution

      1. Step 1: Read storage size

        The YAML requests 10Gi storage under resources.requests.storage.
      2. Step 2: Read access mode

        Access mode is ReadWriteMany as specified under accessModes.
      3. Final Answer:

        10Gi storage with ReadWriteMany access -> Option A
      4. Quick Check:

        storage=10Gi, access=ReadWriteMany [OK]
      Hint: Check resources.requests.storage and accessModes list [OK]
      Common Mistakes:
      • Confusing ReadWriteOnce with ReadWriteMany
      • Misreading storage size
      • Ignoring storageClassName as it doesn't affect size or access
      4. Identify the error in this PVC YAML snippet:
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: test-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 2GB
      medium
      A. metadata name is missing
      B. accessModes should be ReadOnlyMany
      C. storage size unit should be Gi, not GB
      D. apiVersion should be apps/v1

      Solution

      1. Step 1: Check storage size unit

        Kubernetes expects storage size units like Gi, Mi, not GB. '2GB' is invalid.
      2. Step 2: Verify other fields

        accessModes and metadata name are correct. apiVersion for PVC is v1, not apps/v1.
      3. Final Answer:

        storage size unit should be Gi, not GB -> Option C
      4. Quick Check:

        Use Gi for storage size units [OK]
      Hint: Use Gi, Mi units for storage size, not GB [OK]
      Common Mistakes:
      • Using GB instead of Gi for storage size
      • Wrong apiVersion for PVC
      • Changing accessModes unnecessarily
      5. You want to create a PVC that requests 20Gi storage with ReadWriteOnce access and uses a storage class named "premium-ssd". Which YAML snippet correctly defines this PVC?
      hard
      A. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd
      B. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteMany resources: requests: storage: 20Gi storageClassName: premium-ssd
      C. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: limits: storage: 20Gi storageClassName: premium-ssd
      D. apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20GB storageClassName: premium-ssd

      Solution

      1. Step 1: Verify accessModes and storage size

        apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd uses ReadWriteOnce and requests 20Gi storage correctly.
      2. Step 2: Check storageClassName and units

        apiVersion: v1 kind: PersistentVolumeClaim metadata: name: premium-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: premium-ssd correctly sets storageClassName to premium-ssd and uses Gi units. Other options have wrong accessModes, use limits instead of requests, or wrong units (GB).
      3. Final Answer:

        Correct PVC with 20Gi, ReadWriteOnce, and premium-ssd storage class -> Option A
      4. Quick Check:

        accessModes=ReadWriteOnce + requests.storage=20Gi + storageClassName= premium-ssd [OK]
      Hint: Use requests.storage with Gi units and correct accessModes [OK]
      Common Mistakes:
      • Using limits instead of requests for storage
      • Wrong accessModes value
      • Using GB instead of Gi for storage size
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard