A Practitioner’s Guide
While preparing for the VCP-VCF Administrator exam, I put together this guide for myself — and figured it might be useful to share with others going down the same path. It covers all eight objectives in the blueprint, built from the official VCF 9.0 documentation and training materials. The focus is on the concepts, workflows, dependencies, and decision patterns that actually matter when you’re building and running a VCF private cloud — not just memorizing component names.
Exam snapshot: 60 questions · 135 minutes · Pass score 300 (scaled) · Based on VCF 9.0 · Delivered via Pearson VUE.
What This Guide Covers
Each objective follows the same rhythm: what the documentation emphasizes, the core concepts and workflows you need to understand, where common misconceptions arise, and how experienced administrators think about each topic. The underlying principle is operating-model judgment — VCF topics become clear once you identify which layer a given scenario belongs to: infrastructure preparation, platform deployment, domain design, day-2 management, operational visibility, or tenant consumption.
Table of Contents
Section 2 — VCF Fundamentals
- Private Cloud Vision
- VMware Compute Fundamentals
- VMware Storage Fundamentals
- VMware Network Fundamentals
Section 4 — Deploy, Configure & Operate VCF
2.1 Private Cloud Vision
Topics covered: Describe the principles of private cloud, identify private-cloud use cases, and explain the value proposition of private cloud in the VMware Cloud Foundation model.
What the Documentation Actually Emphasizes
VMware Cloud Foundation is presented as a private-cloud platform, not as a loose bundle of infrastructure products. The platform model matters because the value proposition combines compute, storage, networking, security, operations, automation, and consumption in a single operating framework. Training materials repeatedly frame modern private cloud around three pillars: modern infrastructure, a unified cloud experience, and a secure, resilient platform.
What That Means in Practice
Private-cloud vision topics really ask whether you understand cloud-like outcomes on-premises: self-service consumption, standardized lifecycle operations, governance, isolation between organizations or tenants, and consistent controls across virtual machines, containerized applications, and Kubernetes-based services. When the documentation discusses agility, Day 0/1/2 automation, or cyber resilience, it is defining the operating model that VCF is meant to provide.
VCF 9.0 expands this vision concretely: it treats servers, storage, and networks as fluid software pools of resources; gives developers self-service APIs instead of ticket queues; runs VMs, containers, and emerging AI services side-by-side as first-class citizens; extends consistently from core to edge to sovereign facilities; and bakes in audit-ready security with compliance guardrails that follow the workload.
⚠ Common misconception It is tempting to reduce VCF to “vSphere plus vSAN plus NSX.” The product set is part of the story, but the platform concept is broader. A complete understanding of VCF private cloud must include automation, governance, security posture, and consumption — not just the infrastructure components underneath. If your mental model stops at the component list, it is incomplete.
🔑 What to remember The strongest framing describes the platform as a whole: cloud-like experience on premises, faster delivery of services, stronger control over compliance and security, support for both traditional and modern workloads, and a more consistent operating model than ad-hoc virtualization estates. Lead with operating model and value — self-service, governance, resilience, automation — not component names.
2.2 VMware Compute Fundamentals
Topics covered: Deploy and configure VCF compute components (vCenter and ESX), configure a vSphere cluster, deploy and configure virtual machines, and manage virtual machines through vCenter.
What the Documentation Actually Emphasizes
This objective is grounded in vSphere fundamentals, but the documentation frames them within the VCF lifecycle. Administrators are expected to understand the roles of ESX hosts and vCenter Server, how clusters are formed, and how virtual machines are provisioned and managed. At the same time, the VCF deployment material assumes that some compute tasks occur before the VCF platform stack is deployed, and others occur after it.
Think in Layers
| Layer | Scope | Example Tasks |
|---|---|---|
| 1. Host Installation | ESX readiness | Install from ISO, root password, management network, DNS/NTP via DCUI |
| 2. Cluster Admin | vCenter-driven | Create clusters, HA/DRS, cloning, templates, migration, snapshots, power ops |
| 3. VCF Orchestration | Platform services | Workload domains, SDDC Manager, lifecycle, Supervisor enablement |
Manual ESX Installation Flow
The documented sequence is straightforward: boot the host from installation media → move through the installer → select the target disk → set the root password → configure the management network and supporting host settings (DNS, NTP) through the console workflow. This matters because many scenarios try to mix hypervisor installation with later platform tasks. vCenter deployment, VCF Installer workflows, cluster design, and workload provisioning come later — they are not steps in the basic manual ESX installation flow.
vSphere 9.0 — Key Changes in VCF 9.0
- Host Profiles are deprecated — the recommended mechanism is now vSphere Configuration Profiles, which can also apply NSX Transport Node Profiles to clusters.
- Baseline-managed (VUM-based) clusters are not supported in vSphere 9 — clusters and hosts must use image-based lifecycle management.
- Live Patch is extended to more of the ESX image, including vmkernel and NSX components.
- Advanced NVMe Memory Tiering (GA in VCF 9.0): extend the memory pool with local NVMe devices as a second, lower-cost tier. Hot data stays in DRAM, cold pages move to NVMe.
- FDM VIB included in ESX image: vSphere HA deployment is significantly faster and more reliable — no more network-based VIB pushes.
- Fast Suspend-Resume (FSR) for vGPU VMs — previously ~42 seconds for two L40 GPUs, now ~2 seconds.
💡 Operating-model insight Many compute misunderstandings disappear once the three layers are kept separate. The objective is less interested in every single wizard screen than in whether you can distinguish host-level preparation from cluster-level administration and broader VCF orchestration.
2.3 VMware Storage Fundamentals
Topics covered: Configure vSphere storage, describe the use cases for vSAN ESA or vSAN OSA, deploy a vSAN cluster, configure vSAN storage policies, identify resilience and data-availability options, describe the purpose of vSAN space efficiency.
What the Documentation Actually Emphasizes
Storage topics in this blueprint are heavily policy-driven. VMware documentation consistently pushes administrators away from thinking only in terms of “which datastore” and toward the storage policy-based management (SPBM) model. In VCF, storage decisions are tied to workload-domain design, principal versus supplemental storage choices, and the policy-based expectations attached to virtual machine objects.
ESA vs OSA — Architecture Decision, Not Just Labels
You are expected to understand ESA and OSA as different architectural models rather than as interchangeable labels. The point is to connect the architecture to the intended use case rather than to memorize marketing language.
| Characteristic | vSAN ESA (Express Storage Architecture) | vSAN OSA (Original Storage Architecture) |
|---|---|---|
| Disk architecture | Single-tier storage pool — no cache/capacity split | Disk groups with dedicated cache devices |
| Hardware | NVMe-only — optimized for modern hardware | Supports SAS, SATA, NVMe — including spinning disks |
| Performance | Virtually all feature gaps have been eliminated as of vSAN in VCF 9.0 | Stable but limited by cache-tier architecture |
| Deduplication (VCF 9.0) | Global dedup — domain is entire cluster; post-process; 4KB granularity; minimal latency impact | Per-disk-group dedup — limited domain, inline destaging, can impact latency |
| Compression | No performance vs efficiency trade-off — always optimal | Compression can impact performance under heavy load |
| RAID | Adaptive erasure coding (RAID-5/6) with more flexibility | Traditional RAID-1/5/6 |
| Feature parity (VCF 9.0) | Virtually all feature gaps eliminated as of vSAN in VCF 9.0 | Fully mature feature set |
| Recommendation | Recommended for new deployments | Supported for existing environments and non-NVMe hardware |
Policies, Resilience, and Efficiency — Three Distinct Goals
The documentation treats these as different goals, and understanding that distinction is essential.
vSAN Policies (SPBM)
Policies express what level of protection, availability, and behavior an object should receive. Key settings: FTT (Failures to Tolerate), protection method (RAID-1 mirroring vs RAID-5/6 erasure coding), storage tier placement. The policy is attached to the VM object, not the datastore.
Resilience and Data Availability
Topics usually hinge on whether you understand failure tolerance, quorum-oriented thinking, and the relationship between policy settings and object placement. vSAN objects consist of components distributed across hosts — a quorum of components must be available for the object to remain accessible.
Space Efficiency
This is about reducing capacity consumption and improving economics, not about increasing resilience. Techniques include deduplication, compression, TRIM/UNMAP space reclamation, and thin provisioning. In VCF 9.0, vSAN ESA global deduplication spans the entire cluster instead of being limited to a per-disk-group domain, yielding dramatically higher data-reduction ratios.
🔑 Principal vs Supplemental Storage Principal storage is the foundational storage model for a domain (typically vSAN). Supplemental storage extends the design for additional use cases (NFS, vVols, VMFS on FC). Note: vVols is deprecated beginning with VCF 9.0 and will be fully disabled in a future 9.x release.
⚠ Key distinction Resilience and efficiency are separate goals with separate answers. “Increasing data protection” is about FTT and protection method (RAID-1 mirroring vs RAID-5/6 erasure coding). “Reducing storage costs” is about deduplication, compression, or erasure coding for space savings. The documentation treats these as distinct concerns, and understanding that separation is essential.
2.4 VMware Network Fundamentals
Topics covered: Differentiate between VCF networking components, configure virtual networking fabrics and features, configure connectivity and routing, configure virtual networking services.
What the Documentation Actually Emphasizes
This objective centers on understanding how VCF networking is built and consumed through NSX constructs. The documentation expects administrators to distinguish the transport/fabric layer from logical connectivity and from services. Fabric, routing, and network services are related, but they are not interchangeable ideas.
Mental Model: Four Layers
| Layer | What It Does | NSX Components |
|---|---|---|
| Fabric (Transport) | Underlies everything — moves traffic between hosts | Transport Zones, Transport Nodes, N-VDS/VDS, TEP (Tunnel Endpoints) |
| Connectivity | Logical L2 networks — isolated overlay segments | Segments (overlay and VLAN-backed) |
| Routing | L3 routing between segments and the outside world | Tier-0 Gateway (north-south), Tier-1 Gateway (east-west), Edge Clusters |
| Services | Higher-layer network services | NAT, Load Balancing, Distributed/Gateway Firewall, DHCP, DNS, VPN |
NSX in VCF 9.0 — Critical Changes
- NSX is available exclusively as part of the VCF stack, starting with VCF 9.0 — standalone deployment or upgrade of NSX is not allowed.
- NSX Transport Node Profiles are applied using vSphere Configuration Profiles — the recommended configuration management mechanism for clusters.
- NSX VPC (Virtual Private Cloud) is a key construct for tenant networking in VCF Automation.
Networking Scope Changes in VCF
When the wording shifts to provider, organizational, regional, or VPC-level networking, the scope of the answer changes accordingly. Provider networking establishes shared connectivity foundations (Tier-0 Gateways, IP Spaces). Organizational/tenant networking exposes consumable networking within a tenant or organization context. VPCs provide isolated networking domains tied to namespaces.
⚠ Important distinction When deciding which component provides a given type of connectivity, pay attention to the layer. A segment provides L2 connectivity — it connects workloads within the same broadcast domain. A gateway provides L3 routing — it moves traffic between segments or toward external networks. Services like NAT, load balancing, and firewalling operate on top of the routing layer. A north-south traffic scenario requires a gateway and typically an edge cluster, not a segment.
💡 Article takeaway Use clean network vocabulary: fabric, connectivity, routing, and services each describe a different part of the design. If the wording shifts to provider, organization, regional, or VPC-level networking — the scope of the correct answer shifts with it.
4.1 VCF: Deploy and Configure
Topics covered: Identify deployment components and models, describe deployment of a VCF-based private cloud, identify additional required components, describe deployment of a VCF network gateway and VCF networking, deploy a workload domain, configure workload-domain storage, configure Supervisor within a workload domain.
What the Documentation Actually Emphasizes
This is one of the most important objectives because it combines architecture decisions with operational sequencing. The deployment documentation expects administrators to recognize which components belong to a VCF deployment, how deployment models differ, and what prerequisites must be satisfied before domain creation, networking, or Supervisor enablement can succeed.
Deployment Models
The design and deployment materials draw clear distinctions between:
- Minimal footprint — consolidated management infrastructure, fewer hosts
- Standard single-site — dedicated management resources
- Multi-site / high-availability / regional models — broader resilience and scale
These distinctions show how component placement, resilience expectations, and operational scale affect the choice of deployment.
Deployment Sequence — The Core Principle
The right deployment explanation usually respects the sequence and prerequisites.
Prerequisites (DNS, NTP, network, passwords, HW compat) → VCF Installer (validate + deploy mgmt domain) → Post-Deploy (additional clusters, WLD domains) → Networking (edge clusters, gateways) → Supervisor (requires domain + net + storage) → Automation (regions, orgs, consumption)
Management Domain vs Workload Domain
The documentation places strong emphasis on the domain boundary. The management domain hosts VCF management components (SDDC Manager, vCenter, NSX Manager, VCF Operations). Workload domains serve tenant/customer workloads. Administrators need to understand how compute, networking, and storage are attached to a workload domain.
Minimum host counts: 4 hosts for the management domain, 3 hosts for the VI workload domain (vSAN), 2 hosts for the workload domain with NFS/FC. Remote clusters: min 3 (vSAN) or min 2 (NFS/vVols/FC), max 4.
Import vs Net-New — Two Different Workflows
What changes when an existing vCenter environment is imported instead of a new domain being deployed from scratch? Many misunderstandings come from mixing those two workflows. Importing requires readiness checks on the existing environment. Net-new domains are deployed from zero by the SDDC Manager. The readiness path is fundamentally different.
Supervisor Dependencies
Supervisor is not treated as a simple add-on. The documented workflow assumes that the underlying workload domain, networking (NSX with edge cluster, VPC, or segments), and storage prerequisites are already in place before Supervisor is enabled. The same logic applies to network-gateway and provider-networking topics: the gateway model is part of a dependency chain, not a standalone toggle.
⚠ Important nuances Minimal-footprint is a valid starting point but does not automatically represent the recommended long-term architecture. Imported environments follow a different readiness path than net-new domains — the prerequisites and validation steps differ significantly. Supervisor enablement depends on networking and storage being fully configured first; without that foundation, enablement will fail. Understanding these dependency chains is what separates surface-level knowledge from real operational competence.
💡 Article takeaway Sequence matters: prerequisites first, platform deployment second, domain and service enablement after readiness is established. Every correct deployment answer respects that order.
4.2 VCF: Manage
Topics covered: Differentiate fleet-management capabilities, configure identity management and RBAC, configure licensing, certificates, and passwords, identify tasks required to import an existing vCenter, and manage the lifecycle of VCF.
What the Documentation Actually Emphasizes
This objective is about day-2 administration of the platform rather than raw deployment. The materials emphasize centralized lifecycle workflows, identity integration, role-based access, credential handling, licensing visibility, and certificate consistency across managed components.
Identity, RBAC, and Scope of Authority
Not every task belongs to the same administrative scope. Platform/provider-level roles have different authority than organization-level roles, and that distinction matters later in VCF Automation as well. Many management discussions focus on whether you can identify which role should perform a task, not simply on how the task is configured. VCF 9.0 introduces VCF Identity Broker for unified SSO across components — users authenticated through VCF can access integrated services (including HCX Manager) without re-authentication.
Certificates
The enterprise certificate lifecycle requires understanding the difference between self-signed and CA-signed approaches and why certificate replacement must remain aligned across platform components. The SDDC Manager coordinates certificate management for all managed components. The important thing to understand is the centralized model — not just how to replace a certificate on one component in isolation.
Passwords
Password management often hinges on synchronization logic. If a password changes in the target system but the platform is not updated, a consistency problem remains. The correct remediation is the documented password-management workflow (password rotation/remediation in SDDC Manager) — not an assumption that the platform automatically discovered the change.
Licensing
Licensing in modern VCF is treated as a managed platform concern, especially the distinction between connected (automatic validation with Broadcom) and disconnected environments. VCF Operations HCX 9.0 integrates licensing with VCF.
Fleet Management
VCF Operations provides Fleet Management capabilities to monitor and manage configuration drift, standardize host/cluster configurations, and track changes across the environment. Understanding the differences between these capabilities — and when to use each one — is a core competency for VCF administrators.
Lifecycle Management (LCM)
LCM is broader than a single upgrade action. It includes repository readiness, version compatibility, binary availability, and controlled sequencing of updates across components. SDDC Manager orchestrates the entire process. In VCF 9.0, maintenance releases are synchronized among components with a new Bill of Materials, and you can pick and choose which components to apply based on impact.
🔑 Core principle Many wrong explanations in this area sound plausible because they describe a local component task. The stronger answer is the one that reflects centralized platform management, consistent secrets and certificates, and the documented boundaries of administrative scope.
💡 Article takeaway Management topics are strongest when framed as centralized platform workflows, not disconnected local tasks. Whether the scenario involves password rotation, certificate renewal, or lifecycle updates — the answer almost always involves SDDC Manager as the coordinator.
4.3 VCF: Operations
Topics covered: Identify use cases for VCF Network Operations and VCF Operations (Logs), describe deployment options, differentiate metrics and properties, create views/reports/dashboards/alerts, monitor logs, health/diagnostics, networks, storage, applications, security hardening, compliance, and configuration drift.
What the Documentation Actually Emphasizes
Operations topics are really about choosing the right visibility and analysis tool for the problem at hand. VMware documentation separates core operations, analytics, log analytics, network operations, and storage-focused visibility because each addresses different types of questions.
Choose the Tool That Fits the Problem
| Problem Type | Correct Tool | What It Answers |
|---|---|---|
| Performance, capacity, object behavior over time | VCF Operations (analytics) | How much? How fast? How full? What trend? |
| Network visibility, flow analysis, and troubleshooting | VCF Operations for Logs | What happened? When? What triggered it? |
| Network visibility, flow analysis, troubleshooting | VCF Network Operations | Where does traffic flow? What’s blocking? |
| vSAN storage monitoring and troubleshooting | VCF Storage Operations | Disk health? Resync status? Capacity? |
| Platform health, component state | VCF Health and Diagnostics | Is the platform healthy? What’s degraded? |
| Benchmark, hardening, compliance, configuration drift | Configuration & Compliance | Does the config match the desired state? |
Metrics vs Properties — Classic Checkpoint
This distinction is fundamental to operations work and worth internalizing thoroughly.
🔑 Definitions Metrics are time-variant observations: CPU utilization, latency, throughput, IOPS. They have numeric values and timestamps — they change over time.
Properties are descriptive attributes of an object: hostname, firmware version, IP address, memory size. They are comparatively static — they don’t change every second.
When readers blur those concepts, they usually choose the wrong report, dashboard, or troubleshooting path.
Dashboards, Views, Reports, and Alerts — Not Synonyms
| Concept | Purpose | Key Characteristic |
|---|---|---|
| Dashboard | Live / near-live visualization | Operational awareness in real time |
| View | Curated presentation of selected data | Focused on specific object set |
| Report | Formal output for review or sharing | Periodic analysis, exportable |
| Alert | Ties symptoms, policies, and thresholds | Triggered notification |
The documentation consistently separates these concepts, and the strongest explanations preserve the distinction instead of treating them as synonyms.
VCF Operations 9.0 — Key Changes
- Integrated log management — explore logs, configure log-based alerts, and create log dashboards directly within VCF Operations UI (standalone VCF Operations for Logs UI remains for legacy/advanced functions).
- Centralized log collection — manage log collection for vCenter, ESX, VCF Operations from a single UI with pre-installed agents. Logs standardized to RFC 5424.
- The unified cloud proxy handles log forwarding (replacing previous log-forwarding-enabled proxies).
- Supervisor and VKS monitoring — native integration with automatic discovery of Supervisor and VKS clusters. Telegraf agent sends metrics to VCF Operations.
- vCenter linking — single-pane-of-glass view across up to 15 vCenter instances.
- Cost Management — new centralized Cost home page as a hub for all cost visualization.
Logs, Health, Compliance, and Drift
VCF Operations (Logs) is the right choice when the scenario involves events, log records, audit-style investigations, or troubleshooting after something happens. Core operations visibility is the right choice when the problem is performance, capacity, or object behavior over time. Health and diagnostics focus on the platform state. Configuration drift and compliance are another layer entirely — they address deviations from the desired or benchmarked configuration, not transient operational incidents.
💡 Decision rule Logs, audit trail, event history → log analytics Utilization, performance, capacity, policy-driven alerting → operations analytics Benchmark, hardening, compliance score, drift → configuration & compliance monitoring Network visibility, flow analysis → network operations
If it says “benchmark” or “hardening” or “drift” — think configuration and compliance, not a generic alert.
4.4 VCF: Consume and Automate
Topics covered: VCF Automation use cases, components and deployment options, regions, multi-organizational tenancy, provider networking, content libraries, organizational-administrator tasks, organizational networks, content management, extensibility, governance policies, Supervisor-based services.
What the Documentation Actually Emphasizes
This is the largest and most practical objective in the blueprint. The materials focus on how infrastructure becomes consumable: regions are established, organizations are defined, provider-level services and networking are prepared, content is published, and governance controls are applied so teams can safely consume virtual machines, Kubernetes resources, and application services.
Provider vs Organization — The Foundational Boundary
A major thread across the documentation is scope separation. Provider administrators prepare shared capabilities. Organization administrators consume within guardrails. This boundary is foundational to the VCF Automation operating model.
| Scope | Who | What They Do |
|---|---|---|
| Provider | IT Admin / Provider Admin | Creates regions, configures Provider Gateways + IP Spaces, defines VM/Storage Classes, publishes content libraries, establishes top-level governance |
| Organization | Org Admin / Tenant | Consumes resources within guardrails, creates VPCs + connectivity profiles, manages projects + namespaces, deploys VMs/containers, configures org-level policies |
VCF Automation Abstraction Hierarchy
Configuration order matters. The documented order of enablement is:
Region (Supervisors + Zones + NSX) → Provider GW (Tier-0 + IP Spaces) → Organization (Tenant boundary = NSX Project) → Regional Net (Transit GW, default VPC) → Quotas (CPU/mem/storage per region) → Projects (Users + namespaces)
Regions
A region combines compute, memory, storage, and networking resources from the underlying infrastructure. It groups one or more Supervisors and is associated with one NSX Manager instance. All Supervisors within a region must have homogeneous configurations — identical names and definitions for storage classes, VM classes. Provider Administrators commonly create regions that furnish different classes of service (performance, capacity, features). A Supervisor can only be associated with one region.
Provider Gateways and IP Spaces
A Provider Gateway maps to a Tier-0/VRF NSX Gateway. It requires at least one IP Space per region — essentially an NSX IP Block that is routed externally by the Provider Gateway (public internet IPs or intranet IPs for private cloud). IP Spaces are automatically subnetted and used by tenants for public networks, Source NAT, and Load Balancing VIPs. A Provider Gateway can be shared across organizations or dedicated to a particular one.
Organizations
An organization is a top-level entity used to group resources, users, policies, and catalog entities while maintaining a secure boundary from other organizations. A VCF Automation Organization maps to an NSX Project. Two types exist: All Apps (VM, Kubernetes, networking, volumes, Harbor, DNS, certificates, and AI workloads) and VM Apps (a transition path for existing VMware Aria Automation users).
Regional Networking for an Organization
When the provider configures regional networking for an organization, it specifies which Provider Gateway provides external connectivity and which Edge Cluster is used for Transit and VPC Gateways. This configuration automatically creates: an NSX Project, a Transit Gateway, a default VPC, a default connectivity profile, and an outbound SNAT rule. Note: in VCF Automation 9.0, only one regional networking configuration is done per tenant per region — they cannot connect to multiple Provider Gateways.
Region Quotas, Projects, and Namespaces
A region quota defines CPU, memory, and storage resources allocated to an organization for a given region. Resources within a quota can be further subdivided: Projects are logical representations of users and resource pools. Namespaces (vSphere Namespace) are resource pools assigned to projects with CPU/memory/storage controls. Each project can contain multiple namespaces.
Content Libraries and Governance
Content libraries host VM images. The model: the provider publishes shared content centrally; organizations can also create their own content. Governance policies (approval, day-2, lease, quotas) can be applied at the organization or project level.
Extensibility
Exists to connect automation workflows with business processes, events, and external systems. Enables event-driven automation around VM and resource lifecycles.
Supervisor-based Services
Administrators need to understand what these services are for, not every low-level implementation detail:
- VM Service — provision VMs through the Kubernetes API
- VKS (vSphere Kubernetes Service) — managed Kubernetes clusters
- vSphere Zones — distribute Supervisor resources across multiple clusters for HA
⚠ Separation of duties A solid understanding of VCF Automation requires keeping the provider and organization layers distinct. Provider administrators prepare the shared platform: regions, gateways, IP spaces, content libraries, top-level governance. Organization administrators consume within those guardrails: creating VPCs, managing projects, deploying workloads. If you collapse both into a single layer, the operating model stops making sense. Always ask: who owns this task? Provider Gateway configuration is always provider-scope. VPC creation is always organization-scope. Respecting that boundary — and the documented order of enablement — is the foundation.
💡 Article takeaway Think in order: region → tenancy → provider capabilities → organizational consumption → governance → service delivery. Consumption and automation become easier to explain when you preserve provider-versus-organization boundaries and the documented order of enablement.
How to Think About VMware Cloud Foundation
The most productive way to approach VCF is not as a collection of product facts, but as an operating model with clear layers. Topics become much more approachable once you identify which layer a given scenario belongs to:
| Layer | Core Focus Areas |
|---|---|
| Infrastructure preparation | ESX installation, networking, DNS/NTP, hardware readiness |
| Platform deployment | Workload domains, clusters, storage, and network topology |
| Domain design | Workload domains, clusters, storage, network topology |
| Day-2 management | LCM, certificates, passwords, RBAC, import workflows |
| Operational visibility | Metrics vs properties, dashboards vs reports, log analytics vs compliance |
| Tenant consumption | Regions, organizations, VPCs, governance, extensibility, Supervisor services |
This layered thinking is equally valuable for day-to-day architecture decisions and for certification preparation. Understand the platform model, preserve component boundaries, respect prerequisites, and explain each workflow the way the documentation explains it.
💡 Recommended learning path
- Internalize this guide — understand the structure, dependencies, and key distinctions
- Study official documentation: techdocs.broadcom.com — VCF 9.0 sections
- Complete recommended courses: VCF: Build, Manage, and Secure + VCF: Automation and Operations
- Use Hands-on Labs (HOL) for VCF 9.0 — hands-on practice in a live environment
- Read VCF 9.0 release notes — new features, deprecated features, removed features
- Review the VMware Private Cloud overview for vision/value-proposition grounding
- Focus on understanding why things work the way they do, not just what the components are — deep understanding transfers to both real-world operations and certification
VMware Cloud Foundation 9.0 Practitioner’s Guide — built from the official 2V0-17.25 blueprint, VCF 9.0 documentation (techdocs.broadcom.com), and VMware by Broadcom training materials. Content based on VCF 9.0, March 2026.