VMware VCP-VCF: Cloud Foundation Architect Study Guide
The VMware VCP-VCF: Cloud Foundation Architect exam validates the ability to translate business and technical requirements into a complete VMware Cloud Foundation design, covering topology choices, NSX and vSAN design, and design for availability, recovery, security, and lifecycle. It is aimed at solution architects and senior engineers who make design decisions rather than perform hands-on administration. Expect scenario questions that ask you to classify requirements, justify topology and component choices, and reason about trade-offs against constraints.
Reviewed Jul 2026.
Domain 1: VCF design principles and requirements gathering
- An assumption is a statement the architect believes true for planning but has not had formally confirmed; if later invalidated, it forces re-evaluation of every design decision that depended on it.
- A requirement is a stated need the design must satisfy, while a constraint is a pre-existing limitation (existing hardware, budget, timeline, rack space) that narrows the set of viable design choices.
- A dependency is a task or deliverable owed by another party that must be completed before the design can proceed, such as DNS, NTP, or an NFS export being available before bring-up.
- Requirements split into functional (what the system does) and non-functional quality attributes; an explicit uptime target is a non-functional requirement and a mandated logging or retention capability is a compliance-driven non-functional requirement.
- Distinguish business outcomes (cost reduction, time-to-market) from technical or project requirements (migration scope, NSX Federation), because they are captured and validated differently.
- Conceptual design deliverables are high-level, vendor-neutral diagrams showing major building blocks such as the management domain and VI workload domains and how they relate, without specific hardware or configuration values.
- Effective requirements gathering engages the right stakeholders: network operations staff define physical network constraints, and business unit owners articulate uptime, cost, and priority expectations.
- Mapping each requirement to a specific design decision creates traceability, so coverage can be verified and the design validated against original needs.
- Hardware must be validated against the VMware Compatibility Guide and the specific ESXi build in the target Bill of Materials (BOM) before it is committed to the design.
- The VCF subscription edition determines which Aria Suite entitlements are included, so licensing constrains which management capabilities can be designed in.
- Limited initial host availability, where management and workload must share the first cluster, favors the consolidated architecture as a starting point.
- A vSAN stretched cluster requires a witness at an independent third location; with no customer-owned third site, the witness appliance is hosted externally in a cloud or colocation facility.
- Foundational design facts: the management domain always has a dedicated NSX instance, principal storage is the primary shared storage set at cluster creation, and hosts must be commissioned into SDDC Manager before assignment to a domain.
- VCF's core value is automated, validated, full-stack deployment and lifecycle management driven by a BOM, rather than piecing components together manually.
Domain 2: Consolidated vs standard topology and multi-domain design
- A VCF instance is bounded by exactly one SDDC Manager plus the management domain it creates and zero or more VI workload domains it commissions; that SDDC Manager boundary, not physical location, defines the instance and is the exclusive lifecycle authority.
- The consolidated architecture runs management and workloads together in a single cluster, while the standard architecture separates management and workloads into distinct domains.
- Approaching the supported cluster scale ceiling is a clear trigger to expand from consolidated to standard architecture by commissioning hosts and creating a dedicated VI workload domain.
- A vCenter Server and its version are shared by every cluster in a VI workload domain, so independent vCenter upgrade timing and full RBAC or administrative separation require separate workload domains.
- A dedicated VI workload domain provides full compute, storage, and management-plane isolation, which is what compliance boundaries typically demand.
- A dedicated NSX instance for a workload domain is justified when it needs an independent upgrade schedule or strict, policy-driven tenant network segregation.
- Correct N+1 sizing means the surviving hosts retain enough reserved capacity, enforced by HA admission control, to restart affected VMs while vSAN resyncs components back to policy compliance.
- For a 4-host cluster sized N+1, losing one host still leaves 3 hosts, meeting the vSAN minimum for FTT=1, while reservations cover the HA restarts.
- Application Virtual Networks (AVNs) are NSX overlay-backed segments that give management applications like Aria Suite a portable networking layer decoupled from physical network changes.
- A stretched cluster only delivers site resiliency when the two sites have independent power, cooling, and connectivity; shared facility infrastructure defeats the purpose, and unsuitable network links or the absence of a cross-site failover requirement justify a standard cluster instead.
- Scaling capacity is done by incrementally commissioning hosts into an existing cluster, or by adding a new cluster in the workload domain when a single cluster's host limit or distinct cluster-level policies are reached.
- Cross-instance workload mobility uses HCX, while a shared SSO domain simplifies moves within an instance; retaining an IP address across instances requires Layer 2 network extension.
- Core infrastructure services such as DNS, NTP, and Active Directory can be centralized across independent VCF instances even when the instances remain otherwise separate.
- Stretching a management domain across distant regions increases blast radius and usually violates inter-site latency limits, so extending any domain to a remote site depends on meeting latency and bandwidth requirements.
Domain 3: NSX overlay and network design within VCF
- The recommended multi-rack underlay uses routed access with per-rack VLANs and subnets and BGP between leaf and spine, rather than stretching the same Layer 2 VLANs across racks, improving scalability and fault isolation.
- The underlay must provide a consistent 9000-byte MTU across fabric, distributed switch, and host TEP interfaces to absorb Geneve encapsulation overhead, plus redundant top-of-rack switches so each host has uplinks to two separate ToR switches.
- AVN segments attach to a Tier-1 gateway that uplinks to a Tier-0 gateway; the Tier-0 is where NSX peers with the physical fabric via dynamic routing.
- NSX overlay-backed AVN segments fully support vMotion between hosts and clusters sharing the transport zone without the segment existing as a VLAN on the physical network, so VLAN backing is not required.
- VCF creates two AVN segments, a region-specific segment and a cross-region segment, and their routed subnets must be unique and advertised via dynamic routing, requiring coordination with the network team.
- A Tier-0 gateway runs its service router component on Edge nodes; a Tier-1 with no centralized services and no dedicated uplink runs fully distributed and needs no Edge node.
- NSX-prepared ESXi hosts and NSX Edge nodes both function as transport nodes, but Edge nodes are configured individually or through edge cluster workflows because transport node profiles apply only to host clusters.
- Edge form factors and sizing: Medium and Large are valid Edge VM sizes, while bare-metal Edge nodes best fit extreme-scale throughput and stateful service demands.
- TEP behavior follows teaming policy: Failover Order with a single active uplink typically yields one host TEP, while Load Balance Source typically creates one TEP per active uplink.
- The NSX Manager cluster uses three nodes so a majority quorum can always be determined after a single node failure, avoiding split-brain.
- NSX Failure Domains let architects group Edge nodes by fault boundary to guide HA placement, and after a static-routing failover the newly active Edge sends Gratuitous ARP to redirect traffic.
- A single converged VDS across management and overlay traffic simplifies switch lifecycle and operations in VCF.
- NSX documents a maximum of 10 Edge nodes per Edge cluster, which bounds how much stateful service capacity a single cluster can host.
- Clustering protects the control plane but not data, so scheduled remote backups of NSX Manager are still required to guard against data loss that clustering alone cannot prevent.
Domain 4: vSAN design (ESA vs OSA, availability zones)
- vSAN ESA uses always-on, adaptive, per-object inline compression with minimal performance impact, whereas OSA offers compression only bundled with an optional deduplication toggle enabled as a single cluster-wide setting.
- OSA deduplication and compression require an all-flash cluster, add CPU overhead, are scoped per disk group but toggled cluster-wide, and cannot be set per VM.
- Valid reasons to select OSA over ESA include reusing OSA-certified hardware and wanting classic dedup and compression; the device HCL certification for the specific architecture ultimately drives the choice.
- In OSA a host supports up to 5 disk groups, each with one cache device and up to 7 capacity devices, for a theoretical maximum of 35 capacity devices per host.
- OSA RAID-5 erasure coding requires at least 4 hosts, all-flash disk groups, and FTT=1, while RAID-6 (4+2) carries roughly 50 percent capacity overhead.
- ESA's log-structured design narrows the historical performance gap between erasure coding and mirroring, making space-efficient RAID more viable for demanding workloads.
- FTT=0 provides no vSAN-level protection and suits only easily rebuilt, non-critical data or workloads that already achieve redundancy at a higher layer.
- A live storage policy change temporarily needs extra free (slack) capacity because vSAN builds the new components before removing the old ones, so both representations coexist during the transition.
- Stretched cluster limits: up to 20 hosts per data site and 40 total, plus a separate dedicated witness that stores only metadata and cannot host other VMs.
- Stretched cluster latency: the inter-site data link must stay within 5 ms RTT, while the witness link tolerates up to 200 ms RTT because it is off the active I/O path.
- vSAN network design uses Layer 2 within a site and either Layer 2 or Layer 3 between sites; hybrid vSAN is supported down to 1 GbE though higher is recommended.
- Data services ordering matters: deduplication and compression must run before encryption to remain effective, since encrypted data does not compress well.
- Networking best practices include a dedicated vSAN VMkernel adapter and Load Based Teaming to make effective use of both vSAN uplinks.
- Storage policy design balances availability requirements, host count, and the capacity-versus-performance trade-off, and note that cache device usable capacity per disk group has historically been capped so oversizing cache does not necessarily help.
Domain 5: Availability, recovery, and security design
- RPO (data loss tolerance) is driven by whether inter-site bandwidth and latency can keep pace with the data change rate; a data-loss-tolerance statement is an RPO requirement.
- Meeting a near-zero RTO requires reserved standby compute and storage at the recovery site, automated and tested recovery plans, and pre-validated network mappings so failover does not stall.
- Ranking recovery approaches: a stretched cluster with automatic failover gives the lowest RPO and RTO, frequent asynchronous replication achieves a lower RPO than nightly backup, and backup-only recovery has the longest RTO.
- Full management domain recovery relies on coordinated backups of vCenter, NSX Manager, and SDDC Manager together, since no single one restores the whole management plane.
- vCenter Server file-based backup and restore is configured through the Appliance Management Interface (VAMI) on port 5480, independently of the SDDC Manager backup mechanism.
- Proactive HA works with DRS to evacuate VMs from a host that the server vendor's hardware health provider reports as degraded, so the host can be remediated before it actually fails.
- vSphere HA isolation response must still be set deliberately even with redundant networking, because the response defines VM behavior when a host declares itself isolated.
- Encrypted vMotion generates a unique per-operation key to protect VM memory and device state in transit, independent of whether the VM's disks are encrypted at rest.
- Encryption layers differ: vSAN at-rest encryption operates at the datastore layer below the virtual disk, VM encryption operates per VM, and vSAN data-in-transit encryption protects host-to-host traffic and does not depend on a KMS.
- AES-NI capable and enabled CPUs are the key hardware prerequisite for efficient encryption performance across these features.
- Key management options: the Native Key Provider is built into vCenter and needs no external KMS, while centralized key management across multiple vCenter Servers requires registering the same external KMS cluster on each.
- Micro-segmentation contains lateral movement and enables IP-independent, workload-level security policy that follows the workload regardless of network location.
- Consistent NTP time synchronization is foundational for a correlated, trustworthy audit trail across all components.
- Certificates with shorter default validity require more frequent rotation, so designs must include proactive expiration monitoring, alerting, and a documented rotation cadence; Workspace ONE Access can be clustered and load-balanced to remove a single point of failure and can chain RADIUS to an existing RSA SecurID deployment, and where a hardening (STIG) control conflicts with required functionality the exception is documented formally with compensating controls applied.
Domain 6: Lifecycle, monitoring, and capacity design
- Air-gapped or dark-site designs download bundles on an internet-connected system and import them into SDDC Manager through the offline manual bundle upload workflow, preserving BOM-driven orchestration.
- Upgrade planning must validate version skew and interoperability: skip-level upgrades are not assumed supported and must be explicitly validated, and the witness appliance version is coordinated separately from host upgrades.
- Component compatibility is confirmed against the VMware Interoperability Matrix and the target BOM, and for Aria the Aria Suite Lifecycle version support must also be validated.
- Aria Operations HA requires a minimum of 3 analytics cluster nodes (master, master replica, and one data node) so the cluster tolerates the loss of one node without losing data or login access.
- A remote collector group provides redundancy for site-local data collection, keeping monitoring continuous when a collector fails.
- SLA-driven alerting is built from notification rules, group-based policies, and tuned symptoms; severity-based routing (paging or webhook for Critical, digest email for Warning and Info) reduces alert fatigue while preserving SLA response.
- Meeting a tight notification SLA requires an outbound integration such as ServiceNow tied to a notification rule that filters on the relevant alert definitions and severities.
- The monitoring stack is complementary: Aria Operations covers metrics, Aria Operations for Logs covers logs, and Aria Operations for Networks adds flow-based network visibility.
- Widespread high CPU ready time across a cluster signals a genuine capacity shortfall, so the durable fix is adding hosts or compute capacity rather than only reprioritizing existing resources.
- Resource controls behave distinctly: reservations guarantee a minimum allocation under contention, while lower shares and limits on non-production VMs protect production workloads when resources are contended.
- Capacity for FTT=1 with RAID-1 mirroring requires 2x the usable capacity in raw, so 100 TB usable needs 200 TB raw before slack space.
- Stretched clusters must reserve roughly half of total capacity so a full site failover can run the entire workload on the surviving site.
- Achieving full management-plane isolation and staying within cluster-count limits are the design drivers that justify creating a new VI workload domain.
- Keeping Aria Operations available throughout a change window preserves visibility, and Continuous Availability using fault domains and a witness node improves resilience during upgrades.
VMware VCP-VCF exam tips
- Sort every scenario item into assumption, constraint, requirement, or dependency first; the question often hinges on which category a given statement belongs to.
- When a scenario mentions independent upgrade timing, RBAC separation, or a compliance boundary, the answer is almost always a separate VI workload domain, because vCenter and often NSX are shared within a domain.
- Memorize the stretched cluster numbers: 5 ms RTT between data sites, up to 200 ms RTT to the witness, 20 hosts per site and 40 total, and reserve about 50 percent capacity for failover.
- Know ESA versus OSA cold: ESA compression is always-on and inline, OSA bundles dedup with compression as an all-flash cluster-wide toggle, and the HCL certification for the architecture decides the choice.
- For availability and recovery questions, rank the options by RPO and RTO: stretched cluster with automatic failover is lowest, async replication is middle, and backup-only recovery is highest.
Study guide FAQ
What is the difference between the consolidated and standard architectures in VCF?
The consolidated architecture runs management and workloads in a single shared cluster and suits limited initial hardware, while the standard architecture separates them into distinct domains. You expand from consolidated to standard by commissioning hosts and creating a dedicated VI workload domain, typically when the shared cluster approaches its scale ceiling.
When should an architect create a dedicated NSX instance for a workload domain?
A dedicated NSX instance is justified when a workload domain needs an independent upgrade schedule or strict, policy-driven tenant network segregation. The management domain always has its own dedicated NSX instance that is never shared with a VI workload domain.
How do you size a cluster for N+1 availability with vSAN?
N+1 means that after losing one host the surviving hosts still meet the vSAN host minimum for the storage policy (for example 3 hosts for FTT=1) and that HA admission control reserves enough compute and memory to restart the affected VMs while vSAN resyncs components back to compliance.
Is this exam hands-on or design-focused?
It is design-focused. Questions test your ability to gather and classify requirements, choose topologies, and justify NSX, vSAN, availability, recovery, security, and lifecycle design decisions against constraints, rather than testing configuration steps or administration tasks.