Until now, the VMware Certified Advanced Professional programme for VMware Cloud Foundation 9 was organised by pillar. There were five VCAP exams, one for each functional area of the platform: Automation (3V0-21.25), Operations (3V0-22.25), Storage (3V0-23.25), VKS (3V0-24.25) and Networking (3V0-25.25). Broadcom has now added a second dimension. Three new exams, all with guides dated 18 August 2026, are organised by role rather than by pillar: the VCAP-VCF Administrator (3V0-11.26), the VCAP-VCF Architect (3V0-12.26) and the VCAP-VCF Support (3V0-13.26). That brings the total number of VCF 9 VCAP certifications to eight, and registration for the new three is open through the Certmetrics portal.

I passed the five pillar exams earlier this year, so I have read the new blueprints with some interest. The short version is that the role-based exams cut across the same product areas as the pillar exams, but each one takes a single perspective on all of them: designing the platform, running it or fixing it. In this post I walk through what each new exam tests, how it relates to the pillar exams you may already hold and what I would recommend if you are planning to sit one of them.

Eight VCAPs: two ways to slice the platform

The two exam families are best understood as a matrix. The pillar exams go deep on one component and cover it end to end, from design through configuration to troubleshooting. The VCAP-VCF Networking exam, for example, expects you to design, deploy and troubleshoot NSX in a VCF context. The new role-based exams go the other way: the Administrator exam covers configuration across all five pillars, the Architect exam covers design across all five and the Support exam covers troubleshooting across all five.

That also explains the recommended training. The pillar certifications point at the existing per-pillar courses, while each role-based exam recommends a full series of six courses, one per pillar plus VKS, in the matching flavour: Advanced Configuration for Administrator, Advanced Design for Architect and Advanced Troubleshooting for Support. If you already hold one or more pillar VCAPs, you will recognise a large part of the content, but you should expect it to be tested from a different angle and with less depth per component.

For candidates deciding where to invest, the practical difference is this: a pillar VCAP proves you are the specialist for one area, a role-based VCAP proves you can carry a whole VCF private cloud in a particular capacity. Both are valid signals, and they are complementary rather than overlapping.

The shared format

Before looking at the individual blueprints, it is worth noting that Broadcom has standardised the mechanics across all three exams. Each one is a 60-item exam with a 135-minute appointment, a passing score of 300 on a scaled method and a price of USD 250. All three are proctored and delivered through Pearson VUE. The extra time compared to the older 40-item VCP exams is explicitly meant to give non-native English speakers room to work through scenario-based questions.

The item types are also more varied than the classic VCP multiple choice. The guides list multiple-choice, multiple-selection multiple-choice, build-list, matching, drag-and-drop, point-and-click and hot-area questions. The Support exam guide even flags two objectives as "Simulations", which suggests some hands-on style items around NSX routing. Anyone who remembers the VCAP-DCV Deploy lab exams will notice that these are still not full live-lab exams, but they are a clear step up from pure knowledge recall.

One more structural point that I found elegant: Broadcom has standardised the exam blueprint into five sections, and the three role-based exams divide those sections between them almost perfectly. The Architect exam owns sections 1 to 3 (IT architectures, VMware products and solutions, and plan and design). The Administrator exam owns section 4 (install, configure, administrate). The Support exam owns section 5 (troubleshoot and optimise). No section is tested twice. If you hold all three, you have effectively covered the entire VCF 9 blueprint.

VCAP-VCF Administrator (3V0-11.26)

The Administrator exam is aimed at the people who actually run a multi-region or multi-organisation VCF private cloud day to day. The "minimally acceptable candidate" description in the guide expects comprehensive knowledge of vCenter, ESX, vSAN, NSX, VCF Identity Broker, VCF Automation, VCF Operations (including Logs, Fleet Management and Networks) and the vSphere Kubernetes Service (VKS).

With 60 objectives in a single section, this is the heaviest of the three blueprints and the one that most directly reflects how VCF 9 has changed the operational model. Reading through the objectives, a few clusters stand out.

Storage and compute in the workload domain

