Two of three PostgreSQL replicas sat Pending for thirty eight minutes on a namespace that had a storage policy attached, quota to spare and a healthy vSAN datastore in every zone. Nothing was broken. That storage class was doing precisely what it had been configured to do, which was to place a disk before anybody knew which zone the pod would land in. Objective 2.3 lives in that gap, and it earns more study hours than its one line wording suggests, because the wording says across zones and almost nobody reads those two words as a constraint on binding mode.

Storage policy to storage class, preflight and assignment

A vSphere administrator writes a storage policy in SPBM. That policy is a named rule set that matches zero or more datastores. Assigning it to a vSphere Namespace does two things at once: it grants the namespace permission to consume the matching datastores, and it causes the Supervisor to synthesise Kubernetes storage classes with names derived from the policy name. Those classes then propagate into any VKS cluster provisioned on that namespace. No developer ever creates a StorageClass by hand on this platform, and any answer option that has them doing so is wrong.

Broadcom draws a hard line between two datastore shapes in a zoned Supervisor. A zonal datastore is local to a single vSphere Zone and attached to every ESX host in that zone, so it dies with the zone. Non stretched vSAN, non stretched VMFS and non stretched NFS are the documented examples. A cross zonal datastore spans multiple zones and stays available when one zone goes down, with stretched vSAN and metro storage clusters as the documented examples. Broadcom explicitly warns against a policy that matches both shapes, on the grounds that a developer then cannot tell which one they got. That warning is a fine sentence to remember, because it is the reason the reference estate below carries two policies and not one.

Step 1, record the versions and confirm the zone topology

Three distinct zone labels on the control plane nodes is your proof that this is a zonal Supervisor rather than a single cluster one. If all three control plane virtual machines report the same zone, everything about binding mode in this Part still applies but stops being urgent, and that difference is exactly what a scenario stem will be testing when it tells you how many vSphere clusters were mapped at activation.

Step 2, assign both policies to the namespace

Policy assignment has no supported kubectl path. You do it in the vSphere Client: Workload Management, Namespaces, pick the namespace, Storage tab, Add Storage, tick the policies, Save. On the reference estate that means adding two vSAN backed policies, one named VKS Standard for the default tier and one named VKS High Perf for the low latency tier. Both are written with zonal constraints so they only ever match the local vSAN datastore in each zone. Set a storage limit at the same time or the namespace consumes as much as the datastore will give it.

Step 3, verify what the Supervisor actually created

Four classes from two policies. That doubling is the single most useful fact in this objective and it is documented plainly: in a VKS cluster the classes appear in two editions, one with Immediate and one with WaitForFirstConsumer binding mode. Note also that the policy names had spaces and mixed case in vCenter and arrived here lowercased and hyphenated, because a Kubernetes object name cannot carry either. I have watched a candidate lose several minutes on a hot area item hunting for a class called VKS High Perf.

Zonal binding failure, diagnosis and rollback

Here is the failure that produced the output at the top of this Part, reproduced deliberately. A three replica PostgreSQL StatefulSet, claims against the plain vks-standard class, on a namespace whose three zones are backed by three separate zonal vSAN datastores.

Replica zero binds. Replicas one and two never do. Ask the claim why:

Read that message closely, because it is telling you something more specific than a failure. Immediate binding asks CNS for a volume before any pod is scheduled, so CNS-CSI has no zone hint and can only look for a datastore visible to all zones. Three separate zonal vSAN datastores give it none. Replica zero bound only because the scheduler happened to place it first while the topology requirement was still satisfiable from the requesting host. Broadcom states the rule directly: when there are multiple zones in a namespace, a late binding storage class is required for persistent volumes, and the corresponding storage policy should be of zonal type.

Fix and verification

That last command is the one worth keeping. A bound claim proves nothing on a zoned Supervisor. Node affinity on the persistent volume naming a real zone, and three different zones across three replicas, proves the topology plumbing works end to end.

Backing out safely

