Sanitation platform engineers want a catalog of storage tiers available to application teams. Which objects should they list?
Select an answer to reveal the explanation.
Short Explanation
StorageClasses are the menu board hanging in the platform cafeteria—each entry is a tier with a provisioner and options. Listing them tells teams what’s on offer. ReplicaSets, DNS endpoint port names, and LimitRanges are not that catalog.
Full Explanation
Sanitation platform engineers advertising a catalog of storage tiers to application teams should list StorageClass objects. Each StorageClass advertises a provisioner, parameters, binding mode, expansion, and reclaim defaults—the menu board in the platform cafeteria. Inventorying StorageClasses answers which backends and performance tiers teams may request for municipal apps.
ReplicaSets do not imply unique storage backends per replica for catalog purposes. EndpointSlices for kube-dns do not encode disk SKUs in port names. LimitRange objects alone do not replace StorageClasses in modern clusters; they set min/max/defaults for compute or storage requests, not the provisioner catalog.
Exam caveat: cluster-scoped StorageClasses are visible across namespaces, but RBAC may limit who can create PVCs against them. Document which classes are approved for production versus scratch.
Operational check: kubectl get storageclass -o wide, publish the list with intended use (SSD databases, cheap bulk, WaitForFirstConsumer), and verify a sample PVC against each approved class. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.