Objectives 4.1 to 4.18 are the classic infrastructure layer, but updated for VCF 9: deploying vSAN clusters and vSAN stretched clusters inside a workload domain, bringing in supported non-vSAN storage, configuring vSAN cross-cluster capacity sharing and vSAN Storage Clusters, vSAN encryption and vSAN Data Protection, storage policies, CPU and memory optimisation, vCenter performance tuning, and VM encryption with vSphere Trusted Environments. This is where the vSphere 9 content lives and it will feel familiar to anyone with a vSphere or vSAN background.

VCF Automation: Provider and Organization model

Objectives 4.19 to 4.29 are entirely new territory for most vSphere administrators. VCF Automation in version 9 introduces a Provider Management portal, Organizations, the Provider Consumption Organization (PCO) and the "All Apps Organization" model with Projects, Governance Policies, Namespace Classes and VPC connectivity profiles. Identity providers and access control are configured at both the Provider and Organization level. If you have only ever worked with vRealize Automation or Aria Automation, plan to spend real time here.

vSphere Kubernetes Service

Objectives 4.30 to 4.34 cover the Supervisor: creating Supervisors with NSX VPC, NSX Segment, vDS and Avi load balancer options, installing and managing Supervisor add-on services such as Harbor and external-dns, rolling updates of VKS clusters, package repositories and private registries, and upgrading the Supervisor Service.

VCF Operations and Fleet Management

Objectives 4.35 to 4.47 are the operational management layer: reclaiming resources, rightsizing, capacity forecasting with What-If scenarios, cost management, policies, the distinction between Business Intent and Operational Intent, Business Applications, alerts, scaling and upgrading a VCF Fleet, SSO through Identity and Access Management, and configuration drift monitoring.

NSX

Finally, objectives 4.48 to 4.60 are the networking block: NSX Federation in VCF, Edge clusters, Tier-0 and Tier-1 gateways, VRF, segments, VPCs, DHCP, NAT, Projects and tenancy, advanced integrations and operational tasks such as syslog and backup and restore. It is a substantial NSX component for an exam that is not branded as a networking certification.

VCAP-VCF Architect (3V0-12.26)

The Architect exam is the design counterpart and, for my own work, the most interesting of the three. Where the Administrator and Support exams ask "how do you do this", the Architect exam asks "why would you choose this, and what are the consequences". The candidate is expected to design a multi-region or multi-organisation VCF private cloud end to end, producing conceptual, logical and physical design outcomes that meet stakeholder requirements.

The blueprint has 20 objectives across the first three sections, and the structure will look familiar to anyone who has taken a VCAP or VCDX design exam before.

Section 1 covers the design methodology itself: differentiating business and technical requirements, separating requirements from assumptions, constraints and risks, working with the AMPRS design qualities (availability, manageability, performance, recoverability and security), developing design decisions and developing a design validation strategy. This section is about the discipline of architecture, not about VCF specifically.

Section 2 is short but important. It asks you to differentiate between VCF architecture options, to evaluate recommended versus merely supported design choices across the VCF portfolio, and to identify use cases for VCF Advanced Services. That second objective is the one that catches people: knowing that something is supported is not the same as knowing whether you should recommend it.

Section 3 is the core of the exam. It walks through the full design flow: gathering and analysing business objectives, creating a conceptual model, creating VCF logical and physical designs, and then one objective each for designing for availability, manageability, performance, recoverability and security. Three further objectives cover designing for identity management, designing a consumption strategy for VCF and designing a monitoring strategy for VCF. Those last three are new compared to older design blueprints and map directly onto VCF Identity Broker, VCF Automation and VCF Operations.

If you are used to writing High-Level Designs for VCF customers, most of this will feel like a formalisation of what you already do. The challenge is that the exam expects you to reason about the VCF 9 component set, including VKS, VPCs, stateful NSX gateway services and the Provider and Organization model of VCF Automation, not just about vSphere and vSAN.

VCAP-VCF Support (3V0-13.26)

The Support exam is the one that did not exist in previous generations of the VMware certification programme in this form. It targets professionals responsible for maintaining and troubleshooting VCF components against service level objectives, and the candidate profile explicitly mentions using the available APIs and knowing when to engage colleagues or Broadcom support. The exam lives entirely in section 5 of the blueprint, with 30 objectives.

