Back to Certified Kubernetes Administrator (CKA)

Storage

Implement storage classes, volume types, and persistent volume management in Kubernetes (10% of exam).

This domain covers implementing storage classes and dynamic volume provisioning, configuring volume types, access modes and reclaim policies, and managing persistent volumes and persistent volume claims. Understanding storage in Kubernetes is essential for stateful applications.
5 minutes 5 Questions

In the context of the Certified Kubernetes Administrator (CKA) exam, storage is a critical domain focusing on decoupling data persistence from the ephemeral lifecycle of containers. By default, data inside a container is lost if the container crashes or the Pod is deleted. Kubernetes resolves this …

Concepts covered: Implement storage classes and dynamic volume provisioning, Configure volume types, access modes and reclaim policies, Manage persistent volumes and persistent volume claims, StorageClass parameters and provisioners, Volume expansion and resizing, Volume snapshots and cloning, CSI drivers and storage backends, EmptyDir, HostPath and local volumes

Test mode:
Start practice test
CKA - Storage Example Questions

Test your knowledge of Storage

Question 1

What is the primary purpose of the Container Storage Interface (CSI) in Kubernetes?

Correct Answer: To provide a standardized way for storage vendors to expose their storage systems to container orchestrators

The Container Storage Interface (CSI) is a standardized specification that allows storage vendors to develop plugins that expose their storage systems to container orchestrators like Kubernetes. This is the correct answer because CSI was specifically designed to create a universal interface between Kubernetes and various storage providers.

Before CSI, storage drivers had to be built into the Kubernetes core codebase (in-tree drivers), which made it difficult for storage vendors to add support for their systems and required waiting for Kubernetes releases. CSI solves this by providing a standard API that any storage vendor can implement through out-of-tree plugins, making storage integration modular and vendor-independent.

The other options are incorrect for the following reasons:

  • Managing network policies and firewall rules is not related to CSI at all. Network policies in Kubernetes are handled by NetworkPolicy resources and network plugins (CNI), not CSI. CSI deals exclusively with storage operations.

  • While monitoring storage metrics is important, CSI is not designed for this purpose. Monitoring and metrics collection in Kubernetes are typically handled by tools like Prometheus, and while CSI drivers may expose some metrics, the primary purpose of CSI is storage provisioning and management, not monitoring.

  • Backup and disaster recovery operations are not the core function of CSI. While some CSI drivers may include snapshot capabilities that can assist with backups, the primary purpose of CSI is to provide a standardized storage interface, not to handle backup and recovery workflows.

Question 2

When creating a StorageClass in Kubernetes, what is the purpose of the 'reclaimPolicy' field?

Correct Answer: It determines what happens to the underlying storage when the PersistentVolume is released

The 'reclaimPolicy' field in a StorageClass determines what happens to the underlying storage when the PersistentVolume (PV) is released from its PersistentVolumeClaim (PVC).

The reclaimPolicy can be set to one of the following values:
- Retain: The PersistentVolume remains after the PVC is deleted, and the data is preserved. An administrator must manually reclaim the volume.
- Delete: Both the PersistentVolume object and the underlying storage asset (such as an AWS EBS volume, GCE PD, or Azure Disk) are deleted when the PVC is deleted.
- Recycle (deprecated): The volume is scrubbed (basic rm -rf) and made available for a new claim.

This is a fundamental concept for managing storage lifecycle in Kubernetes clusters.

The other options are incorrect because:

  • The option about checking for available disk space on nodes is not related to reclaimPolicy. Storage provisioners do not use reclaimPolicy for health checks or capacity monitoring.

  • The option about retention period for snapshots is incorrect. Snapshot retention is handled through VolumeSnapshot and VolumeSnapshotClass resources, not the reclaimPolicy field in StorageClass.

  • The option about scheduling behavior for multiple pod storage requests is incorrect. Pod scheduling and storage request handling are managed by the scheduler and storage provisioner logic, not by the reclaimPolicy field.

Question 3

A Kubernetes administrator wants to restore data from a VolumeSnapshot to a new PVC. The VolumeSnapshot named 'backup-snap' is in the 'production' namespace and shows 'readyToUse: true'. When writing the PVC manifest, which dataSource configuration correctly references the VolumeSnapshot for restoration?

Correct Answer: spec.dataSource with kind: VolumeSnapshot, name: backup-snap, and apiGroup: snapshot.storage.k8s.io

The correct answer specifies spec.dataSource with kind: VolumeSnapshot, name: backup-snap, and apiGroup: snapshot.storage.k8s.io.

When restoring data from a VolumeSnapshot to a new PVC in Kubernetes, you need to configure the dataSource field in the PVC specification. The correct configuration requires:

  1. kind: VolumeSnapshot - This specifies that you're restoring from a VolumeSnapshot object (not VolumeSnapshotContent)
  2. name: backup-snap - This references the name of your snapshot
  3. apiGroup: snapshot.storage.k8s.io - This is the correct API group for VolumeSnapshot resources

The other options are incorrect for the following reasons:

  • Using VolumeSnapshotContent as the kind is wrong because VolumeSnapshotContent is the cluster-scoped resource that represents the actual snapshot in the storage backend. When restoring to a PVC, you reference the namespace-scoped VolumeSnapshot object, not the VolumeSnapshotContent.

  • Using spec.dataSourceRef with apiGroup: storage.k8s.io is incorrect because the proper apiGroup for VolumeSnapshots is snapshot.storage.k8s.io, not storage.k8s.io. While dataSourceRef can be used, the apiGroup must still be correct.

  • Including a namespace field in the dataSource reference is incorrect because the dataSource reference is namespace-scoped by default and must reference a VolumeSnapshot in the same namespace as the PVC. You cannot specify a different namespace in the dataSource reference - the snapshot and the new PVC must be in the same namespace.

More Storage questions
244 questions (total)
Start 100 question test