VMware VCAP-VCF: Cloud Foundation Design Study Guide
The VMware VCAP-VCF: Cloud Foundation Design exam validates senior, architect-level skill in designing software-defined data centers on VMware Cloud Foundation, covering logical and physical design of management and workload domains and advanced vSphere, vSAN, NSX, and Aria decisions. It is aimed at experienced solution architects and infrastructure designers who must justify every design decision against explicit requirements, constraints, assumptions, and risks. Expect scenario-driven questions that test not just product knowledge but the reasoning and trade-offs behind design qualities such as availability, manageability, performance, recoverability, and security.
Reviewed Jul 2026.
Domain 1: Requirements, constraints, assumptions, and risks
- Business drivers are the strategic motivations for a project, such as time to market (agility) or regulatory compliance; they explain why the initiative exists rather than prescribing a technical solution.
- A requirement is a stated, measurable need the design must satisfy; a constraint is an externally imposed limitation the design cannot change; an assumption is an unverified planning condition; and a risk is an uncertain future event with a negative impact.
- A measurable availability target (for example, a stated uptime percentage or the ability to survive a rack failure) is a requirement, not a constraint, and must be treated as something the design has to achieve.
- Functional requirements describe specific capabilities the solution must provide, such as self-service Kubernetes provisioning or Active Directory integration.
- An expectation formed from informal comments and not yet formally confirmed is an assumption, and it must be explicitly validated with the accountable stakeholder before dependent design decisions rely on it.
- Unvalidated assumptions must remain visible as tracked open items; if an assumption is later invalidated, every design decision that depended on it must be reassessed.
- Validating an assumption requires direct confirmation with the accountable party plus a tracked deadline, not silent acceptance into the design.
- A single requirement often fans out into several coordinated decisions; a rack-failure availability requirement can drive vSAN fault domains (storage), Edge distribution across racks (network), and host anti-affinity plus spare capacity (compute).
- Every design decision must carry a justification (the why, tracing back to a requirement) and an implication (the cost or consequence); a decision with no identifiable implication or no traceable justification signals incomplete analysis and should be reconsidered.
- Operational overhead is a consequence of a decision and belongs in the implication or risk field, not stated as a requirement.
- A recovery interval must be mathematically consistent with the stated objective; a 4-hour replication interval cannot meet a 5-minute RPO, so such a decision must be revised regardless of which tool orchestrates failover.
- The correct technical requirement ties a specific VCF capability to a measurable threshold under defined load rather than merely restating the business need in general terms.
- Risk mitigation must address the root cause; an inter-site bandwidth risk is mitigated by increasing validated bandwidth or reducing the workload footprint, not by tuning an unrelated setting.
- A direct conflict between a fixed constraint and a mandatory requirement cannot be resolved silently by the architect and must be escalated for a stakeholder decision; stakeholder walkthroughs also validate the conceptual model before deeper design begins.
Domain 2: Logical and physical design of management and workload domains
- Consolidated architecture runs management and tenant workloads on a single shared cluster with one vCenter Server and one NSX Manager, so every lifecycle operation touches both at once; standard architecture keeps a dedicated management domain plus separate VI workload domains, giving stronger isolation and independent lifecycle at the cost of more hardware.
- The management domain must exist and be fully deployed before any VI workload domain can be created.
- Compliance mandates for hard administrative separation, projected growth beyond a single cluster, and the need for independently scheduled patch or upgrade cadences all favor starting with standard architecture rather than consolidated.
- A shared NSX Manager control plane can serve multiple workload domains, but Edge node and gateway design still remains independent per workload domain; strong isolation requirements favor a dedicated NSX Manager instance.
- Clustered application node VMs should use anti-affinity rules to keep nodes on separate hosts, and the cluster needs at least one host more than the number of nodes so vSphere HA can still honor the rule after a host failure.
- Percentage-based admission control is the recommended default for most production clusters; it must reserve at least 1/N of cluster resources per tolerated host failure (rounded up), so reserving one of six hosts is about 16.7 percent and two of six is about 33.3 percent.
- One large cluster reserves a smaller percentage for the same absolute host-failure tolerance than several smaller clusters, but it increases the blast radius of a failure.
- vSAN FTT=1 with fault domains requires a minimum of 3 fault domains, mirroring the standard 3-host quorum rule (two data components plus one isolated witness).
- Sizing compute for HA means covering the surviving-host case; for example, 96 vCPUs at a 4:1 consolidation ratio needs 24 physical cores total, which across 3 surviving hosts is 8 cores per host.
- Configuration maximums are hard design limits; a single ESXi host supports up to 1024 VMs, so any design proposing more than that on one host is invalid, and a vLCM image applies uniformly to an entire cluster (hosts in one cluster cannot run different images).
- Latency-sensitive workloads should stay within a single domain in a single instance, while latency-tolerant workloads can consume spare capacity anywhere; exceeding vCenter Server's supported management latency threshold points toward a local workload domain rather than a remote cluster.
- EVC for future host refreshes should be set to the lowest CPU generation expected in the cluster, with a planned baseline raise once the oldest hosts are retired.
- Aria Operations supports a centralized analytics cluster with remote collector nodes deployed close to each remote data source, reducing WAN traffic and firewall exposure while preserving unified cross-domain analytics; the Aria Suite can also be placed in a dedicated VI workload domain to relieve capacity pressure.
- Physical design must validate firmware and driver choices against the VMware Compatibility Guide and the VCF Bill of Materials, and vCenter Server RBAC natively scopes permissions to specific inventory objects such as clusters or resource pools.
Domain 3: Advanced NSX overlay/underlay and multi-site design
- A leaf-spine (Clos) fabric connects every leaf to every spine in a full mesh, so adding spines increases aggregate bandwidth and redundancy; Layer 3 ECMP replaces spanning tree, letting all links carry traffic simultaneously.
- Geneve is the NSX overlay encapsulation; its key advantage over the older fixed-header VXLAN is an extensible, variable-length option header, and its transport uses the address family configured for the TEP/underlay (commonly IPv4), not a mandatory IPv6 header.
- Host transport nodes have only local TEPs for intra-location overlay traffic, while Remote Tunnel Endpoints (RTEPs) exist only on Edge transport nodes; therefore cross-location overlay traffic always transits Edge nodes and never flows directly host-to-host between sites.
- The NSX native Load Balancer attaches only to a Tier-1 gateway, never directly to Tier-0; adding a Load Balancer to a Tier-0-only topology requires inserting a Tier-1, which also forces that Tier-1 into Active-Standby mode.
- Tier-0 gateways can run Active-Active with ECMP for north-south scale-out and BGP peering, while Tier-1 centralized services always run Active-Standby with exactly one active Edge node regardless of span; VCF AVN bring-up deploys a two-tier topology with an Active-Active BGP Tier-0 above Tier-1s that host the AVN segments.
- North-south ECMP requires the Tier-0 to run active-active across at least two Edge nodes that peer to distinct top-of-rack switches, with each Edge uplink on its own dedicated uplink VLAN for redundant paths.
- A Failover Order teaming policy with one active and one standby uplink yields a single host TEP and no active load balancing; distributing Edge nodes across multiple racks prevents a single rack or ToR failure from removing all north-south connectivity.
- Multi-traffic-type host uplinks should use 802.1Q trunk ports that permit only the required VLANs, and Tier-0 external uplink segments are VLAN-backed and require a VLAN transport zone.
- NSX Federation splits control between a Global Manager and per-location Local Managers because Manager cluster consensus needs roughly 10 ms RTT between nodes; a 60 ms inter-site link breaks that, which is exactly why the GM/LM model exists.
- Only the active Global Manager accepts writes to global objects while the standby is read-only, and Federation region scopes are Global (all locations), Custom (an admin-defined subset), and the automatic per-Location region; no cluster- or availability-zone-scoped region exists.
- Scoping policies to Custom Regions instead of defaulting to a Global span, combined with change control, limits the blast radius of a badly authored centrally managed policy.
- Aligning the primary location across linked Tier-0 and Tier-1 gateways reduces traffic hairpinning across the inter-site link in a stretched design.
- A static IP Pool for TEPs gives predictable, NSX-tracked addressing that eases day-2 operations, and the pool must cover the current minimum of 2 TEPs per host across all hosts plus headroom for future host additions.
- A collapsed Edge and compute cluster is justified mainly for small or resource-constrained environments, while a dedicated Edge cluster is preferred for production where north-south performance isolation and independent scaling matter; NSX Edge Bridging extends Layer 2 between an overlay segment and a VLAN-backed network for migration or legacy integration.
Domain 4: vSAN advanced design (stretched clusters, ESA/OSA, fault domains)
- A vSAN cluster must be uniformly OSA or uniformly ESA, and this applies to both sites of a stretched cluster; the two architectures cannot be mixed within one cluster.
- vSAN ESA requires an all-NVMe storage pool where every device is a qualified NVMe device in any role; SAS or SATA SSDs cannot participate, even in a capacity-only role.
- The fault-domain minimum follows the 2 times FTT plus 1 rule: FTT=1 needs 3 fault domains and FTT=2 needs 5, so 3 racks cannot provide rack-level FTT=2 protection and would fall back to host-level fault domains.
- Provisioning one fault domain beyond the strict minimum preserves full rebuild and rebalance capability during a rack failure or maintenance without dropping below the policy minimum.
- RAID-1 FTT=1 mirroring stores two full object copies and roughly doubles raw capacity consumption, while RAID-6 uses a 4+2 data-plus-parity scheme requiring a minimum of 6 hosts.
- Erasure coding such as RAID-6 splits each object into more data and parity components than a RAID-1 mirror, so at very large object counts it can approach per-host component limits sooner than mirroring.
- In a stretched cluster the witness holds only metadata (witness components) and never VM data, and it must be placed at an independent third location; read locality serves reads from the local site copy, lowering inter-site bandwidth and bounding read latency by local storage performance.
- A synchronous stretched cluster requires 5 ms or less RTT between the two data sites, so a 12 ms link rules out a synchronous stretched design; direct back-to-back cabling is only viable for a single host per site (2-node) design.
- Stripe width distributes an object's data across additional disks to increase parallelism and throughput, but ESA's log-structured storage pool inherently stripes across all member disks, reducing the need for manual stripe-width tuning.
- OSA deduplication and compression requires all-flash, operates across the entire disk group as a single cluster-wide toggle, and is not a per-VM or per-VMDK policy setting.
- Operations reserve withholds capacity so internal operations like resync do not fill the cluster, and host rebuild reserve automatically sizes enough capacity to rebuild after a full host failure; both are cluster-level settings in the vSAN Capacity view, not per-VM.
- Force provisioning allows an object to be placed despite insufficient resources at the cost of temporary policy non-compliance and reduced redundancy until resources become available.
- Adding local capacity devices to hosts already contributing to vSAN can create an unwanted second, separately managed datastore instead of extending the vSAN datastore.
- Capacity math follows device layout directly (for example, 5 disk groups times 7 capacity devices each yields 35 capacity devices and 5 cache devices), and an external KMS used for encryption should be deployed redundantly with at least two instances.
Domain 5: Availability, disaster recovery, and business continuity design
- Recovery tiers should map replication interval and recovery-plan priority to measured business impact, aligning a critical system such as order processing to a tighter RPO/RTO tier and a lower-priority system such as reporting to a looser tier so investment is proportional to impact.
- Per-tier protection groups allow independent RPO tuning and precise orchestration control, while a single recovery plan can still coordinate the overall failover sequence and dependencies across all groups.
- The two supported VM data replication mechanisms are array-based replication via a Storage Replication Adapter (SRA) and host-based vSphere Replication.
- Zero RPO is physically bounded by inter-site latency; a 60 ms link rules out any synchronous technology, and a 5-minute asynchronous interval can never satisfy a true RPO=0 requirement.
- When replication transfer time is less than the configured interval no backlog accumulates, so the achievable RPO tracks the configured interval (for example, a 6-minute transfer within a 10-minute window yields a 10-minute RPO).
- A recovery test uses a temporary writable copy of replicated data on an isolated network so production is never touched and replication continues, whereas a real failover promotes the actual replica; never testing restores leaves latent failures undiscovered until a real outage.
- Recovery plans automate per-VM IP reassignment when the recovery site uses different subnets, and local egress lets recovered workloads exit through the recovery site's own uplinks.
- Backups must sit outside the fault domain they protect: an external off-box SFTP or equivalent target is required so backups survive loss of the management domain compute and storage.
- Ransomware defense combines immutability with a separate identity boundary so compromised production credentials cannot delete or tamper with recovery points; off-domain storage, escrowed encryption keys, and documented restore testing together demonstrate recoverability.
- Live Site Recovery (formerly Site Recovery Manager) orchestrates replication-based failover but does not by itself provide immutable, air-gapped vaulting; that capability comes from a separate immutable backup solution.
- Image-level backup supplements file-based backup as an alternate whole-VM recovery path when the primary route is unavailable.
- A standard management domain commonly needs 4 hosts to combine vSAN FTT=1 data protection with N+1 spare capacity, since 3 hosts satisfy FTT=1 alone but leave no spare host to absorb a failure.
- Percentage-based reservation recalculates automatically as hosts are added or removed, and admission control mainly governs new power-on requests rather than acting on already-running VMs.
- The NSX Manager cluster VIP requires Layer 2 adjacency among the nodes; a design that separates the nodes across Layer 3 boundaries should use an external load balancer instead of the built-in VIP.
Domain 6: Operations, monitoring, and lifecycle design
- A super metric is justified when a reusable custom formula must combine multiple metrics or objects into a single derived value applied consistently across many objects; it is not warranted when a built-in metric exists or a one-off calculation would suffice.
- The recommended runbook automation pattern defines a threshold as an Aria Operations alert definition linked to a recommendation or action that automatically invokes an Aria Orchestrator workflow, closing the loop without waiting for an operator.
- Immediate response plus durable evidence needs are met by combining webhook or REST outbound notifications for SLA-impacting severities with continuous log forwarding to an external SIEM for searchable, compliant retention.
- Continuous or daily scanning provides near real-time drift visibility while a separately scheduled report cadence (for example quarterly, aligned to a PCI-DSS attestation cycle) reuses that same data as attestation evidence; the two are complementary, not conflicting.
- A separate custom compliance benchmark layers organization-specific controls on top of official STIG content without corrupting the shipped STIG baseline.
- Alert thresholds and escalation priority should be tuned per workload domain by business criticality, with production tuned tighter than test or development to reduce noise in lower tiers while keeping urgent production alerts responsive.
- Aria Operations sizing is driven by ingestion rate, retention period, and desired resiliency or throughput; an HA deployment requires a master node, a master replica, and at least one data node.
- Per-tenant visibility in a shared Aria Operations instance is enforced with custom object groups combined with scoped custom roles, and tag-driven custom groups with proportional cost policies give a defensible usage-based tenant allocation.
- Showback provides cost visibility without triggering real billing transactions, and showback rate changes should follow a documented annual review-and-approval governance process to remain deliberate and auditable.
- What-if scenarios proactively model projected workload against real capacity constraints; the Remove Object scenario approximates capacity loss but must be independently validated against vSAN stretched-cluster specifics such as witness placement rather than assumed to model them fully.
- DR failover capacity must be tracked separately from day-to-day growth headroom so it is not silently consumed by routine onboarding, and insufficient spare capacity with no admission control jeopardizes host evacuation during rolling upgrades.
- Skip-level upgrades require a validated upgrade path that may route through intermediate releases, and firmware or BIOS changes require a defined maintenance window with rollback planning plus documented pre- and post-change validation checks.
- Archived log or metric data must be restored or imported before it can be searched again; it is not queryable while archived.
- Cross-layer root-cause correlation is enabled by relationship mapping combined with symptom-linked recommendations, letting operators trace a problem across the compute, storage, and network layers.
VMware VCAP-VCF exam tips
- Master the precise definitions and be ready to classify a statement as a requirement, constraint, assumption, or risk; the exam repeatedly tests whether you can tell an unverified assumption from an externally imposed constraint.
- For every design decision, expect to identify its justification (which requirement it satisfies) and its implication (cost or consequence); a decision with no traceable justification or no implication is a red flag the exam wants you to catch.
- Memorize the core sizing rules cold: vSAN fault domains follow 2 times FTT plus 1 (3 for FTT=1, 5 for FTT=2), RAID-6 needs 6 hosts, stretched-cluster data sites need 5 ms or less RTT, and management domains often need 4 hosts for FTT=1 plus N+1.
- Watch for numeric contradictions between an objective and the proposed technology, such as a 4-hour interval against a 5-minute RPO or a 60 ms link against RPO=0; when the math does not work, the design must be revised regardless of tooling.
- Know the NSX topology rules exactly: the native Load Balancer attaches only to Tier-1, Tier-1 centralized services are always Active-Standby, RTEPs live only on Edge nodes, and Federation exists because Manager consensus needs roughly 10 ms RTT.
Study guide FAQ
How is VCAP-VCF: Cloud Foundation Design different from the VCP-VCF Architect level?
VCAP is a senior, advanced design exam that goes beyond VCP-level product knowledge. It expects you to produce and defend complete SDDC designs, justify each decision against requirements, constraints, assumptions, and risks, and reason through advanced NSX, vSAN, DR, and lifecycle trade-offs rather than simply recall feature facts.
When should I choose standard architecture over consolidated architecture in VCF?
Choose standard architecture when you need hard administrative separation for compliance, expect to grow beyond a single cluster, or require independently scheduled patch and upgrade cadences per business unit. Consolidated architecture shares one cluster, vCenter, and NSX Manager for management and tenant workloads, which conserves hardware but couples all lifecycle operations together.
What are the key latency limits I need to remember for design decisions?
A synchronous vSAN stretched cluster requires 5 ms or less RTT between the two data sites. NSX Manager cluster consensus needs roughly 10 ms RTT between nodes, which is why Federation splits into a Global Manager and Local Managers for higher-latency sites. Any RPO=0 requirement is bounded by latency, so a high-latency link such as 60 ms rules out synchronous replication entirely.
How do the design qualities factor into the exam scenarios?
Availability, manageability, performance, recoverability, and security are the lenses every scenario is evaluated through. A single requirement often affects several qualities and fans out into coordinated storage, network, and compute decisions, so you should map each requirement to the qualities it drives and confirm the proposed decision genuinely improves that quality rather than just restating the need.