The objectives are organised by component. Storage comes first: monitoring and troubleshooting vSAN as well as supported non-vSAN storage using the tools available in VCF. Then the workload domain itself: identifying the right tools, and troubleshooting ESX hosts, the workload domain vCenter, clusters and individual virtual machines, followed by performance optimisation of both the workload domain and the VMs in it.

VCF Automation gets three monitoring objectives, covering VCF Automation via VCF Operations, Provider Management and All Apps Organizations. VKS gets four: diagnosing Supervisor and VKS cluster provisioning, connectivity or namespace errors, troubleshooting container deployment, registry and trusted CA errors, restarting or recovering failed VKS upgrades, and optimising cluster performance through monitoring and scaling.

VCF Operations is treated as both a subject and a tool. You are expected to troubleshoot the Operations infrastructure itself (Cloud Proxy, clusters, HA, adapters) and to use VCF Operations, Operations for Networks and Operations for Logs to troubleshoot VCF configuration, network and workload issues, as well as to work with alerts.

The NSX block closes the blueprint: choosing the right VCF tool for an NSX problem, common infrastructure issues, connectivity and routing issues, and the two simulation-flagged objectives on ECMP with high availability and the logical routing packet walk. If you are going to sit this exam, being able to draw the NSX packet walk from memory is clearly not optional.

Recommended training

As mentioned above, each of the new exams recommends a series of six courses: VMware Cloud Foundation Storage, Automation, Operations, Networking and Compute, plus vSphere Kubernetes Service, each in the Advanced Configuration, Advanced Design or Advanced Troubleshooting flavour. That is eighteen distinct courses across the three role-based tracks, which tells you something about the size of the VCF 9 platform.

As a VMware Certified Instructor I obviously have an interest here, but my honest view is that the courses are the fastest route to the VCF Automation and VKS content in particular, because that is where the product has changed the most and where documentation alone is hardest to turn into working knowledge. For the vSphere, vSAN and NSX content, experienced administrators can probably rely on hands-on lab time and the Broadcom TechDocs.

The exam guides list three references that item writers work from: the VMware private cloud topic pages on vmware.com, the Broadcom TechDocs portal and broadcom.com. In practice, TechDocs is the one that matters. Read the release notes for VCF 9 as well; the guides state explicitly that the exam content is based on the current VCF release and that release notes are in scope.

Which exam should you take?

All eight exams are independent. There is no prerequisite chain between the pillar exams and the role-based exams, and each one leads to its own certification. That makes the choice a matter of role rather than sequence.

If you operate a VCF environment, start with the Administrator exam. It is the broadest of the three and the one most likely to match your daily work. If you design VCF environments or write the architecture documents that other people implement, the Architect exam is the natural choice, and the design methodology in sections 1 and 3 is a genuinely useful framework even if you never sit the exam. If you are in a platform support or escalation role, or you are the person people call when the Supervisor will not provision, the Support exam is built for you.

For those aiming at all three, I would suggest Administrator first, then Support, then Architect. The Administrator blueprint teaches you what every component does, the Support blueprint teaches you what happens when it breaks, and the Architect exam then asks you to make decisions based on both. If you already hold the pillar VCAPs, the Administrator exam should be the most comfortable starting point, because its objectives overlap most directly with the configuration content you have already studied.

A few notes on the exam guides

The guides are clearly first editions. The Architect guide refers in one footnote to content being based on "VVF" rather than VCF, and its "Related Certification" line lists the Administrator title against the Architect exam code. Neither affects the objectives themselves, but if you see a corrected revision appear on the Broadcom site, that is why. I would expect the guides to be updated before the first cohort of candidates has finished studying.

Having completed the five pillar exams, the three role-based ones are the obvious next step for me, and I plan to sit them in the coming months. I will share my experience here once I have. In the meantime, the full list of VCF 9 VCAP certifications, the exam guides and the registration link are below.

The full VCF 9 VCAP line-up

Pillar-based (3V0-2x.25)