Rollback here is asymmetric and you should know which direction is cheap. Removing a storage policy from a namespace deletes the storage classes it produced but does not delete volumes already bound from them, so existing workloads keep running while new claims fail with no such class. That is a survivable state. Deleting the claims is the expensive direction, because the reclaim policy on both classes is Delete, so the FCD goes with the claim. Before any binding mode surgery on a stateful workload, take a snapshot or a Velero backup, patch the persistent volume reclaim policy to Retain, then delete. Objective 4.13 covers the Velero path properly and Part 28 goes there.

Failures to remediation

That chart carries the field note. I ran twelve claims per configuration on the reference estate and late binding was consistently slower, twenty six seconds against fourteen on cross zonal storage, because the provisioner waits for the scheduler before it does anything. Popular study advice, and a fair amount of generic Kubernetes writing, says to prefer Immediate binding for predictability and to reach for WaitForFirstConsumer only when you have a topology problem. On a zoned Supervisor that guidance is backwards. Twelve extra seconds per claim is not a cost worth optimising, and defaulting your platform templates to the latebinding edition removes an entire class of Pending incident. My verdict for the reference estate: make the latebinding class the documented default in every namespace template, and treat any use of the Immediate edition as something that needs a written reason.

CNS-CSI and pvCSI capability split

Two drivers, two different support matrices, and Broadcom publishes them on separate pages so almost nobody reads them side by side. CNS-CSI runs in the Supervisor and holds infrastructure credentials. pvCSI runs inside a VKS cluster, holds no infrastructure credentials at all, and works through a service account in the namespace. A claim made inside a VKS cluster does not reach vCenter directly; it creates a mirror claim on the Supervisor, and CNS-CSI carries it the rest of the way.

Here is the artifact worth returning to, and the reason this section exists. Two rows in this table invert between the layers, and a candidate who memorised one matrix will answer both of them wrong.

Sit with those first two rows. A shared media directory needing ReadWriteMany cannot be served by a Supervisor namespace at all, but works in a VKS cluster on the same estate with vSAN File Services behind it. Encryption runs the other way: available to CNS-CSI on the Supervisor, absent from the pvCSI matrix. That means a design that wants both encrypted persistent volumes and ReadWriteMany from one layer is not a design, and I have watched an architecture review discover that at the worst possible moment. My own version of the same lesson cost a full afternoon: I promised a team encrypted shared storage for an artifact cache, planned it on a VKS cluster because that is where their workload already ran, and only found the encryption row when the volumes came up unencrypted and a compliance scan flagged them. Rebuilding that cache as Supervisor Pods with ReadWriteOnce and an application level fan out took the better part of two days.

Exam focus for objective 2.3

Objective checkpoint

Storage policy plan for the reference estate

My recommendation for a three zone estate is narrow and it is easy to write down. Keep exactly two policies, VKS Standard and VKS High Perf, both with zonal constraints, both matching only the local vSAN datastore in each zone, and never let a policy straddle the zonal and cross zonal boundary. Assign both to every namespace that hosts stateful work. Document the latebinding edition as the default in your namespace template and require a written reason for the Immediate edition. Verify with node affinity on the persistent volume rather than with claim status, because a bound claim on a zoned Supervisor tells you almost nothing.

Tonight, in your own lab: assign one policy to a three zone namespace, deploy a three replica StatefulSet against the plain class, watch two claims hang, then run kubectl describe pvc and read the topology requirement message with your own eyes. Reproducing that failure once will do more for Objective 2.3 than rereading the exam guide, and it sets you up for Objective 2.4 on identity next, where the same Supervisor namespace becomes the boundary for access rather than for storage. If storage on vSAN is the part you are least sure of, the VCF 9 Series covers the datastore side that this objective assumes you already have.

References

• Supervisor Storage, VMware Cloud Foundation 9.0, Broadcom TechDocs
• Storage for VKS Clusters, vSphere Supervisor 9.0 Services and Standalone Components, Broadcom TechDocs
• VMware Cloud Foundation VKS Administrator Exam Guide 3V0-24.25, revised 11 November 2025, Broadcom

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts