A developer on a CKAD-scoped team needs durable storage for an app and starts drafting a PersistentVolume and StorageClass. What responsibility boundary should they follow?
Select an answer to reveal the explanation.
Short Explanation
Think apartment lease versus owning the building—developers ask for a PVC (the lease), admins provision PVs and StorageClasses (the building). Don’t spend app time authoring cluster storage plumbing.
Full Explanation
A developer on a CKAD-scoped team who needs durable storage should create and consume a PersistentVolumeClaim and leave PersistentVolume and StorageClass provisioning to cluster administrators. The PVC is the application-facing request for storage; binding and provisioning happen through admin-provided classes and dynamic provisioners common in city platforms.
Always defining a PersistentVolume first in the same namespace as the Pod misunderstands PV scope (cluster-scoped) and blurs admin vs developer responsibilities. Editing the default StorageClass reclaimPolicy from the application Deployment is an admin operation and not done via Deployments. Binding hostPath PersistentVolumes directly from the container image build is not an image concern.
Exam caveat: Know PVC YAML fields apps author—accessModes, resources.requests.storage, storageClassName—without authoring PVs in many exam environments.
Operational check: kubectl apply pvc; kubectl get pvc to Bound; mount claimName in the Pod template; kubectl describe pvc; avoid creating PV objects unless the task explicitly requires static provisioning. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.