• VCAP - VMware Cloud Foundation Automation (3V0-21.25)
• VCAP - VMware Cloud Foundation Operations (3V0-22.25)
• VCAP - VMware Cloud Foundation Storage (3V0-23.25)
• VCAP - VMware Cloud Foundation VKS (3V0-24.25)
• VCAP - VMware Cloud Foundation Networking (3V0-25.25)

Role-based (3V0-1x.26, new)

• VCAP-VCF Administrator (3V0-11.26): certification page and exam guide
• VCAP-VCF Architect (3V0-12.26): certification page and exam guide
• VCAP-VCF Support (3V0-13.26): certification page and exam guide
• Exam registration: Certmetrics portal
• Reference documentation: Broadcom TechDocs

Broadcom opened VMware Explore 2026 in Las Vegas today with the clearest articulation yet of where VMware Cloud Foundation is heading: the Private AI Cloud. After two years of positioning VCF 9 as the modern private cloud platform, the message this year is that private cloud and private AI infrastructure are no longer separate disciplines — they are converging into a single platform. Here's my rundown of everything announced today, and what it means for those of us designing and running these environments.

VMware Private AI Cloud: the new umbrella

The headline announcement is VMware Private AI Cloud, Broadcom's integrated approach to running AI workloads — inference, agentic applications, and traditional enterprise workloads — side by side on infrastructure you own. It brings together VCF 9 as the foundation, the new VMware AI Factory, the VMware Tanzu Platform for agent foundations, vDefend for hypervisor-level microsegmentation, and the brand-new AgentMinder for AI agent governance.

Ram Velaga, president of Broadcom's Infrastructure Software Group, called it "the inflection point where enterprise private cloud and private AI infrastructure stop operating as separate disciplines." The timing is backed by Broadcom's own Private Cloud Outlook 2026 research: 56% of enterprises now plan to run production AI inferencing on their private cloud.

VMware AI Factory: bare metal to inference in hours

For infrastructure architects, VMware AI Factory is the most significant piece. It's a software-defined foundation — included in VCF at no additional cost — that automates the full path from bare metal to a running model. Broadcom claims deployment times drop from weeks to hours. The building blocks:

• Automated AI-ready infrastructure — provisioning and unified lifecycle management that spans hardware and software, with heterogeneous bare metal automation through a MetalSoft integration.
• Model Runtime and a unified Model Gallery — one interface for managing model inference and RAG workflows across VMs, containers, and GPU resources, with new multi-tenant model sharing via isolated namespaces.
• GPU resource pooling — multiple models sharing the same accelerators to improve utilization and control what Broadcom is now calling "AI tokenomics."
• AI Gateway — unified governance across on-prem and cloud endpoints with intelligent prompt routing, token limiting, and rate limiting.
• Secure AI sandboxes — isolated container spaces for executing agent-generated code with proper control layers.

Just as notable is the hardware story. AI Factory pairs VCF not only with NVIDIA but now formally with AMD Instinct GPUs and the ROCm ecosystem, running on certified AI ReadyNodes from Cisco, Dell Technologies, Lenovo, and Supermicro. VMware Chief Product Officer Paul Turner summed it up: customers get "a software-defined foundation that automates infrastructure deployment, unifies lifecycle management, and lets them choose their preferred hardware and vetted models."

Leading AI models, validated on VCF

Broadcom also announced a set of frontier and enterprise models tested and validated to run on VCF:

• NVIDIA Nemotron 3 — multimodal, hybrid Mamba-Transformer architecture, 1M-token context window.
• Google DeepMind Gemma 4 — open-weight multimodal model built for local execution.
• NEC cotomi — Japanese-language model with roughly 40% better token efficiency.
• Alibaba Qwen 3.7-Max — proprietary multimodal model with a one-million-token context window.
• Z.ai GLM 5.2 — open-source model aimed at coding and reasoning agents.

On top of that, VCF supports more than 150 open-source models through the vLLM runtime, with MLPerf Inference v5.1 results showing performance "on par with bare metal" — and mixed compute across AMD, Intel, and NVIDIA hardware. Chris Wolf framed it as "a clear path to data sovereignty and cost-effective AI at scale," which is exactly the conversation I'm having with regulated and government customers every week.

