Storage selection is a workload contract

Choose from access pattern, failure tolerance and performance before choosing a StorageClass.

Need	First candidate	Reason
Single-writer general block	Balanced Persistent Disk	Durable, familiar and dynamically provisioned
Cross-zone block resilience	Regional Persistent Disk	Replicates within two zones of a region
Shared POSIX-like files	Filestore	Managed NFS and ReadWriteMany
Object data through file API	Cloud Storage FUSE	Bucket scale with file-oriented application access
Tunable block performance	Hyperdisk	Independent performance controls on supported shapes

Validate backup, restore and failover behavior with the exact StorageClass, not only the product family.

Storage decision is easiest to understand by separating the Kubernetes contract from the Google Cloud implementation. A PVC hides provisioning mechanics but not storage semantics. Build platform classes that encode supported choices and backup expectations. The Kubernetes objects stay familiar, but GKE supplies controllers, infrastructure and safe defaults around them. This is why a team can move from an on-premises cluster without rewriting every workload, while still needing to redesign networking, identity and operational ownership for the cloud environment.

A useful inspection step is `kubectl describe pvc payments-data -n payments`. Read the output as evidence, not as a ritual: first confirm the desired object exists, then look at status conditions, events and the Google Cloud resource it represents. In production, capture the expected result in a runbook or automated check so an operator can distinguish slow reconciliation from a configuration error.

Production gotcha: The default StorageClass is convenient, not automatically correct for availability, performance or data-loss objectives. The safe habit is to verify quotas, regional availability and feature support against current Google Cloud documentation before rollout. Module 7 connects evidence, cost and troubleshooting.