KCNA - Container Orchestration (28% of the exam) - Section 2.3
Describe how Kubernetes provides persistent storage to workloads.
Volumes versus PersistentVolumes, PersistentVolumeClaims, StorageClasses and dynamic provisioning, access modes, reclaim policies, and the Container Storage Interface. Also why StatefulSets pair with per-replica claims.
A storage vendor wants their proprietary networked storage system to work with Kubernetes so that clusters can provision, attach, and mount volumes from it, without the vendor needing their code merged into the Kubernetes source tree or tied to Kubernetes release cycles. Which standardised mechanism is designed to let such third-party storage integrate with Kubernetes in this decoupled way?
AA Container Storage Interface driver deployed to the clustercheck_circle Correct
BA ConfigMap that describes the vendor's storage endpoints
CAn in-tree volume plugin compiled into Kubernetes itself
DA DaemonSet that mounts the vendor's storage on each node
Identify the Container Storage Interface as the standard that lets third-party storage integrate with Kubernetes without in-tree code. The Container Storage Interface is a standard API that decouples storage drivers from the Kubernetes release cycle, so vendors provide a CSI driver rather than merging code into the Kubernetes source tree.
Why A is correct: The Container Storage Interface defines a standard API so a vendor ships a CSI driver deployed to the cluster, letting Kubernetes provision, attach, and mount their storage without upstream code changes or release coupling.
Why B is wrong: A ConfigMap can hold configuration values a driver reads, which makes it seem relevant, but it cannot provision or attach volumes and provides no integration interface for a storage system.
Why C is wrong: In-tree plugins did once integrate storage, so this is a believable answer, but they require the vendor's code inside the Kubernetes tree and tie it to release cycles, which is exactly what the vendor wants to avoid.
Why D is wrong: A DaemonSet is often part of how a driver runs a component per node, which makes it tempting, but on its own it is just a workload controller and defines no standard storage integration contract.
Answers that look right on this material and are not. Each one is a distractor from a different question in the KCNA bank for this domain.
The Container Network Interface, which standardises how networking plugins provide connectivity to Pods.
errorWhy it is wrong: This is a genuine Kubernetes interface and easy to confuse by its similar naming, but it governs Pod networking, not storage provisioning and attachment.
A statically defined PersistentVolume for each tier, created in advance by the administrator before any claim is made.
errorWhy it is wrong: Pre-creating volumes is a real pattern, so this is plausible, but it is static provisioning and requires manual administrator effort, which is the opposite of the on-demand automation asked for.
The kubelet volume cache, which stores recently used volume handles in memory to speed up remounts.
errorWhy it is wrong: This names real components in plausible-sounding language, but there is no such standard integration surface for third-party storage; caching remounts would not let a vendor ship an independent driver.