AgentMinder: governance for autonomous agents

AgentMinder — generally available today — is Broadcom's answer to the question every security team is asking: what happens when AI agents start acting on enterprise systems? AgentMinder treats every agent as an enterprise identity with a declared mission, permitted intents, approved tools, and authorized resources. A cloud-native gateway authenticates and authorizes every tool call at runtime against a dynamic policy engine, and OpenTelemetry-based observability delivers compliance-grade audit trails — a "chain of custody" for agent actions.

Broadcom has been running it internally at serious scale: 36 million customer-related and 7 million workforce-related API calls per day, across more than 20 million customer identities. Clayton Donley described it as "a traffic controller" for agents — verifying what they're doing, providing guardrails, and tracking their work.

Tanzu Platform: AI-ready data foundations

The Tanzu team is tackling what Purnima Padmanabhan called the real blocker: "Enterprises do not have an AI ambition problem. They have an agent trust problem." Coming in Fall 2026, the Tanzu Platform adds hardened agent sandboxes with a deny-by-default runtime model (isolating credentials and blocking prompt-injection and unauthorized network access), AI-ready data foundations that process structured and unstructured data on-prem to give agents high-precision context (fewer hallucinations, lower token spend), and governance across three dimensions: access, context, and lineage — so every agentic decision can be traced back to its data sources. A curated marketplace of vetted models and tools plus a Tanzu AI gateway for monitoring, rate limiting, and credential management round it out.

Security hardening: vDefend, Avi, and TrueSource

A few security announcements deserve their own call-out:

• vDefend gains detection of unauthorized shadow AI usage inside the private cloud — a topic close to my heart, as regular readers know.
• Avi Load Balancer adds Agentic Threat Defense, with MCP tool restrictions and real-time threat isolation to prevent agent tool misuse and data exfiltration.
• TrueSource is a new verified open-source portfolio, available today: Trusted Artifacts (secure builds for Java, Python, and Node.js), Data Services (PostgreSQL, RabbitMQ, MySQL, Valkey), alongside the existing Spring Enterprise offering.

Ecosystem momentum

Beyond the product news, colocation provider Flexential announced plans to build AI offerings on VMware AI Factory launching early 2027, combining its infrastructure footprint with hosted Private AI services — an early sign that the AI Factory model will extend beyond enterprise datacenters into the provider ecosystem.

My take

What strikes me most about this year's Explore is coherence. Last year, Private AI Foundation with NVIDIA was an add-on you architected alongside VCF. Today, AI Factory is simply part of the platform — the same VCF domains, the same lifecycle management, the same operational model, now extended from bare metal all the way to model endpoints. For organisations where data sovereignty is non-negotiable, the combination of validated models running at near bare-metal performance, agent governance with a real audit trail, and shadow-AI detection makes the private cloud case stronger than it has ever been.

The multi-vendor accelerator story (NVIDIA and AMD), the model-vendor breadth (from Nemotron to Gemma to Qwen), and the fact that AI Factory ships in VCF at no additional cost all point in the same direction: Broadcom wants the private AI conversation to start — and stay — on VCF. I'll be digging into the AI Factory architecture, Model Runtime, and AgentMinder in detail in upcoming posts and videos as the bits become available.

Broadcom Introduces VMware Private AI Cloud (Aug 31, 2026)

Broadcom Announces VMware AI Factory (Aug 31, 2026)

VMware Cloud Foundation Brings Leading AI Models to the Private AI Cloud (Aug 31, 2026)

Broadcom Unveils AgentMinder (Aug 31, 2026)

Broadcom Unveils AI-Ready Data Foundations in VMware Tanzu Platform (Aug 31, 2026)

VMware Explore 2026 Las Vegas Media Kit — Broadcom

Network World — Private AI cloud, agentic infrastructure dominate VMware Explore

Athom recently released the Homey Self-Hosted Server as an official Docker image (ghcr.io/athombv/homey-shs), which means you can now run the Homey smart home platform on your own hardware instead of a Homey Pro appliance. That raises a fun question for those of us running VMware Cloud Foundation at home or in the lab: where does a container like this land in a VCF 9.1 environment? A vSphere Pod on the Supervisor, a VKS cluster, or a plain Docker VM?

