A school district wants to stop surprise dynamic volumes from expensive default storage. Which admin control directly addresses that risk?
Select an answer to reveal the explanation.
Short Explanation
If the cafeteria’s “default meal” is the pricey steak plate, change what’s marked default—or require an explicit order. Same for StorageClass: manage the is-default-class annotation so forgotten storageClassName fields don’t mint expensive disks. Killing CSI or scaling apps to zero just breaks things while the default still lurks.
Full Explanation
A school district that wants to stop surprise dynamic volumes from expensive default storage should clear or move the default StorageClass annotation so omitted storageClassName no longer auto-selects a costly class. Managing what is marked default—or requiring explicit class names—is the direct admin control for accidental premium disk minting. Killing unrelated components while leaving the default in place does not fix the surprise.
Deleting the CSI driver DaemonSet but leaving the default StorageClass annotation breaks provisioning without correcting the default policy. Setting every Deployment replicas to 0 stops workloads but does not change default class selection for PVCs that still arrive. Renaming PersistentVolumes with a temp- prefix does not disable defaults.
Exam caveat: with no default class, PVCs that omit storageClassName may stay Pending until a class is set—communicate that to app teams. Some platforms use admission policies to ban empty class fields entirely.
Operational check: remove or relocate storageclass.kubernetes.io/is-default-class, attempt a PVC without storageClassName and confirm behavior, publish the approved class names, and monitor for unexpected premium PV provisioning.