A candidate on a study call last month asked me which Supervisor settings he would be stuck with forever if he got them wrong. He had been working through a screenshot walkthrough of the activation wizard, memorising field order. That is the wrong artifact to memorise. What Objective 2.1 rewards is knowing which of those fields you can revisit on a Tuesday afternoon and which one costs you a platform rebuild, because a scenario item will hand you a running Supervisor and a new requirement and ask what happens next.

Fixed at activation versus changeable later

Before any of the mechanics, here is the shape of the problem in wall clock. I timed five common post activation changes on the lab estate, each one from clicking Save to the Supervisor reporting Running again. Four of them are coffee break work. One of them is a maintenance window.

Now the artifact worth bookmarking. I call it the activation permanence table, and it is the thing I would print and stick to the wall a week before sitting this exam. Every row is a field you either saw in the activation flow or will meet in Configure, and the second column is the one the item writers care about.

Read the first three rows together and you have the whole exam angle. Everything permanent about a Supervisor is a topology decision, and every topology decision was made in the first ten minutes of activation. Everything else, including things that feel structural like storage and identity, is a runtime setting you can revise. Candidates who study this objective as a component glossary get caught by scenario items that hinge entirely on that split.

flowchart TD
  A[Change requested on a running Supervisor] --> B{Was it set at activation}
  B -->|Networking stack| C[Rebuild required]
  B -->|Management zone count| C
  B -->|Supervisor name| C
  B -->|No| D{Direction of change}
  D -->|Control plane size upward| E[Rolling replace, maintenance window]
  D -->|Control plane size downward| C
  D -->|Storage, DNS, NTP, proxy, IdP, default CNI| F[Edit in place, no restart]
  D -->|Add workload zones to a namespace| G[Namespace edit, Objective 4.2]

Every command below assumes the lab estate this series has been building since Part 3. Last Part we chose the zone model on paper. This Part the Supervisor is live on three zones and we go and interrogate it.

I use the vSphere plugin for kubectl rather than a raw kubeconfig on the Supervisor side for one reason worth saying once: the plugin fetches a short lived token tied to your vCenter single sign on session, so the same login that authorises you in vCenter authorises you against the Supervisor API. A static kubeconfig would decouple the two and hide exactly the RBAC behaviour later objectives test.

Components and capabilities you actually configure

Ask most vSphere admins what a Supervisor is and you get an answer about control plane VMs. That answer is a third of the object. Broadcom documents five components, and three of them run nowhere near the control plane VMs.

Run the node listing on a three zone Supervisor and the mixture becomes obvious. Three control plane VMs with Kubernetes style names, then six ESX hosts appearing as worker nodes because Spherelet put them there.

That last line is a real failure from my lab and it is worth pausing on, because a NotReady ESX node in a Supervisor is not a Kubernetes problem. Spherelet had stopped on that host after a network maintenance window, and until it came back the host contributed no capacity to any vSphere Pod placement, while still looking perfectly healthy in the vSphere inventory. Restarting Spherelet on the host cleared it in under a minute. An admin who only watches vCenter alarms will never see this.

Capabilities are the second noun in the objective, and here the networking choice from activation reaches forward and decides what the platform can run at all.

Broadcom states the constraint plainly in the VCF 9.0 documentation: a cluster configured with NSX supports running a vSphere Pod and a VKS cluster, while a Supervisor configured with the vSphere networking stack supports VKS clusters only. Popular study advice treats vSphere Pods as a universal Supervisor feature you can reach for anywhere. In practice they are a capability you bought with your networking decision, and if the answer options in an item include a vSphere Pod on a VDS backed Supervisor, that option is wrong on its face.

Services are the third noun. Supervisor Services are optional add on packages that install onto a running Supervisor and then present themselves to namespace consumers, Harbor as a private container registry and external-dns as a DNS record publisher being the two the blueprint names by example. They register through the appplatform API group, which is where discovery becomes useful.

Control plane resize, start to finish

Of everything in the permanence table, control plane size is the row that gets people, because it looks changeable and is only half changeable. Four sizes exist, Tiny through Large, and once you have picked one you can move up and never down. Here is the procedure end to end on the lab estate.

Step 1, preflight the current state

Three things have to be true before you touch the size field. All control plane VMs are healthy, the Supervisor is not mid upgrade, and there is at least one free address in the management IP range for the replacement VM. Part 4 established why the management range needs headroom beyond the running VMs. This is the operation that spends it.

Step 2, apply the size change

No CLI path exists for this one. In vSphere Client, go to Workload Management, select the Supervisor, then Configure and General, and edit Control Plane Size. Pick the next size up and save. If you open that list expecting to go down, you will find out immediately that you cannot.

Step 3, watch the rolling replacement

vCenter does not resize the existing VMs. It builds a replacement control plane VM at the new size, joins it, drains and removes an old one, and repeats. On the lab estate that took 45 minutes across three VMs, roughly 13 to 14 minutes each plus validation. During each swap the Supervisor API stays reachable through the floating address, but the endpoint moves, so a long running kubectl watch will drop and need restarting.

Step 4, verify

Green looks like three Ready control plane nodes with fresh ages, the Supervisor Config Status reading Running in vSphere Client, and every namespace still resolving. Node age is the fastest tell that the replacement actually happened rather than silently stalling.

Step 5, rollback and fallback

There is no rollback for a size increase, which is the honest answer and the one an item will test. Your fallback is a partial one. If the resize wedges midway, the Supervisor keeps serving on whichever control plane VMs are still Ready, so the safe move is to stop, free whatever resource is blocking the next VM, usually an IP address or cluster capacity, and let the operation resume rather than cancelling it. If the whole Supervisor becomes unrecoverable, restoring it is a separate exercise that leans on the Supervisor backup path and is out of scope here.

Exam focus for objective 2.1

Objective checkpoint

Activation decisions worth writing down

My recommendation for this objective is narrow and practical. Keep a one page record of every activation choice on every Supervisor you run: networking stack, management zone count, control plane size, storage policies and the management IP range with its spare addresses counted. Four of those five you can change later, and knowing which one you cannot is the difference between answering a scenario item in ten seconds and talking yourself into a rebuild that was never required.

Tonight, do one thing in your own lab. Open Workload Management, go to Configure on your Supervisor, and walk every tab writing down which fields are editable and which are greyed out. That greyed out list is your permanence table, verified against your own build rather than mine, and it takes about fifteen minutes. Part 6 picks up the networking half of that record and takes Supervisor networking apart properly, VDS against NSX segments against VPC, with the load balancing path attached.

References

• Supervisor Architecture and Deployment Options, Broadcom TechDocs, VCF 9.0
• Configuring and Managing a Supervisor, Broadcom TechDocs, VCF 9.0
• Change the Control Plane Size of a Supervisor, Broadcom TechDocs, VCF 9.0
• VMware Cloud Foundation VKS Administrator Exam Guide, 3V0-24.25

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