The short answer: put it in a small Linux VM in a workload domain. The longer answer is more interesting, because this little container is a nice case study in why some workloads fundamentally don’t fit vSphere Pods — and why that is by design.

What the Homey container actually needs

The requirements from Athom’s documentation are modest: a Linux-based OS (Debian or Ubuntu), an Intel/AMD or Arm 64-bit CPU, 1 GB of RAM and 1 GB of storage. But two lines in the Docker Compose file do all the architectural heavy lifting:

services:

  homey-shs:

    image: ghcr.io/athombv/homey-shs:latest

    container_name: homey-shs

    restart: unless-stopped

    network_mode: host

    privileged: true

    volumes:

      - ~/.homey-shs:/homey/user

network_mode: host and privileged: true — Homey wants to sit directly on the LAN with a dedicated IP address, because it relies on mDNS multicast for device discovery, and it wants near-unrestricted access to the host kernel. Athom explicitly notes that virtual machines should use bridged networking so the server is reachable on the LAN. The server listens on four ports: 4859 (HTTP + Socket.io), 4860 (HTTPS + Socket.io), and 4861/4862 for the Homey Bridge server (v1/v2). All persistent state lives in a single volume.

Keep those two Compose lines in mind — they decide the placement discussion below almost on their own.

The recommended option: a small Linux VM in a workload domain

This is by far the most practical route in VCF 9.1, and it takes about fifteen minutes:

1. Deploy a small VM (Ubuntu or Debian, 2 vCPU, 2 GB RAM, 20 GB disk is plenty) on an NSX segment — overlay or VLAN-backed — that has Layer 2 reachability to your IoT and smart home devices. mDNS discovery works within the subnet, so placement on the right segment matters more than sizing.
2. Install Docker and start the container with the Compose file above (docker compose -f homey-shs.yml up --detach).
3. Open ports 4859–4862 in the NSX distributed firewall (and gateway firewall if applicable), then pair the server with your Athom account via my.homey.app.
4. For Zigbee, Z-Wave and Thread you need radios. The clean way in a virtual environment is a Homey Bridge on the network, which talks to the server over ports 4861/4862. The alternative — a USB dongle with ESXi USB passthrough — works, but pins the VM to a host and breaks vMotion and DRS, which defeats much of the purpose of running it on VCF in the first place.
5. Put the ~/.homey-shs volume in your backup scope, or simply protect the whole VM with your VADP-based backup product. That one directory holds the entire configuration.

The Kubernetes option: VKS

Could you run this on a vSphere Kubernetes Service cluster instead? Technically, yes. VKS worker nodes are ordinary Linux VMs with a full kernel, so a pod with hostNetwork: true and privileged: true, plus a PersistentVolumeClaim through the vSAN CSI driver, will run fine. But you gain very little: Homey is a single-instance stateful appliance, it would share the node’s IP address, and mDNS discovery becomes harder to reason about. Kubernetes adds operational surface without adding value here. If you already run everything on VKS as a matter of principle, it works — otherwise, keep it simple.

Why vSphere Pods are off the table

The Supervisor’s native vSphere Pods might seem like the elegant answer — no VM to manage, no VKS cluster to maintain. But privileged containers and vSphere Pods fundamentally don’t mix, and it is worth understanding why.

On regular Kubernetes, a pod runs as a set of processes on a node: a Linux machine with one kernel shared by dozens of pods. privileged: true means “give this container near-total access to that node kernel” — all capabilities, direct access to /dev, the ability to load kernel modules and manipulate the host network stack, with seccomp and AppArmor out of the way. That is exactly what Homey uses (together with host networking) to sit directly on the LAN.

A vSphere Pod works fundamentally differently. The Supervisor runs every pod through the CRX runtime as its own stripped-down virtual machine directly on ESXi, with a dedicated, slimmed Photon kernel per pod. There is no shared node kernel to get privileged access to — the “host” is the ESXi hypervisor itself, and that is deliberately never exposed to a workload. This is precisely the selling point of vSphere Pods: VM-grade isolation for every single pod. Allowing privileged access would break that security model, so the Supervisor simply doesn’t support it.

For the same reason, every pod spec that refers to a “node” is unavailable:

• hostNetwork — there is no host network stack to join; the pod’s vNIC attaches to an NSX segment
• hostPath volumes — there is no node filesystem
• hostPID and hostIPC — no shared process or IPC namespaces
• Device passthrough — no way to hand a USB Zigbee dongle to a CRX pod

Homey Self-Hosted Server asks for almost exactly the list of things vSphere Pods deliberately don’t offer. That is not a limitation to work around; it is two security models that point in opposite directions.

Conclusion

VCF 9.1 gives you three ways to run containers, and this workload sorts them out neatly. vSphere Pods are excluded by design — their per-pod micro-VM isolation is incompatible with a privileged, host-networked container. VKS can do it, but brings Kubernetes overhead to a single-instance appliance that doesn’t benefit from it. A small Ubuntu VM on the right NSX segment, running Docker with the official Compose file, gets you a fully supported Homey server with vMotion, DRS, HA and your regular backup tooling — exactly the qualities you run VCF for.

The cornerstone of the VMware Cloud Foundation curriculum is getting its 9.1 refresh: VMware Cloud Foundation: Build, Manage, Secure [v9.1] is about to be released. I've been reviewing the course materials, and this five-day, hands-on training remains the definitive starting point for anyone who needs to design, deploy, and run a VCF private cloud — and the natural entry point into the rest of the 9.1 curriculum.

What the course is about

VMware Cloud Foundation delivers public cloud scale and agility with on-premises security, resilience, and performance. This course takes you through the complete lifecycle of a VCF 9.1 private cloud: planning and preparing the deployment, bringing up the environment with the VCF Installer, performing post-deployment tasks, and then managing the platform day to day — fleet management, workload domains, networking, storage, certificates, lifecycle management, and security.

The management experience is built around VCF Operations throughout. From navigating the redesigned console and verifying its integration with the management domain, to licensing, identity, password management, and security posture — you learn to run the fleet the way it is actually operated in 9.1.

Course outline

Twelve modules over five days:

1. Course Introduction
2. VCF Private Cloud: Overview and Architecture
3. VCF Private Cloud Deployment
4. VCF Post-Deployment Tasks
5. VCF Fleet Management
6. VCF Workload Domain
7. VCF Networking
8. VCF Storage Management
9. VCF Certificate Management
10. VCF Life Cycle Management
11. VCF Security
12. VCF Upgrade Paths

Thirty-one hands-on labs

The lab kit follows the lecture flow with 31 exercises, a mix of live labs and guided simulations. You deploy VCF with the Quick Installer, manage the environment through the VCF Operations UI, deploy the VCF Operations for Logs appliance, configure Single Sign-On and assign permissions to SSO users, and manage passwords across the fleet.

The workload domain module is particularly complete: commissioning hosts, creating a workload domain — including one without a vSphere cluster and one with the Supervisor — adding ESX hosts, assigning licenses, and importing an existing vCenter as a workload domain using VCF Operations.

A few more highlights:

• Modern VCF networking — the VPC consumption model with hands-on labs for configuring a Distributed Transit Gateway, creating distributed and centralized Virtual Private Clouds, deploying a VNA cluster with connectivity profiles, and building an Edge cluster with a Tier-0 gateway from vCenter.
• vSAN storage — reviewing the workload domain vSAN cluster, analyzing VM object and component placement, running vSAN health tests, and creating and applying storage policies.
• Platform operations — implementing certificates, configuring backups, and optional labs on the VCF APIs and SoS commands.
• Security and compliance — the integrated security features across all layers of VCF, and security management from VCF Operations.
• Upgrade paths — every supported route to 9.1, including vSphere 8.0 to VCF 9.1, vSphere with multiple Aria components, and VCF 5.x with multiple Aria components.

Who should attend

This course is aimed at administrators, engineers, and architects who are new to VMware Cloud Foundation or moving up to 9.1, with working experience of vSphere as the recommended starting point. It is also the prerequisite for the rest of the 9.1 curriculum — the What's New, Automate and Operate, and Troubleshooting courses all build on it — and it aligns with the upcoming VCP-VCF 9.1 Administrator certification.

Final thoughts

If you are building your VCF 9.1 skills from the ground up, this is the course to start with. It covers the full journey from bare hosts to a secured, workload-ready private cloud, and the 31 labs make sure you have actually done everything you have learned. The course will be released shortly through Learning@Broadcom — keep an eye on this blog for scheduling details.

Broadcom is about to release a brand-new edition of the VMware Cloud Foundation: Troubleshooting course, fully updated for VCF 9.1. I recently got a first look at the course material, and this five-day, hands-on training is shaping up to be an essential deep dive for anyone who operates and supports a VCF private cloud.

Why this course matters

VMware Cloud Foundation brings compute, storage, networking, automation, and operations together in a single platform — which is great, until something breaks. Misconfigurations and system failures can surface anywhere in the stack, from the initial bring-up to day-2 lifecycle operations. This course teaches administrators a structured approach to isolating and resolving problems across the entire VCF fleet, using the tools built into the platform itself.

What's new in the 9.1 edition

Compared to the 9.0 course, two things immediately stand out. The course now opens with a dedicated module on Monitoring and Troubleshooting with VCF Operations, including the Troubleshooting Workbench with its real-time analysis tools and log management. And at the other end of the week, there is a completely new module on Troubleshooting vSphere Kubernetes Service (VKS), covering the vSphere Supervisor architecture and troubleshooting VKS cluster deployments with logs and health checks — a welcome addition now that Kubernetes is a first-class citizen in VCF.

The upgrade module has also been reworked around real-world 9.1 scenarios, such as upgrading from vSphere 8 to VCF 9.1 and moving a VCF environment with multiple Aria components to 9.1.

Course outline

The course spans twelve modules over five days:

1. Course Introduction
2. Monitoring and Troubleshooting with VCF Operations
3. Troubleshooting New Deployment
4. Troubleshooting Upgrades
5. Troubleshooting License Management
6. Workload Domain Troubleshooting
7. Troubleshooting VCF Compute
8. Troubleshooting VCF Networking
9. Troubleshooting VCF Storage
10. Troubleshooting Using VCF Operations Fleet Management
11. Troubleshooting VCF Automation
12. Troubleshooting vSphere Kubernetes Service

Hands-on from day one

This is not a slideware-only course. Thirteen lab exercises run throughout the week, and they mirror what you actually face in production: analyzing SDDC Manager pre-check errors during a management domain upgrade, reviewing post-deployment logs, working with the VCF APIs, troubleshooting compute, networking, and vSAN issues, running vSAN health tests, fixing certificate and password management problems through Fleet Management, and diagnosing VCF Automation platform failures.

A few highlights from the content itself:

• VCF Operations as the starting point — fleet visibility monitoring, the Troubleshooting Workbench, and log analysis form the foundation for everything that follows.
• Deep networking coverage — from NSX management cluster status and Edge node validation to live traffic analysis, routing validation, and the new Virtual Network Appliance.
• Storage troubleshooting — monitoring vSAN through the UI and digging deeper with CLI tools.
• Fleet Management — certificates, passwords, identity and access management, tags, and configuration drift remediation using vCenter configuration profiles.
• VCF Automation — clustered deployment architecture and troubleshooting the automation platform, including microservice pod execution anomalies using container log architectures.

Who should attend

The course is aimed at administrators and support engineers responsible for a VCF 9.1 environment. You'll get the most out of it if you've already followed VCF: Build, Manage, Secure [v9.1] or have equivalent hands-on experience. It also aligns with the upcoming VCP-VCF 9.1 Support certification, making it a logical preparation step.

Final thoughts

Troubleshooting skills are what separate an administrator who can operate a platform from one who can keep it running when things go wrong. With the added coverage of VCF Operations, the Troubleshooting Workbench, and vSphere Kubernetes Service, the 9.1 edition reflects how troubleshooting in a modern VCF environment actually works today. Keep an eye on the course catalog — this one is worth booking as soon as it becomes available.