VCP-VCF 9.0 Administrator (2V0-17.25)

VCP-VCF 9.0 Administrator (2V0-17.25)#

Exam Badge: 2V0-17.25

| 70 questions | 130 minutes | Passing score ~300/500 (60%) | Proctored

This is the foundational administrator certification for VMware Cloud Foundation 9.0. It validates hands-on operational knowledge of VCF components (vSphere, vSAN, NSX, lifecycle management, security, backup/DR). Unlike the VCDX (design-focused), this exam tests implementation and day-to-day administration of VCF 9.0 environments. Success requires deep understanding of each component's architecture, integration points, and common operational tasks.

• 📄 VCF 9.0 Official Documentation
• 📄 vSphere 8.x Administration Guide
• 📄 vSAN 8.x Storage Guide
• 📄 NSX 4.x Administration
• 📄 vSphere Replication DR Guide
• 📄 SRM (Site Recovery Manager)
• 📄 VCP-VCF 2024 Exam Details
• 📄 VMware Learning - VCDX Architect Path

VCF 9.0 Architecture & Components

VCF 9.0 fundamentally restructures the management plane. VCF 9.0 introduces VCF Operations as the primary management interface. Cloud Builder is removed (replaced by VCF Installer for initial deployment). SDDC Manager still exists but its UI is deprecated — lifecycle management and Day-2 operations are now performed through VCF Operations and vSphere Client. SDDC Manager UI will be removed in a future major release. The hierarchy introduces new concepts above the domain level: a VCF Private Cloud is the highest-level construct encompassing one or more Fleets, each Fleet contains one or more Instances, and each Instance contains domains (management + workload). VCF Operations becomes the mandatory management appliance, with SDDC Manager UI deprecated.
VCF 9.0 Architecture Diagram (ASCII)

┌─────────────────────────────────────────────────────────────────┐
│                     VCF Fleet Manager (Optional)                 │
│              Federated governance across multiple                │
│              VCF Instances in hybrid environments                │
└────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│         VCF Instance (vcdx-instance-01)                         │
│    ┌──────────────────────────────────────────────────────────┐ │
│    │     VCF Operations (Single mgmt appliance)              │ │
│    │  • HA-capable (standby instance for failover)          │ │
│    │  • Lifecycle Management Engine                         │ │
│    │  • Fleet Manager Agent (if federated)                  │ │
│    │  • Credentials vault, certificate authority            │ │
│    └──────────────────────────────────────────────────────────┘ │
│                              ↓                                   │
│    ┌──────────────────────────────────────────────────────────┐ │
│    │        vCenter (HA Cluster for management PC)          │ │
│    │  • Protected by vSphere HA (VM restart on host failure)           │ │
│    │  • PSC (Platform Services Controller) unified          │ │
│    │  • Manages NSX integration                             │ │
│    │  • Content Library, vSphere+ hybrid cloud              │ │
│    └──────────────────────────────────────────────────────────┘ │
│                              ↓                                   │
│    ┌──────────────────────────────────────────────────────────┐ │
│    │    NSX Manager Cluster (3 nodes, 9.x+)                │ │
│    │  • Tier-0 & Tier-1 gateway management                  │ │
│    │  • DFW (Distributed Firewall) policies                 │ │
│    │  • Segment & VTEP management                           │ │
│    │  • BGP/OSPF routing                                    │ │
│    └──────────────────────────────────────────────────────────┘ │
│                                                                  │
│    ┌─────────────────────┐      ┌──────────────────────┐       │
│    │ Management PC       │      │ Workload PC (N)      │       │
│    │ ┌─────────────────┐ │      │ ┌──────────────────┐ │       │
│    │ │ ESXi 8.x hosts  │ │      │ │ ESXi 8.x hosts   │ │       │
│    │ │ (4 min)         │ │      │ │ (4+ min)         │ │       │
│    │ │ • vSAN 8.x      │ │      │ │ • vSAN 8.x       │ │       │
│    │ │   (OSA/ESA)     │ │      │ │ • Tier-1 GW      │ │       │
│    │ │ • Standalone    │ │      │ │ • Workloads      │ │       │
│    │ │   VC (optional) │ │      │ │ • NSX integration│ │       │
│    │ └─────────────────┘ │      │ └──────────────────┘ │       │
│    └─────────────────────┘      └──────────────────────┘       │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Key Architectural Changes from VCF 5.2 to 9.0:

• Cloud Builder removed (VCF Installer used for initial deployment); SDDC Manager UI deprecated, functions migrated to VCF Operations and vSphere Client

• Domain-only hierarchy expanded: Private Cloud (top) → Fleet → Instance → Domains
• vCenter per domain → vCenter per PC (HA-capable)
• NSX-T 3.x → NSX 4.x (supports both NSX-T and NSX simple)
• vSAN 7.x → vSAN 8.x (OSA + ESA options, vSAN Max for disaggregation)

• Bring-up workflow automated by VCF Operations (no Cloud Builder UI)

Instance vs Fleet vs Private Cloud Explained

Instance:

A standalone VCF deployment controlled by a single VCF Operations appliance. Has its own vCenter, NSX, and private clouds. Equivalent to legacy SDDC Manager instance.

Fleet:

A logical grouping of multiple Instances managed by VMware Cloud Foundation Fleet Manager (optional add-on). Enables: cross-instance policies, workload mobility, multi-instance vSAN support, federated networking.

Private Cloud:

A logical compute/storage/network resource unit within an Instance. Replaces legacy "Domain" concept. Can be management PC (hosts VCF Operations, vCenter) or workload PC (hosts customer VMs). Each Instance must have 1 management PC; can have N workload PCs.

Management Domain vs Workload Domain (Legacy Terminology)

These terms still exist in VCF 5.2 but are deprecated in 9.0. Understanding the mapping is critical for migration scenarios:

Aspect

VCF 5.2: Management Domain

VCF 5.2: Workload Domain

VCF 9.0: Management PC

VCF 9.0: Workload PC

Purpose

Hosts SDDC Manager, vCenter, NSX, management VMs

Runs customer workloads, isolated from mgmt

Hosts VCF Operations, HA vCenter, NSX, infrastructure

• Runs customer/app workloads, can have multiple
• Number per SDDC
• 1 (required)
• 1-N
• 1 (required)
• 0-

vSphere Administration

vSphere 8.x is the foundation of VCF 9.0. Mastering ESXi host management, vCenter cluster operations, VM lifecycle, and HA/DRS is non-negotiable for VCDX-level administration.

ESXi 8.x Host Management

Key capabilities in ESXi 8.x:

Secure Boot & vTPM:

ESXi 8.0+ supports Secure Boot (prevents rootkits at firmware level) and virtual TPM (vTPM) for VM encryption keys. Enterprise deployments require these.

Memory Encryption:

AMD SEV (Secure Encrypted Virtualization) and Intel TME (Total Memory Encryption) at host level. Can be enabled per-VM for sensitive workloads.

Driver Support & HWA:

Hardware acceleration for NVMe, storage controllers, and network adapters. Critical for performance tuning.

Kernel Module Acceptance Level:

Can restrict (partner/vmware-approved) or allow (any driver). Set via Host Profile or ESXi settings. VCDX exams test this.

vCenter 8.x Operations

vCenter Server Availability: vSphere provides vCenter HA as an Active-Passive-Witness architecture (NOT active-active). The Active node handles all operations, continuously replicating data to a Passive node. A lightweight Witness node (1 vCPU, 1GB RAM) provides quorum. If the Active node fails, the Passive node is promoted automatically. All three nodes communicate over a dedicated vCenter HA private network.
vCenter HA Architecture:

┌──────────────────────────────────┐
│ vCenter HA (Active-Passive-Witness)│
│ ┌─────────────┐                  │
│ │ vCenter-01  │ (Active)         │
│ │ Public IP   │ Handles all ops  │
│ ├─────────────┤                  │
│ │ vCenter-02  │ (Passive)        │
│ │ No public IP│ Receives replicas│
│ ├─────────────┤                  │
│ │ vCenter-03  │ (Witness)        │
│ │ 1vCPU/1GB   │ Quorum only      │
│ └─────────────┘                  │
│ • Continuous replication Active→ │
│   Passive over HA private network│
│ • Automatic failover if Active   │
│   node fails                     │
└──────────────────────────────────┘

IMPORTANT VCF Restriction: vCenter HA CANNOT be configured for a vCenter Server that is managed by VCF (per Broadcom documentation). In VCF environments, vCenter availability is achieved through vSphere HA (which restarts the vCenter VM on another host if the ESXi host fails) and regular SDDC Manager/VCF Operations backups for recovery. This is a critical exam distinction — do not confuse vCenter HA (standalone vSphere feature) with vCenter protection in VCF (vSphere HA + backup/restore).
VM Lifecycle & Resource Management

DRS (Distributed Resource Scheduler)

DRS balances VM placement across hosts to optimize CPU/memory utilization. DRS algorithms in vSphere 8.x:

Affinity Rules:

VMs should/must run on same host or separate hosts. Critical for HA VMs (e.g., don't co-locate all DB nodes on one host).

VM/Host Groups:

Assign VMs and hosts to groups, then apply rules. Example: "Finance VMs run on Finance Hosts."

Cluster Configuration:

Enable DRS on cluster

Get-Cluster "management-domain" | Set-Cluster -DrsEnabled:$true -DrsAutomationLevel "Partia

Key Takeaways

• VCDX Test Focus: Expect deep questions on DRS automation levels, HA admission control calculation, FT limitations, and vMotion compatibility. Practice calculating failover capacity: (total_resources) - (largest_host) = failover_budget.
• Exam Emphasis: Expect 8-10 questions on vSAN. Know how to calculate usable capacity from raw disks + RAID + replication. Understand FTT vs host failure tolerance. Know when to use OSA vs ESA. Stretched cluster is common in disaster recovery scenarios—understand quorum math.
• NSX Exam Topics: Expect questions on Tier-0/Tier-1 hierarchy, segment creation, DFW microsegmentation rules, VXLAN encapsulation, and BGP/OSPF peering. Practice creating a multi-tier network (app, db, storage segments) with DFW policies that enforce east-west isolation.
• LCM is heavily tested on the exam. Understand pre-check/remediation flow, bundle dependencies, certificate rotation, drift detection, and upgrade paths. Practice reading LCM logs to troubleshoot failed patches. Know which components are HA-safe during patching (vCenter, NSX) and which are not (vSAN
• Backup & DR Design: VCDX exams test your ability to design a complete backup strategy. Example: "Design a DR plan for VCF with 4-hour RTO and 1-hour RPO." Answer: vSphere Replication (5 min RPO VM level) + SRM (orchestration) + VADP hourly backups (granular restore) + VCF component daily backup.

VCF 9.0 Day-1 Bring-up Flow End-to-End#

Deploying VCF 9.0 is fundamentally different from VCF 5.2. The workflow has shifted from Cloud Builder → SDDC Manager to VCF Installer → VCF Operations Manager, with a revised governance model emphasizing Fleet management and Private Clouds. Understanding each step and its validation gates is essential for VCP-Admin certification and beyond.

Pre-Flight Prerequisites & Validation

Before launching VCF Installer, validate the physical infrastructure:

Infrastructure Checklist:

├─ Hardware:
│  ├─ CPU: minimum 16 cores per ESXi host (32+ recommended for VCF 9.0)
│  ├─ RAM: 256 GB per host minimum (512 GB+ if vSAN + workloads on same cluster)
│  ├─ NVMe: 2x 1.6 TB (management domain) + 4x 3.84 TB (workload domain)
│  └─ NIC: minimum 10 GbE (25 GbE+ recommended for vSAN replication)
├─ Networking:
│  ├─ Management network: 192.168.1.0/24 (for vCenter, NSX, SDDC → VCF Ops IPs)
│  ├─ vSAN network: 192.168.2.0/24 (dedicated for vSAN replication, isolated vLAN)
│  ├─ Workload network: 192.168.3.0/24 (overlay or external)
│  ├─ Static IPs reserved: 192.168.1.10-30 (management domain components)
│  └─ DNS/NTP: external servers configured, synchronization verified
├─ Software:
│  ├─ ESXi 8.0 U2 or later installed on all hosts
│  ├─ VCF Installer OVA staged (download from Broadcom Support Portal)
│  └─ VCF bundle (5.2.2.0, 9.0.0, or 9.0.2) available (online or offline)
└─ Validation:
   ├─ NTP: all ESXi hosts ± 1 second of true time
   ├─ Networking: ping between all ESXi hosts on all vLANs
   └─ Storage: all NVMe devices visible via vCenter datastore browser

Step 1: VCF Installer OVA Deployment

Deployment Method:

Deploy the VCF Installer OVA to one of the ESXi hosts (typically the first host, which will host SDDC Manager in VCF 5.2 or become the management domain in VCF 9.0).

VCF Installer Appliance Sizing:

├─ vCPU: 8
├─ Memory: 16 GB
├─ Disk: 100 GB (thin-provisioned)
├─ Network: 1 vNIC (management network, e.g., 192.168.1.5)
└─ Deployment location: First ESXi host (host-01) or shared vCenter if pre-existing

Post-Deployment Configuration:

1. Power on VCF Installer VM
2. Wait for boot (3–5 minutes)
3. Access via SSH or Web UI: https://vcf-installer-ip:443/ui
4. Authenticate: root / password (or customer-provided credentials)

5. Navigate to: Deployment → Start New Deployment

Step 2: Management Domain Bring-up (Foundation Tier)

The management domain is the foundational tier in VCF 9.0. It contains:

vCenter Server:
Single VCSA protected by vSphere HA (vCenter HA not supported in VCF)

NSX Manager Cluster:

3-node cluster

VCF Operations Manager:

Single appliance (or HA pair if required)

Fleet Manager (optional):

• For multi-instance federation
• vSAN Datastore:
• Minimum 2 TB capacity (all management objects)

VCF Installer bring-up workflow (automated):

Step 2A: Configure Management Domain Network Pools

├─ Specify IP ranges for management components:
│  ├─ vCenter VIP: 192.168.1.10 (floating IP, HA endpoint)
│  ├─ NSX Manager IPs: 192.168.1.20, 192.168.1.21, 192.168.1.22 (one per manager)
│  ├─ SDDC Manager (VCF 5.2 only): 192.168.1.30
│  ├─ VCF Operations: 192.168.1.32 (new in VCF 9.0)
│  ├─ Fleet Manager: 192.168.1.33 (new in VCF 9.0)
│  └─ ESXi management IPs: 192.168.1.50-60 (vmk0 for each host)
└─ Validation: VLC verifies no IP conflicts with physical network gateway

Step 2B: Deploy vCenter Server

├─ VCF Installer deploys a single vCenter Server Appliance (VCSA)
├─ vCenter is protected by vSphere HA (VM restart on host failure)
├─ Note: vCenter HA (active-passive-witness) is NOT supported in VCF
└─ Validation: vCenter boots, DNS resolves vcenter.vcf.local to management IP

Step 2C: Deploy NSX Manager Cluster

├─ 3 NSX Manager appliances deployed (spread across 3 ESXi hosts)
├─ NSX Manager is clustered (one Primary, two replicas)
├─ NSX Controllers (data plane) are ready but not yet deployed
└─ Validation: NSX Manager API responding on 192.168.1.20:443

Step 2D: Configure vSAN for Management Domain

├─ vSAN cluster is auto-formed (4-node minimum for HA)
├─ Single disk group per ESXi host (cache + capacity)
├─ Datastore named "vsanDatastore" (default)
├─ RAID-1 mirroring enabled for fault tolerance
└─ Validation: vCenter reports vSAN health as GREEN, quorum count = 4 nodes

Step 2E: Deploy VCF Operations Manager (NEW in VCF 9.0)

├─ Single appliance (16 vCPU, 64 GB RAM) deployed as nested VM
├─ VCF Ops connects to vCenter, NSX Manager, and cluster
├─ Collectors (optional) can be deployed separately for scale
└─ Validation: VCF Ops UI is accessible at https://vcf-ops.vcf.local:443

Step 2F: Bootstrap Identity Services (NEW in VCF 9.0)

├─ Local user database initialized (administrator@vcf.local)
├─ Optional: LDAP/AD integration configured
├─ OAuth 2.0 enabled for API clients
└─ Validation: Can log into VCF Ops with administrative credentials

Management Domain Bring-up Time: 60–90 minutes (depends on hardware + network)

Post-Bring-up Validation Gates:

├─ DNS resolution of all FQDNs (vcenter.vcf.local, nsxmgr.vcf.local, etc.)
├─ SSL certificates auto-generated and valid

Key Takeaways

• VCP-Admin Test Tip:Understand the *difference* between VCF 5.2 (Cloud Builder → SDDC Manager) and VCF 9.0 (VCF Installer → VCF Operations Manager) bring-up flows. Exam questions will ask: "Which component in VCF 9.0 replaces SDDC Manager?" Answer: VCF Operations. "What new appliance ma

Understanding the VCF Fleet Concept Deeply#

VCF Fleet is one of the most significant architectural changes in VCF 9.0. It fundamentally changes how organizations manage multiple VCF instances. This is a VCP-Admin-level concept but critical for VCDX-level design.

What is a Fleet? (Hierarchy & Terminology)

The VCF 9.0 Management Hierarchy:

Fleet (manages multiple VCF Instances within a Private Cloud)

├─ Fleet Manager Appliance (192.168.100.33)
│  ├─ Fleet Repository (PostgreSQL backend, ~100 GB)
│  ├─ Inventory Sync Engine (polls instances every 5 minutes)
│  ├─ Policy Propagation Engine (pushes policies to all instances)
│  └─ Reporting & Analytics (cross-instance dashboards)
│
├─ Instance-1 (VCF 9.0 deployed in DC-A, 192.168.1.10 vCenter VIP)
│  ├─ Management Domain
│  │  ├─ vCenter (protected by vSphere HA)
│  │  ├─ NSX Manager (3-node)
│  │  └─ VCF Operations
│  │
│  └─ Private Cloud 1 (Workload Domain)
│     ├─ ESXi Cluster (3–32 hosts)
│     ├─ vSAN Datastore
│     └─ NSX Overlay Networks
│
├─ Instance-2 (VCF 9.0 deployed in DC-B, 192.168.2.10 vCenter VIP)
│  ├─ Management Domain
│  └─ Private Cloud 1
│
└─ Instance-3 (VCF 9.0 deployed in Cloud-C, public cloud)
   ├─ Management Domain
   └─ Multiple Private Clouds (multi-tenant)

Fleet Manager Appliance: Architecture & Deployment

Appliance Specifications (Physical or Nested in HA pair):

• Component
• Specification
• Notes
• vCPU
• 8 (can increase to 16 for 100+ instances)
• More instances = more inventory sync CPU
• Memory
• 16 GB (can increase to 32 GB for scale)
• Fleet sync engine is memory-hungry at scale
• Storage
• 100 GB (persistent PostgreSQL database)
• Database grows ~1 MB per instance per day
• Network
• 1 NIC (management network), static IP required
• Must be able to reach all VCF instance management networks
• High Availability
• Optional (active-passive pair with shared storage/database)
• Recommended for production (no automatic failover; manual failover required)

Fleet Manager High Availability (Production Deployment):

Two-Node Fleet Manager HA Pair:

├─ Fleet Manager Primary (192.168.100.33)
│  ├─ Shares PostgreSQL database on NFS export from vSAN
│  └─ Actively syncs inventory from all VCF instances
│
├─ Fleet Manager Standby (192.168.100.34)
│  ├─ Read-only copy of database
│  └─ Can be promoted to Primary manually via CLI
│
└─ Virtual IP (192.168.100.33) – points to active node

(Manual failover: update VM network to new primary, update VCF instance registrations)

Note: VCF 9.0 GA supports manual failover only. Delivered in VCF 9.1: fleet lifecycle and operational components run on the unified VCF management services runtime; validate automatic-failover behavior against the 9.1 release notes before designing around it

Instance vs. Private Cloud Distinction

Critical Terminology:

• Concept
• What It Is
• Scope
• Number per Fleet
• Example
• Fleet
• All infrastructure within a VCF deployment (VCF Operations, vCenter, NSX, domains)
• Per datacenter or region
• 1 or more per Private Cloud
• All VCF components in a datacenter
• Instance
• A complete VCF deployment (independent management domain + storage)
• Per datacenter or cloud region
• 2–10 per fleet (typical)
• VCF in DC-A, VCF in DC-B, VCF in AWS
• Management Domain
• vCenter, NSX Manager, VCF Ops (foundation tier)
• Per instance (not shared)
• 1 per instance
• 192.168.1.10 (vCenter VIP in DC-A instance)
• Private Cloud
• Tenant-isolated workload pool (compute + storage)
• Per instance
• 1–20 per instance (typical)
• Production cloud, Staging cloud, Dev cloud (all on same instance)

Example Scenario: Enterprise with Multiple Instances

Fleet: "Global-VCF-Fleet"

├─ Instance: "DC-A-Production"
│  ├─ Management Domain: vCenter 192.168.1.10
│  ├─ Private Cloud: "Prod-Finance" (50 hosts, 5000 VMs)
│  └─ Private Cloud: "Prod-Engineering" (30 hosts, 2000 VMs)
│
├─ Instance: "DC-B-Disaster-Recovery"
│  ├─ Management Domain: vCenter 192.168.2.10
│  └─ Private Cloud: "DR-Finance" (50 hosts, 5000 VMs – stretched from DC-A)
│
└─ Instance: "AWS-Production"
   ├─ Management Domain: vCenter (AWS EC2 deployed)
   ├─ Private Cloud: "Cloud-Prod-NA" (N nodes, burst capacity)
   └─ Private Cloud: "Cloud-Prod-EMEA" (N nodes, burst capacity)

Cross-Instance Operations via Fleet Manager:

├─ Policy Sync: Define a DFW ruleset once, push to all instances
├─ Inventory View: Single dashboard shows all VMs across DC-A, DC-B, AWS
├─ Workload Migration: Orchestrate HCX migration from DC-A to DC-B
└─ Reporting: Consolidated license usage, compliance, cost (all instances combined)
Cross-Instance Operations: Policy Propagation & Inventory Sync
Inventory Sync Process (automated every 5 minutes):
1. Fleet Manager connects to each VCF instance's vCenter (HTTPS 443)
2. Queries inventory:
   └─ VMs, hosts, clusters, datastores, networks, DFW rules
3. Stores in local PostgreSQL database
4. Builds cross-instance inventory model:
   ├─ Global VM list (tagged by instance/private cloud)
   ├─ Global network topology (NSX federation data)
   └─ Global DFW rule matrix (combined rules from all instances)

5. Makes available via Fleet Manager REST API

• Inventory Sync Interval: 5 minutes (configurable, minimum 1 minute for real-time)
• Typical sync time: < 10 seconds (depends on number of VMs; 10,000+ VMs = ~30 sec)
• Policy Propagation Example: DFW Ruleset Push

Use Case:

Key Takeaways

• VCDX Design Consideration:If your design involves a multi-cloud or multi-region VCF deployment, Fleet Manager is critical. However, understand its limitations. For example: "My design uses Fleet Manager for policy governance across 3 VCF instances, but each instance maintains independent storage/com
• VCDX Identity Design Consideration:If your design involves a multi-tenant VCF environment, Identity Services federated with external IdP is non-negotiable. Demonstrate: (1) SAML integration with corporate AD/Okta, (2) attribute-based RBAC (groups in AD map to VCF roles), (3) per-Private-Cloud access
• VCDX DR Design Validation:Your VCDX defense must include a tested, documented BCDR strategy. Show: (1) backup procedures with screenshots of successful backups, (2) restore test results (timeline: how long to restore vCenter, NSX, VCF Operations), (3) stretched cluster failover test (manually failed over, docu

VCF Compute, Storage & Network Fundamentals (Objectives 2.2–2.4)#

Blueprint Objectives 2.2, 2.3, 2.4 — VCF Fundamentals

This topic covers VCF-specific aspects of compute, storage, and networking that differentiate VCF Admin from VVF Admin. Core vSphere/vSAN/networking concepts are covered in the main theory topic; this topic focuses on how these components integrate within the VCF stack.

VCF Compute Fundamentals (Objective 2.2)

Deploy/Configure VCF Compute:

VCF compute deployment differs from standalone vSphere — all ESXi hosts are commissioned through VCF Operations or SDDC Manager, not manually added to vCenter.

Host Commissioning Workflow:

├── Physical host prepared (BIOS, firmware, networking)
├── ESXi installed with VCF-compatible image (from VCF bundle)
├── Host added to VCF Operations free pool: VCF Operations UI → Hosts → Commission → enter host IP, credentials
├── VCF Operations validates: NTP sync, DNS resolution, network connectivity, storage readiness
├── Host assigned to Private Cloud (workload domain) or management domain
└── VCF Operations automatically configures: vDS uplinks, vSAN disk groups, NSX transport node

vSphere Cluster Configuration in VCF:

├── Clusters created via VCF Operations (not directly in vCenter)
├── DRS: Fully Automated required for VCF (manual not supported)
├── HA: Enabled with admission control (percentage-based, 25% default)
├── EVC (Enhanced vMotion Compatibility): Recommended for mixed-CPU clusters
├── vLCM: Image-based lifecycle (VCF bundle includes ESXi + VIB + firmware)
└── Minimum: 4 hosts per cluster in management domain, 3 in workload domain

Deploy/Configure VMs in VCF:

├── Standard VM deployment via vCenter (same as standalone vSphere)
├── Content Libraries: Federated across VCF instance (publish/subscribe)
├── VM Templates: OVF/OVA deployed via vCenter or VCF Automation (if licensed)
├── VM Encryption: vTPM + VM encryption policies backed by KMS (HyTrust, Thales)
├── VM Storage Policies: Tied to vSAN storage policies (FTT, encryption, RAID level)
└── GPU Passthrough: vGPU (NVIDIA GRID) or DirectPath I/O for AI/VDI workloads

Manage VMs through vCenter:

├── Day-2 VM operations: snapshot, clone, migrate (vMotion), hot-add CPU/memory
├── vSphere DRS automation: VM placement recommendations, load balancing
├── Resource Pools: Hierarchical resource allocation (shares, limits, reservations)
├── VM Groups & Host Groups: Affinity/anti-affinity rules for workload placement
├── Distributed Resource Scheduling (DRS) Levels:
│   ├── Manual: Recommendations only (admin must approve)
│   ├── Partially Automated: Initial placement automatic, migrations recommended
│   ├── Fully Automated: All placement and migrations automatic (VCF default)
│   └── Migration Threshold: Conservative (1) to Aggressive (5) — affects sensitivity
└── Tags & Custom Attributes: Organizational metadata for filtering and policy

VCF Storage Fundamentals (Objective 2.3)

vSphere Storage in VCF:

├── VMFS 6: Block storage on FC/iSCSI SAN (supported as principal storage)
├── NFS 4.1: Network file storage (supported as supplemental storage)
├── vVols: Per-VM granularity with VASA provider (supported, vendor-dependent)
├── vSAN: Default HCI storage for VCF (most common)
└── vSAN Max: Disaggregated vSAN — compute and storage on separate clusters (VCF only)

vSAN ESA vs OSA:

├── OSA (Original Storage Architecture):
│   ├── Separate cache tier (SSD) + capacity tier (HDD or SSD)
│   ├── Disk groups: 1 cache device + 1-7 capacity devices per group
│   ├── Up to 5 disk groups per host
│   ├── Dedup/compression: Optional, post-process
│   └── Use case: Existing hardware with mixed SSD/HDD
├── ESA (Express Storage Architecture):
│   ├── Single storage tier (NVMe only — no cache tier distinction)
│   ├── Storage pool: All NVMe devices contribute to single pool
│   ├── Dedup/compression: Always on, inline (no performance penalty on NVMe)
│   ├── RAID-5/6 erasure coding with single object stripe
│   ├── Higher performance: Single tier eliminates cache destaging bottleneck
│   └── Use case: New deployments with NVMe-only storage (recommended for VCF 9.0)
└── Decision Framework:
    ├── Choose ESA if: All NVMe, new deployment, VCF 9.0
    ├── Choose OSA if: Mixed media (SSD + HDD), existing hardware, budget constraints
    └── Migration: OSA → ESA requires vSAN cluster rebuild (no in-place migration)

vSAN Storage Policies:

├── FTT (Failures to Tolerate): 0, 1, 2, 3
├── RAID Level: RAID-1 (mirroring) or RAID-5/6 (erasure coding)
├── Encryption: Data-at-rest (KMS required), data-in-transit (TLS between hosts)
├── Object Space Reservation: Thick provisioning (0-100%)
├── IOPS Limit: Per-object QoS throttling
├── Checksum: Data integrity verification (enabled by default)
└── Stripe Width: Number of capacity devices used (performance tuning)

vSAN Resilience & Data Availability:

├── Component placement: Automatic across fault domains
├── Fault Domains: Group hosts by rack/power/network for failure isolation
├── Witness: Required for 2-node clusters (witness appliance on third failure domain)
├── Stretched Cluster: Synchronous replication across 2 sites + witness (RPO=0)
├── vSAN Data Migration: Ensure accessibility/full evacuation/no data migration (host maintenance)
└── Rebuild Priority: Automatic after failure, configurable delay timer (60 min default)

VCF Network Fundamentals (Objective 2.4)

Differentiate VCF Networking Components:

VCF uses NSX for overlay networking — unlike VVF which uses vDS only. Understanding the NSX integration is critical.

NSX in VCF — Architecture:

├── NSX Manager Cluster: 3-node cluster (management plane)
├── NSX Edge Cluster: 2+ Edge nodes (data plane — north-south routing)
├── Transport Zones:
│   ├── Overlay TZ: Geneve encapsulation for east-west VM traffic
│   └── VLAN TZ: Physical network connectivity (uplinks to ToR switches)
├── Transport Nodes: ESXi hosts with NSX VIBs installed (N-VDS or vDS-backed)
└── Segments: Logical network switches (replace port groups in NSX world)

NSX Networking Constructs:

├── Tier-0 Gateway: North-south routing (connects to physical network via BGP/OSPF/static)
│   ├── HA Mode: Active-Active or Active-Standby
│   ├── Route Redistribution: Connected, static, NAT, LB VIPs
│   └── Uplink: Connected to VLAN-backed segment on Edge node
├── Tier-1 Gateway: Tenant/workload routing (connects to Tier-0 for external access)
│   ├── Per-workload domain or per-tenant isolation
│   ├── Services: NAT, firewall, load balancing, DHCP, DNS forwarding
│   └── Route Advertisement: Connected subnets, NAT IPs, LB VIPs → Tier-0
├── Segments: Layer 2 broadcast domains (equivalent to VLANs/port groups)
│   ├── Overlay Segment: Geneve-encapsulated (TEP-to-TEP tunneling)
│   ├── VLAN Segment: Direct VLAN tagging (for physical device connectivity)
│   └── Subnet: IP range + gateway assigned per segment
└── Distributed Firewall (DFW): Microsegmentation at hypervisor level
    ├── Rules applied per-VM (based on tags, segments, groups, IPs)
    ├── Stateful inspection: East-west traffic filtered without hairpinning
    ├── Policy Categories: Emergency > Infrastructure > Environment > Application
    └── Applied to: All VMs on NSX-prepared hosts (no agent required)

Configure Virtual Networking Fabrics/Features:

├── N-VDS: NSX-managed virtual switch (deprecated in NSX 4.x — use vDS integration)
├── vDS Integration: NSX 4.x integrates with vSphere Distributed Switch
├── TEP (Tunnel Endpoint): IP on each host for Geneve encapsulation
│   ├── TEP VLAN: Dedicated VLAN for overlay traffic (jumbo frames recommended)
│   └── TEP Pool: IP range assigned via VCF Operations during host commissioning
├── MTU: 1700 minimum for overlay (1600 Geneve header + 100 safety margin)
└── BFD (Bidirectional Forwarding Detection): Fast failure detection between TEPs

Configure Virtual Networking Connectivity/Routing:

├── BGP Peering: Tier-0 peers with physical ToR switches (eBGP recommended)
├── OSPF: Alternative to BGP for Tier-0 uplink routing
├── Static Routes: Manual routes on Tier-0/Tier-1 (simple topologies)
├── Route Redistribution: Control which routes are advertised (connected, static, NAT)
└── ECMP: Equal-Cost Multi-Path for north-south load distribution across Edge nodes

Configure Virtual Networking Services:

├── NAT: SNAT (outbound masquerade), DNAT (inbound service publishing)
├── Load Balancing: L4/L7 LB on Tier-1 (or Avi ALB for advanced)
├── DHCP: Relay or local DHCP server on Tier-1 gateway
├── DNS Forwarding: Conditional DNS forwarding on Tier-1
├── VPN: IPSec (site-to-site) or L2VPN (extend L2 across sites)
└── Edge Firewall: Gateway firewall rules on Tier-0/Tier-1 (north-south filtering)

Holodeck Lab Note: In Holodeck, NSX overlay networking works within nested environment. TEP traffic is encapsulated inside the outer ESXi vDS. Verify MTU end-to-end: outer ESXi MTU must be ≥1700 for inner NSX overlay to function. Common Holodeck issue: overlay connectivity fails if outer vDS MTU is default 1500.

Key Takeaways

• Exam: VCF hosts are commissioned via VCF Operations (not manually added to vCenter). Know the commissioning workflow: prepare → commission → assign to domain → auto-configure.
• Exam: ESA vs OSA — ESA = NVMe-only, single pool, always-on dedup. OSA = mixed media, cache + capacity tiers, optional dedup. ESA recommended for VCF 9.0 new deployments.
• Exam: NSX in VCF — Tier-0 (north-south, BGP/OSPF) → Tier-1 (per-tenant routing, services) → Segments (L2). DFW for microsegmentation. TEPs for Geneve encapsulation.
• Exam: vSAN storage policies — know FTT + RAID combinations and their space overhead. FTT=1/RAID-1 = 2x overhead. RAID-5 FTT=1 depends on architecture: OSA is always 3+1 = 1.33x (4 hosts); ESA is adaptive - 2+1 = 1.5x under 6 hosts, 4+1 = 1.25x at 6+ hosts. RAID-6 FTT=2 (4+2) = 1.5x.

VCF 9.0 Edge Patterns (Design Library)#

VCF Edge is the 9.x successor to the pre-9.0 "Remote Clusters" concept — the docs state it plainly: "VCF Edge earlier called Remote Clusters is an optimized configuration of VMware Cloud Foundation tailored for edge use cases." Anything an exam presents as "remote clusters" in a 9.x context maps to VCF Edge.

Platform entitlement gates (VCF Edge Models page):

├── Minimum 10 sites or more
├── Minimum 8 CPU cores per host
├── Maximum 256 CPU cores per site
├── Edge hosts physically distinct from data-centre workloads (separate rack/switch)
└── VCF Operations is MANDATORY for licensing the Edge environment

The Design Library splits VCF Edge content into two tiers, and the distinction is exam-relevant:

• Design Options WITH Full VCF Stack -> the numbered "VCF Edge Pattern N" series
• Design Options WITHOUT the full stack -> the "VCF Edge Option N" series (3 options)

Pattern count is VERSION-SCOPED: VCF 9.0 documents NINE patterns (1-9). VCF 9.1 adds Pattern 10 (Colocated vCenter with ESX Host at the Edge) for TEN. Quote the count that matches the release you are asked about.

THE NINE VCF 9.0 EDGE PATTERNS

Pattern 1 — Centrally Managed Edge Compute Clusters in a Workload Domain
Each edge site is a vSphere compute cluster inside one central workload domain. Management (vCenter, NSX, VCF Operations, VCF Automation, SDDC Manager) is entirely in the core DC. Constraint: 100 ms / 10 Mbps to the edge. Choose for many sites, one operational model, no local admin staff.

Pattern 2 — Segregated Edge Deployment across Multi-Region Workload Domains
Central management domain, but ONE WORKLOAD DOMAIN PER REGION, each region holding multiple sites and its own independent vCenter for daily operation. Constraint: 100 ms / 10 Mbps. Choose for regional blast-radius separation with central governance.

Pattern 3 — Locally Managed Edge

The management domain is hosted NEAR the edge locations, and a single local vCenter manages both the management and the edge-site workloads. Each site operates autonomously. This is the key contrast with Patterns 1/2/6/8, where the WAN is on the critical path for management and LCM. Choose for oil rigs, mines, offshore platforms, military/defence, sovereignty-constrained and disconnected-tolerant sites. (The doc also captions a figure here "Locally Managed Thick Edge".)

Pattern 4 — VCF Fleet with Multi Region, Distributed Edge

Each major region runs its OWN VCF Instance with its own management domain, all bound into a single VCF Fleet. Management is explicitly dual-level: central IT owns LCM, certificates, password policy and standards; regional IT owns Day-N operations, resources, users and local compliance. A regional VCF Operations Collector handles local collection over WAN latency. The largest and most complex pattern.

Pattern 5 — Dark Site Edge

The dark site runs its OWN independent VCF Instance, separate from the primary Fleet, with a local management domain. A local VCF Offline Depot is deployed to serve software bundles, patches and upgrades in the absence of internet connectivity — this is what keeps LCM working. Two variants: Dark Site 1 buffers collector data offline and synchronises to central VCF Operations when connectivity returns; Dark Site 2 is fully local with its own Fleet and dedicated VCF Operations. Dark sites needing VKS deploy a Harbor bootstrap registry to stage initial components.
LICENSE CHECK-IN: the design guide states VCF Operations "mandates a periodic license check-in (e.g., every 180 days, even for dark sites via their limited connectivity or alternative methods)". Note the wording — 180 days is given as an EXAMPLE, and it is the only figure the guide provides. Treat it as the defensible exam answer, but do not defend it to a panel as a hard product-enforced maximum.

Pattern 6 — vSphere Supervisor at the Edge in a VCF Instance with Multiple Domains
Central management; workload domains hold multiple clusters so edge types can be separated. THIS is where thin/thick edge is defined: thin edge = 2-host clusters in a workload domain; thick edge = "a more substantial cluster with more resources" — no host count is documented for thick edge anywhere. Supervisor is enabled at each edge site alongside traditional VMs.

Pattern 7 — Supervisor Zonal Separation at the Edge

Each site is split into a Control Plane Zone and a Worker/Workload Zone (the doc uses both names). The two zones run on SEPARATE 2-HOST CLUSTERS with external storage — 4 hosts per site, 2 per zone, no vSAN. Unusually, management (VCF Operations, SDDC Manager, vCenter, VCF Automation, NSX) sits AT the edge location. Choose for strong local control and minimal external dependencies.

Pattern 8 — Single Host vSphere Supervisor at the Edge in a VCF Instance

ONE physical ESX host per edge site, with Supervisor enabled including a Supervisor Control Plane VM. Cluster creation and host add are manual in vCenter. Networking is VDS for both Supervisor management and workload networks; storage is shared or local.

HA ADMISSION CONTROL: the design guide is explicit — "vSphere HA is enabled on the cluster however, to make vSphere Supervisor to work, we have disabled HA Admission control in the cluster level in vCenter", and restates it as a requirement. Read that precisely: vSphere HA STAYS ENABLED; it is ADMISSION CONTROL that is disabled. An answer saying "disable vSphere HA" is wrong.

Connectivity: target 1 Gbps or higher, 100 Mbps minimum tolerable, latency below 100 ms. Implications: single point of failure, no vMotion for local HA, and a critical caveat — for multi-node VKS clusters, if a pod using a persistent volume must restart on another worker node, Supervisor MUST reach vCenter to perform the volume detach/attach, or the pod cannot come back online.

Choose for retail stores, bank branches, QSR, cell towers, remote industrial sites.

Pattern 9 — Leveraging Existing VCF Operations for Far Edge Expansion
An existing Fleet is extended to far-edge sites under VCF Edge licensing; a vCenter for those sites sits in the existing DC or a colo and connects to VCF Operations. VCF Operations provides LICENSE MANAGEMENT AND UNIFIED MONITORING ONLY — verbatim: "VCF Operation will not perform life cycle management of vCenter and hosts which are connected to this vCenter." LCM stays with the edge vCenter.

Pattern 10 — Colocated vCenter with ESX Host at the Edge (VCF 9.1 ONLY)
The management domain stays central, but each edge site needing colocated management deploys its own VCSA on-site next to its ESX cluster, imported into VCF as a workload domain. Option A is greenfield (deploy new, then brownfield-import); Option B imports an existing locally-managed vCenter with no redeployment and no VM maintenance window. Constraint: SDDC Manager to vCenter latency under 100 ms.

SIZING TABLE (from the pattern index page)

Four supported shapes: 1-node cluster in a VCF Instance | 2-node with external storage in a workload domain | 3-node vSAN cluster | 4-node VCF Fleet.

├── Max hosts per cluster: 64 (all four)
├── Max workload domains: NOT SUPPORTED for 1-node; 24 for the other three
├── 1-node storage: local or external NFS/FC. 2-node: external NFS or FC, NO vSAN. 3/4-node: vSAN or external
└── VKS supported in all four

Version drift to watch: the 9.0 index states 100 ms latency / 10 Mbps; the 9.1 index states 300 ms / 10 Mbps for the same columns. Cite the figure for the release you are asked about.

THE THREE NON-FULL-STACK OPTIONS

Option 1 — VCF Operations with vCenter for Distributed Edge: central VCF Operations plus centrally located vCenters managing many distributed sites.

Option 2 — Thin Edge with vSphere Supervisor on Two-Node vSAN: 2a places License Server, VCF Operations, vCenter and a Witness VM in a management cluster, recommends ONE Control Plane VM on the 2-node vSAN cluster, and allows up to 300 ms / 10 Mbps vCenter-to-ESX; 2b adds a unified software depot, centralised logging and password/certificate management, deployed with the VCF Installer's VVF option. The docs state the key deviation from Pattern 6 explicitly: this design does NOT incorporate a full VCF stack, but it does leverage vSAN.

Option 3 — vSAN Witness Placement for Distributed Edge: witness placed outside the data-bearing edge sites to hold quorum for 2-node vSAN edges.

TRAP: "THIN EDGE" IS DEFINED TWO INCOMPATIBLE WAYS

Pattern 6 (9.0): thin edge = 2-host clusters INSIDE a full VCF stack, centrally managed.

Option 2 (9.1): Thin Edge = 2-node vSAN cluster explicitly WITHOUT the full VCF stack.

Any statement asserting one universal definition of thin edge — or any host count for "thick edge" — is unsupported by the documentation.

Key Takeaways

• Count is version-scoped: VCF 9.0 documents NINE numbered Edge patterns (1-9); VCF 9.1 adds Pattern 10 for TEN. Plus three non-full-stack 'Options' in both releases.
• Pattern 5 = Dark Site Edge: own independent VCF Instance + local VCF Offline Depot for LCM. License check-in is given as 'e.g., every 180 days' — an example in the guide, not a hard enforced maximum.
• Pattern 8 = Single Host vSphere Supervisor: one ESX host per site. vSphere HA stays ENABLED; HA ADMISSION CONTROL is what must be disabled. 'Disable vSphere HA' is a wrong answer.
• Pattern 3 = Locally Managed Edge: management domain sits NEAR the edge and one local vCenter runs both management and workloads — the autonomy/WAN-outage-resilience choice, versus Patterns 1/2/6/8 where the WAN is on the management critical path.
• Pattern 7 = Supervisor Zonal: 2-host cluster per zone x 2 zones = 4 hosts per site, external storage, no vSAN, and management located AT the edge.
• Pattern 9 = Far Edge Expansion: VCF Operations does licensing and monitoring ONLY — it explicitly does NOT perform LCM of that vCenter or its hosts.
• VCF Edge is the rename of pre-9.0 'Remote Clusters'. Entitlement gates: 10+ sites, 8+ cores per host, 256 cores per site max, and VCF Operations is mandatory for Edge licensing.
• Defence trap: 'thin edge' has two incompatible definitions (Pattern 6 = 2-host inside full stack; Option 2 = 2-node vSAN without full stack), and 'thick edge' has NO documented host count.

VCF Management Operations (Objective 4.2)#

Blueprint Objective 4.2 — VCF: Manage

Fleet Management Capabilities in VCF Operations (Obj 4.2)

VCF Operations is the unified management plane for VCF 9.0. It replaces SDDC Manager with expanded fleet-level capabilities.

Fleet Management Functions:

├── Instance Overview: Dashboard showing all managed VCF instances
├── Inventory Sync: Automatic inventory collection every 5 minutes
├── Cross-Instance Policy: Push DFW rules, compliance policies across instances
├── Workload Migration: Orchestrate HCX migrations between instances
├── Centralized Reporting: Consolidated license usage, capacity, compliance
└── Fleet Health: Aggregated health status across all instances

VCF Operations Dashboard Features:

├── Private Cloud status (management + workload domains)
├── Host inventory (free pool, commissioned, decommissioned)
├── Certificate status (expiry timeline, rotation history)
├── Password rotation status (auto-rotated vs manual)
├── Lifecycle management (bundle availability, upgrade readiness)
└── Alert center (cross-component alerts from vCenter, NSX, vSAN)

Identity Management & RBAC (Obj 4.2)

VCF Identity Architecture:

├── Local Users: Built-in user database (administrator@vcf.local)
├── Active Directory/LDAP: External identity source integration
│   ├── LDAP over SSL (port 636) recommended for production
│   ├── User/group sync: Automatic, configurable interval
│   └── Nested group support: Yes (up to 5 levels)
├── SAML 2.0: Federation with enterprise IdP (Okta, Azure AD, ADFS)
│   ├── SP-initiated SSO: User clicks login → redirected to IdP
│   ├── Attribute mapping: IdP groups → VCF roles
│   └── Session timeout: Configurable (default 8 hours)
└── OAuth 2.0: API client authentication (machine-to-machine)

RBAC Roles in VCF:

├── System Administrator: Full access to VCF Operations, all Private Clouds, all operations
├── Cloud Administrator: Manage specific Private Clouds (workload domains)
├── Network Administrator: NSX configuration, segment management, DFW policies
├── Security Administrator: Certificate management, password rotation, compliance
├── Operator: Read-only access to dashboards and reports
├── Service Account: API-only access for automation tools
└── Custom Roles: Granular permission sets (create via VCF Operations API)

Role Assignment:

├── VCF Operations UI → Administration → Access Control → Users & Groups
├── Assign roles at: Instance level, Private Cloud level, or Cluster level
├── Principle of Least Privilege: Assign minimum required role
└── Audit: All role changes logged in VCF Operations audit trail

License Management (Obj 4.2)

VCF Licensing Model (post-Broadcom acquisition):

├── Subscription-based: Per-core licensing (replaced perpetual per-socket model). Minimum 16 cores per physical CPU. License assigned to vCenter instances — connected ESXi hosts licensed automatically
├── License Keys: Applied at VCF Operations level (covers entire instance)
├── Component Licenses: vSphere, vSAN, NSX bundled in VCF license
├── License Tiers:
│   ├── VCF Standard: vSphere + vSAN + NSX (base)
│   ├── VCF Advanced: + VCF Operations + VCF Automation
│   └── VCF Enterprise: + Fleet Manager + Avi ALB + advanced features
├── License Compliance: VCF Operations tracks core count vs entitlement
└── Expiry Management: VCF Operations alerts 90/60/30 days before expiry

License Operations in VCF Operations:

├── Add License: VCF Operations → Administration → Licensing → Add License Key
├── Assign License: Automatically applied to all hosts in instance
├── View Usage: Dashboard shows cores consumed vs entitled
├── Export Report: License compliance report (PDF/CSV) for audit
└── Renewal: Replace license key before expiry (no downtime)

Certificate Management (Obj 4.2)

VCF Certificate Architecture:

├── VCF CA: Built-in Certificate Authority (issues certificates for all VCF components)
├── External CA: Microsoft CA, DigiCert, Let's Encrypt (enterprise option)
├── Component Certificates:
│   ├── vCenter: Server certificate + machine SSL certificate
│   ├── NSX Manager: Cluster certificate + API certificate
│   ├── ESXi: Host certificate (signed by VCF CA or external CA)
│   ├── VCF Operations: Appliance certificate
│   └── Edge Nodes: Tunnel endpoint certificates
└── Certificate Chain: Root CA → Intermediate CA (optional) → Leaf certificates

Certificate Rotation:

├── VCF Operations → Security → Certificates → view all component certificates
├── Auto-rotation: VCF Operations can auto-rotate certificates approaching expiry (configurable threshold)
├── Manual rotation: Select component → Rotate → specify CA → generate CSR or auto-sign
├── Impact: Certificate rotation may cause brief API interruption (seconds)
│   ├── vCenter: Rolling restart of vpxd service
│   ├── NSX: API unavailable for ~30 seconds during rotation
│   ├── ESXi: Host reconnects to vCenter after cert update
│   └── VCF Operations: Self-restart after own certificate rotation
├── Validation: VCF Operations validates certificate chain, key length (2048+ RSA), expiry
├── Auto-renewal (VCF Operations Fleet Management): automatic renewal happens 60 DAYS before certificate expiration, for VMCA / Microsoft CA / OpenSSL / self-signed certs on components that support non-disruptive update. Shipped in VCF 9.0.2 (KB 427937).
├── vCenter-NATIVE behaviour is different and fixed: Machine SSL auto-renews 5 days before expiry; ESXi SSL 10 days (vpxd.certmgmt.certs.autoRenewThreshold); a pre-expiration ALARM fires at 30 days. In VCF 9.1 the ESX value is documented as 30 days — version-scope it.
├── External-CA certificates are NEVER auto-renewed, and auto-renew is inoperative when vpxd.certmgmt.mode=custom
└── Do not confuse ALERTING with RENEWAL: the 90/60/30-day figures elsewhere are licence-expiry alerts, not certificate renewal

Password Management (Obj 4.2)

VCF Password Architecture:

├── Credential Vault: VCF Operations stores all component credentials securely (encrypted at rest)
├── Managed Accounts:
│   ├── ESXi root passwords (per-host)
│   ├── vCenter administrator@vsphere.local
│   ├── NSX admin
│   ├── VCF Operations admin
│   ├── Service accounts (SDDC Manager service, backup accounts)
│   └── vSAN witness passwords
├── Auto-rotation: VCF Operations rotates managed passwords on schedule
│   ├── Default interval: 90 days (configurable per-account)
├── Password length is PER COMPONENT, not one global rule: SDDC Manager vcf/root/backup min 12; SDDC Manager admin@local 15-127; vCenter root min 15; administrator@vsphere.local 8-20; ESX root 7-40; NSX root/admin/audit 12-128; VCF Operations root/admin(OS) min 15, admin(app) min 8; VCF Automation min 15. SDDC-Manager-GENERATED rotated passwords are exactly 20 characters. VCF 9.1 adds fleet/instance-scoped password policies but publishes no new default length
│   ├── History: Last 5 passwords cannot be reused
│   └── Notification: VCF Operations alerts before rotation (email/webhook)
├── Manual rotation: VCF Operations UI → Security → Passwords → select account → Rotate
└── Password Retrieval: VCF Operations UI → Passwords → click 'Show' (requires admin role)

Password Rotation Considerations:

├── Coordinate with backup schedules (backup credentials may need update)
├── Update external integrations (monitoring tools, scripts using rotated credentials)
├── Test after rotation: Verify all component connectivity
├── Lockout prevention: VCF Operations coordinates rotation to avoid lock-out cascades
└── Emergency: Reset password via VCF Operations CLI if GUI inaccessible

Holodeck Lab Note: In Holodeck, VCF Operations password rotation can be tested safely. Use the VCF Operations UI to rotate ESXi root passwords across Holodeck hosts. Verify connectivity after rotation by SSH-ing with new credentials. Certificate rotation in Holodeck uses self-signed VCF CA (acceptable for lab).

Key Takeaways

• Exam: VCF Operations provides fleet-level management — inventory sync, cross-instance policy, centralized reporting. Know VCF Operations dashboard components.
• Exam: RBAC roles — System Admin (full access), Cloud Admin (per-PC), Network Admin (NSX), Security Admin (certs/passwords). Assign at instance or PC level.
• Exam: Certificate auto-renewal in VCF Operations fires 60 DAYS before expiry (VCF 9.0.2+). vCenter-native auto-renew is separate and fixed: Machine SSL 5 days, ESXi SSL 10 days, with a 30-day pre-expiry alarm. External-CA certs never auto-renew. Alerting is not renewal.
• Exam: Password auto-rotation — 90-day default, 14-char complexity, last 5 history. Credential vault stores all managed passwords encrypted.

VCF Operations & Observability (Objective 4.3)#

Blueprint Objective 4.3 — VCF: Operate

VCF Network Operations & Operations for Logs (Obj 4.3)

VCF Operations in VCF context includes deeper integration than VVF — specifically NSX adapter, network topology visualization, and cross-component correlation.

VCF Operations — VCF-Specific Capabilities:

├── NSX Adapter: Collects NSX Manager metrics and topology
│   ├── Metrics: Firewall rule hit count, segment traffic, Edge throughput
│   ├── Topology: Tier-0/Tier-1/Segment hierarchy visualization
│   ├── Flow analysis: East-west traffic patterns between segments
│   └── DFW analytics: Most/least used rules, shadow rule detection
├── VCF Operations Manager Adapter: Collect VCF Operations health and lifecycle data
├── Cross-Component Correlation:
│   ├── VM slow → check host CPU (vCenter) → check segment congestion (NSX) → check vSAN latency
│   ├── Unified timeline: Correlate events across vCenter, NSX, vSAN in single view
│   └── Root cause analysis: Automated symptom-to-cause chain
└── Capacity Planning:
    ├── Demand forecasting: Predict when cluster needs additional hosts
    ├── What-if analysis: Model adding hosts or VMs before commitment
    ├── Reclaimable resources: Identify oversized VMs (CPU/memory waste)
    └── Cost optimization: Right-size recommendations with savings estimate

VCF Operations Cluster Components & Deployment (Obj 4.3):

├── Analytics Node: Processes collected data (metrics, events, alerts)
├── Collector Node: Gathers data from adapters (vCenter, NSX, vSAN, VCF Operations)
├── Remote Collector: For distributed data centers (reduces WAN bandwidth)
├── Data Node: Time-series database (TSDB) for metric storage
├── Sizing (VCF):
│   ├── Small (up to 4,000 objects): 1 node (4 vCPU, 16GB, 512GB)
│   ├── Medium (up to 20,000 objects): 2-node cluster + remote collector
│   ├── Large (up to 100,000 objects): Multi-node cluster + data nodes
│   └── Note: VCF typically has more objects than VVF due to NSX (segments, DFW rules, Edge nodes)
└── HA: Analytics node HA (active-passive) recommended for production

VCF Operations for Logs — VCF-Specific (Obj 4.3):

├── Log Sources (beyond VVF):
│   ├── NSX Manager logs: Control plane events, DFW rule changes, policy updates
│   ├── NSX Edge logs: Routing changes, NAT translations, LB health
│   ├── VCF Operations logs: Lifecycle operations, host commissioning, bundle downloads
│   └── VCF Automation logs: Blueprint deployments, catalog requests, ABX actions
├── Content Packs:
│   ├── NSX Content Pack: Pre-built dashboards for NSX events
│   ├── VCF Content Pack: VCF Operations operations dashboard
│   └── vSAN Content Pack: Storage-specific log analysis
└── Integration: Bidirectional with VCF Operations (launch-in-context between metrics and logs)

Differentiate Metrics, Properties, and Logs (Obj 4.3):

Metrics:

├── Definition: Numeric, time-series data collected at regular intervals
├── Examples: CPU usage %, memory consumed MB, disk IOPS, NSX firewall throughput
├── Collection: Every 5 minutes (default), stored in TSDB
├── Use: Trending, alerting, capacity planning, anomaly detection
└── Retention: 5-min granularity (24h), 1-hour (1 month), 1-day (1 year)

Properties:

├── Definition: Configuration attributes — static or slowly changing
├── Examples: VM name, ESXi version, NSX segment name, vSAN disk type
├── Collection: On inventory sync (every 5 min for changes)
├── Use: Grouping, filtering, compliance, inventory views
└── Retention: Current value + history of changes

Logs:

├── Definition: Unstructured text events with timestamps
├── Examples: "DFW rule 1024 applied to VM web-01", vpxd error stack trace
├── Collection: Real-time syslog ingestion (UDP 514, TCP 1514, TLS 6514)
├── Use: Root cause analysis, forensics, audit trail, security investigation
└── Retention: 30 days default (configurable, archive to NFS/S3)

Custom Views, Reports & Dashboards (Obj 4.3):

Custom Views:

├── List View: Tabular display of objects with metrics columns
├── Summary View: Aggregated statistics (avg, max, min, count)
├── Trend View: Time-series chart for selected metrics
├── Distribution View: Histogram of metric values across objects
├── Filters: Object type, property value, tag, custom group
└── Export: CSV, PDF, schedule email delivery

Reports:

├── Pre-built Templates: Capacity, Performance, Compliance, Cost
├── Custom Reports: Combine multiple views + charts + text
├── Scheduling: Daily, weekly, monthly auto-generation
├── Format: PDF or CSV export
└── Distribution: Email to stakeholders, archive to shared storage

Dashboard Creation:

├── Widget Types: Scoreboard, heatmap, top-N, trend, alert list, object relationship
├── Widget Interactions: Click-to-filter across widgets (host → VMs, cluster → hosts)
├── Sharing: Per-user/group, read-only or edit, import/export as JSON
└── Content Packs: Pre-built dashboards (vSAN, NSX, K8s, VCF Operations)

Alerting & Notifications (Obj 4.3):

├── Symptom: Single condition (metric threshold + duration)
├── Alert Definition: One or more symptoms with AND/OR logic
├── Criticality: Info, Warning, Immediate, Critical
├── Notification: Email (SMTP), webhook (REST), SNMP trap, Slack/PagerDuty
├── Recommendation: Suggested remediation steps attached to alert
└── Alert Lifecycle: New → Acknowledged → Resolved (manual or auto-clear)

Costing & Chargeback (Obj 4.3):

├── Rate Cards: Define cost per resource unit ($/vCPU/month, $/GB storage/month)
├── Cost Drivers: Server hardware, storage, network, licensing, power/cooling
├── Chargeback: Bill business units based on actual VM resource consumption
├── Showback: Display costs without billing (awareness mode)
├── Reports: Cost per VM, per department, per Private Cloud, trend analysis
└── Setup: VCF Operations → Administration → Cost Settings → Rate Card Editor

Policies & Compliance (Obj 4.3):

├── Operational Policies: Define thresholds per object type/group
│   ├── Capacity: Alert when remaining capacity < N days
│   ├── Utilization: Alert on sustained over/under utilization
│   └── Override: Per-object policy customization
├── Compliance Benchmarks:
│   ├── CIS ESXi 8 Benchmark: 100+ configuration checks
│   ├── DISA STIG for vSphere: DoD security requirements
│   ├── PCI-DSS: Payment card industry requirements
│   └── Custom: Define organization-specific compliance rules
├── Compliance Dashboard: Per-host/cluster green/yellow/red status
├── Drift Detection: Alert when configuration deviates from baseline
└── Remediation: Recommended esxcli/PowerCLI commands for non-compliant items

Application Monitoring & Service Discovery (Obj 4.3):

├── Service Discovery: Auto-detect applications in VMs
│   ├── Discovers: Web servers (Apache, Nginx, IIS), databases (MySQL, PostgreSQL, Oracle), app servers (Tomcat, JBoss)
│   ├── Method: Agentless (port scan + protocol detection) or agent-based (Telegraf)
│   └── Output: Application → VM → Host → Cluster dependency map
├── Application-Aware Monitoring:
│   ├── Response time, throughput, error rate per application
│   ├── Dependency visualization (which VMs serve which applications)
│   └── Impact analysis: If host fails, which applications are affected?
└── Integration: ServiceNow CMDB, Slack notifications, PagerDuty alerts

vSAN Storage Operations (Obj 4.3):

├── Deep vSAN Monitoring: Disk health, rebuild progress, dedup/compression ratio
├── Capacity Forecasting: Predict when vSAN needs additional disks/hosts
├── Performance Monitoring: Per-disk group latency, IOPS, throughput
├── Health Correlation: vSAN health → VM performance impact analysis
└── Alerts: Disk failure prediction, congestion warning, capacity threshold

Holodeck Lab Note: VCF Operations in Holodeck can monitor all nested components including NSX Manager (add NSX adapter with NSX Manager IP and credentials). The NSX adapter enables network topology dashboards and DFW analytics. Install NSX Content Pack from VMware Marketplace for pre-built NSX dashboards.

Key Takeaways

• Exam: VCF Operations in VCF adds NSX adapter (DFW analytics, network topology), VCF Operations adapter, and cross-component correlation. Know these VCF-specific capabilities.
• Exam: Metrics = numeric time-series (CPU %, IOPS). Properties = config attributes (VM name, ESXi version). Logs = text events (syslog). Know the differences.
• Exam: Dashboards use widgets with interactions (click-to-filter). Reports combine views + charts. Both support scheduling and sharing.
• Exam: Compliance = CIS/DISA STIG benchmarks. Costing = rate cards + chargeback/showback. Service Discovery = auto-detect apps in VMs.

VCF Automation — Consume & Automate (Objective 4.4)#

Blueprint Objective 4.4 — VCF: Consume and Automate

VCF Automation Use Case (Obj 4.4)

VCF Automation (formerly vRealize Automation / Aria Automation) is the self-service and governance platform in VCF. It is NOT included in VVF — it's a VCF-only capability.

VCF Automation Purpose:

├── Self-Service Portal: Developers request infrastructure via catalog
├── Cloud Templates: Infrastructure-as-Code (YAML) for multi-cloud deployments
├── Governance: Approval workflows, cost controls, lease management
├── Day-2 Operations: Automated resize, snapshot, backup, decommission
├── Multi-Cloud: Deploy to vSphere, AWS, Azure, GCP from single catalog
└── Extensibility: ABX (Action Based Extensibility) for custom logic

VCF Automation Components & Deployment (Obj 4.4):

Architecture:

├── Cloud Assembly: Template design and deployment engine
│   ├── Cloud Accounts: Connections to vCenter, NSX, AWS, Azure
│   ├── Cloud Zones: Compute/storage placement policies
│   ├── Flavor Mappings: VM sizing (small=2vCPU/4GB, medium=4vCPU/8GB)
│   ├── Image Mappings: OS images per cloud (e.g., ubuntu → vSphere template + AWS AMI)
│   └── Network Profiles: Network assignment per cloud zone
├── Service Broker: Catalog management and request processing
│   ├── Catalog Items: Published cloud templates available to consumers
│   ├── Content Sources: Cloud Assembly, VCF Orchestrator, external sources
│   ├── Entitlements: Who can request what (user/group → catalog item)
│   └── Policies: Approval, lease, naming, placement enforcement
├── VCF Orchestrator: Workflow engine for automation
│   ├── Pre-built Workflows: VM lifecycle, NSX config, vSAN management
│   ├── Custom Workflows: JavaScript/Python actions, drag-and-drop designer
│   ├── Event-Based Triggers: Deploy hook, post-provision, on-delete
│   └── Integration: REST API, SSH, PowerShell, SNMP
└── Deployment:
    ├── VCF Automation appliance: 12 vCPU, 48GB RAM, 200GB disk
    ├── Clustered: 3-node cluster for HA (recommended for production)
    ├── Integrated: Deployed and managed via VCF Operations
    └── Access: https://<automation-fqdn>/cloud

Configure Region (Obj 4.4):

Regions in VCF Automation:

├── Definition: A region maps to a VCF instance or cloud provider region
│   ├── vSphere Region: Maps to a vCenter + associated NSX + vSAN
│   ├── AWS Region: Maps to an AWS region (us-east-1, eu-west-1)
│   ├── Azure Region: Maps to an Azure region (eastus, westeurope)
│   └── GCP Region: Maps to a GCP region (us-central1, europe-west1)
├── Purpose: Enable multi-region deployment with placement policies
├── Configuration:
│   ├── Add Cloud Account (vCenter connection with credentials)
│   ├── Associate cloud zones to region (which clusters serve this region)
│   ├── Configure capability tags (e.g., "tier:gold", "location:dc-a")
│   └── Map regions to projects (which teams can deploy to which regions)
└── Use Case: "Deploy my app to the nearest VCF instance" → region selection

Configure Multi-Organizational Tenancy (Obj 4.4):

Multi-Tenancy in VCF Automation:

├── Organizations: Top-level isolation boundary
│   ├── Each org has its own: users, projects, cloud accounts, catalog, policies
│   ├── Data isolation: Org A cannot see Org B's deployments
│   └── Use case: MSP (Managed Service Provider) hosting multiple customers
├── Projects: Resource boundary within an organization
│   ├── Members: Users/groups assigned to project with roles
│   ├── Roles: Administrator, Member, Viewer
│   ├── Resource Limits: Max VMs, max CPU, max memory, max storage
│   ├── Cloud Zones: Which compute resources this project can use
│   └── Naming Convention: Project-level naming template (e.g., ${project}-${resource}-${count})
├── Custom Naming: Template-driven resource naming
│   ├── Variables: ${project}, ${resource}, ${org}, ${user}, ${count}
│   ├── Example: "prod-web-${count}" → prod-web-001, prod-web-002
│   └── Uniqueness: VCF Automation ensures no name collisions
└── Lease Management:
    ├── Lease Duration: Auto-delete deployment after N days (prevent sprawl)
    ├── Warning: Email notification before lease expiry
    ├── Extension: User can request extension (requires approval if policy set)
    └── Default: No lease (deployments persist until manually deleted)

Configure Provider Networking (Obj 4.4):

Provider Networking in VCF Automation:

├── Network Profiles: Define how deployments get network connectivity
│   ├── Existing Networks: Use pre-created NSX segments or vDS port groups
│   ├── On-Demand Networks: VCF Automation creates NSX segments dynamically
│   │   ├── Routed: Connected to Tier-1 gateway (internet-accessible)
│   │   ├── Isolated: No external connectivity (internal communication only)
│   │   └── Outbound-only: NAT for outbound, no inbound (security zones)
│   └── Private Networks: Isolated per deployment (multi-NIC VMs)
├── IP Address Management (IPAM):
│   ├── Internal IPAM: VCF Automation manages IP pools
│   ├── External IPAM: Integration with Infoblox, BlueCat
│   └── IP Ranges: Define start/end IP per network profile
├── Load Balancer Integration:
│   ├── NSX LB: Tier-1 L4/L7 load balancing
│   ├── Avi ALB: Advanced L7 with WAF, analytics
│   └── Cloud Template: LB defined as resource in YAML template
├── Security Groups: NSX security groups applied to deployed VMs
│   ├── Existing Groups: Reference pre-created NSX security groups
│   ├── On-Demand Groups: Created per-deployment with DFW rules
│   └── Tag-Based: VMs automatically added to groups via tags
└── DNS Integration: Auto-create DNS records for deployed VMs

Cloud Templates (Obj 4.4):

Cloud Template YAML Example:

formatVersion: 1
inputs:
  size:
    type: string
    enum: [small, medium, large]
    default: small
  count:
    type: integer
    default: 1
resources:
  web-server:
    type: Cloud.vSphere.Machine
    properties:
      image: ubuntu-2204
      flavor: ${input.size}
      count: ${input.count}
      networks:
        - network: ${resource.web-network.id}
      customizationSpec: linux-cloud-init
      cloudConfig: |
        packages:
          - nginx
        runcmd:
          - systemctl enable nginx
          - systemctl start nginx
  web-network:
    type: Cloud.NSX.Network
    properties:
      networkType: routed
      constraints:
        - tag: env:production

Cloud Template Capabilities:

├── Inputs: User-provided parameters (dropdowns, text, numbers)
├── Resources: Infrastructure objects (VMs, networks, LBs, disks)
├── Constraints: Tag-based placement (match cloud zone capability tags)
├── cloud-init: Guest OS customization (packages, scripts, users)
├── Iterations: count property for multi-instance deployment
├── Dependencies: Implicit (resource references) and explicit (dependsOn)
└── Version Control: Templates versioned in Git (GitOps integration)

Approval Policies:

├── Pre-Approval: Required before deployment starts
│   ├── Approvers: Named users or group
│   ├── Conditions: Based on cost, VM count, network type
│   └── Timeout: Auto-deny after N days if not approved
├── Day-2 Approval: Required for resize, reconfigure, delete operations
└── Integration: Email notification, Slack webhook, ServiceNow ticket

Holodeck Lab Note: VCF Automation can be deployed in Holodeck but requires significant resources (12 vCPU, 48GB RAM per appliance). For lab purposes, single-node deployment is acceptable. Configure a vCenter cloud account pointing to the Holodeck vCenter. Create simple cloud templates that deploy VMs to the Holodeck cluster. On-demand NSX networks require NSX integration configured in VCF Operations.

Key Takeaways

• Exam: VCF Automation = Cloud Assembly (templates) + Service Broker (catalog) + Orchestrator (workflows). VCF-only, not in VVF.
• Exam: Regions map to VCF instances or cloud provider regions. Cloud zones within regions define placement. Capability tags drive placement decisions.
• Exam: Multi-tenancy = Organizations (isolation) → Projects (resource limits, members, cloud zones). Lease management prevents VM sprawl.
• Exam: Provider networking = existing, on-demand (routed/isolated/outbound), private networks. IPAM internal or external (Infoblox). Security groups via NSX.
• Exam: Cloud templates (YAML) — inputs, resources, constraints, cloud-init. Approval policies enforce governance. Version control via Git.

VCF Troubleshooting Methodology & Scenarios (Objectives 4.1, 4.6, 4.7, 4.8)#

The VCF Admin exam Section 4 tests practical troubleshooting across all VCF layers. This theory covers the troubleshooting methodology and common scenarios for vSphere networking, VCF lifecycle management, VCF Operations, and VCF Automation.

General Troubleshooting Methodology

VCF troubleshooting follows a layered approach: identify symptoms → isolate the layer (physical/virtual/application) → gather diagnostic data → correlate events across components → remediate → validate fix → document root cause.

Tools by Layer: Physical network (switch CLI, cable tester, LLDP/CDP), vSphere networking (esxtop, packet capture, net-stats), NSX overlay (Traceflow, Central CLI, transport node status), vSAN (vSAN Health Service, vSAN Observer, esxtop for disk stats), SDDC Manager (API /v1/tasks, /v1/system, lcm logs), VCF Operations (dashboards, alerts, super metrics, log queries), VCF Automation (deployment history, event logs, extensibility action logs).

Objective 4.1 — Troubleshoot vSphere Networking Issues

esxtop Network Counters: Launch esxtop on ESXi host, press 'n' for network view. Critical counters:

%DRPTX / %DRPRX (Dropped Transmit / Receive): Packets dropped at the vNIC or pNIC level. Values > 0.01% indicate contention or misconfiguration. Cause: ring buffer exhaustion, MTU mismatch, uplink saturation. Fix: increase ring buffer (ethtool -G vmnicX rx 4096), verify MTU end-to-end, check uplink utilization.

MbTX / MbRX (Megabits Transmitted / Received): Throughput per vNIC/pNIC. Compare against link speed — if MbTX approaches link capacity, the NIC is saturated. Fix: add uplinks, enable LACP, or redistribute VMs across hosts.

USED-BY: Shows which port group and VM is using each vNIC. Essential for mapping traffic to physical uplinks during troubleshooting.

Troubleshoot Network — Common Scenarios:

Scenario 1: vMotion fails with "migration to host X failed with error timed out." Diagnostic steps: (1) Verify vMotion VMkernel adapter exists on both source and destination hosts. (2) Check vMotion network connectivity: vmkping -I vmkX <dest-vMotion-IP>. (3) Verify MTU consistency — if jumbo frames enabled on one side but not the other, large packets are silently dropped. (4) Check vMotion TCP port 8000 is not blocked by physical firewall. (5) Verify EVC mode compatibility if hosts have different CPU generations.

Scenario 2: VM loses network connectivity after adding to new port group. Diagnostic steps: (1) Verify VLAN ID on port group matches physical switch trunk configuration. (2) Check uplink teaming policy — active/standby vs LACP. (3) Verify security policy settings (promiscuous mode, MAC changes, forged transmits) if VM uses nested virtualization or load balancer VIPs. (4) Use packet capture on ESXi: pktcap-uw --uplink vmnic0 --dir 0 -o /tmp/capture.pcap. (5) Check DVS health check for VLAN/MTU mismatches.

Scenario 3: Intermittent packet loss on overlay network. Diagnostic steps: (1) Verify MTU 9000 end-to-end from ESXi TEP → physical switch → destination TEP. Use vmkping -d -s 8972 -I vmkX <dest-TEP>. (2) Check TEP connectivity via nsxcli on transport node: get logical-switch transport-node-table. (3) Verify BFD status between TEPs. (4) Check physical switch for CRC errors or interface resets on uplink ports.

Objective 4.6 — Troubleshoot VCF Lifecycle Management Issues

SDDC Manager LCM Architecture: Lifecycle operations (upgrades, host commissioning, domain creation) are executed as asynchronous tasks. Each task has sub-tasks that execute sequentially. If a sub-task fails, the parent task enters ERROR state. Logs location: /var/log/vmware/vcf/lcm/ on SDDC Manager appliance.

Bundle Download Failures: Symptoms: bundle download stuck at 0% or fails with timeout. Diagnostic steps: (1) Verify SDDC Manager has internet connectivity to Broadcom depot (depot.vmware.com). Test: curl -v https://depot.vmware.com. (2) Check proxy configuration if behind corporate proxy: /opt/vmware/vcf/sddc-manager/proxy.properties. (3) Verify DNS resolution of depot hostname. (4) Check disk space on SDDC Manager — bundles can be 10-50GB. (5) For air-gapped environments: verify offline bundle was downloaded correctly (checksum validation) and uploaded via SDDC Manager API.

Bundle Apply / Upgrade Failures: Symptoms: upgrade task shows ERROR status in SDDC Manager UI. Diagnostic steps: (1) Check task details via API: GET /v1/tasks/{task-id} — shows which sub-task failed. (2) Read LCM logs: /var/log/vmware/vcf/lcm/lcm.log — search for ERROR or EXCEPTION. (3) Common failures: pre-check validation failed (host not in maintenance mode, incompatible version), SSH connectivity lost to ESXi host during upgrade, vCenter upgrade failed (insufficient disk space, service restart timeout). (4) Fix: resolve the specific pre-check failure, then retry the task via API: PATCH /v1/tasks/{task-id} with action RETRY.

SDDC Manager Error States: Common error patterns and resolution:

"Host commission failed — cannot reach host via SSH": Verify ESXi host has correct management IP, SSH service is running (esxcli system service list | grep SSH), and no firewall blocks port 22 between SDDC Manager and host.

"Workload domain creation failed — insufficient resources": vSAN cluster formation requires minimum 4 hosts with compatible storage. Verify all hosts have correct disk configuration, no existing VMFS partitions on vSAN-designated disks, and hosts are in the SDDC Manager inventory with UNASSIGNED status.

"Upgrade pre-check failed — compatibility issue": SDDC Manager validates version compatibility matrix. If a component is at an unexpected version (manual upgrade outside SDDC Manager), the matrix check fails. Fix: verify all component versions via API GET /v1/system, update the interop matrix, or perform manual remediation per KB article.

LCM Retry and Rollback: Most LCM tasks support retry after failure remediation. For ESXi rolling upgrades, if one host fails, the remaining hosts are untouched — fix the failed host and retry. For vCenter upgrade failure: restore from pre-upgrade snapshot (taken automatically by SDDC Manager). For NSX upgrade failure: check NSX Manager cluster health, restore individual node if needed.

Objective 4.7 — Troubleshoot VCF Operations Issues

VCF Operations Adapter Troubleshooting: Adapters collect metrics from managed infrastructure. Common failures:

Adapter Collection Failure: Symptoms: metrics stop updating for specific objects (vCenter, NSX, vSAN). Dashboard shows stale data. Diagnostic steps: (1) Check adapter status in VCF Operations UI → Administration → Solutions → adapter instance → check connection status. (2) Verify credentials — if vCenter password changed, adapter loses connectivity. Fix: update credentials in adapter configuration. (3) Test API connectivity from VCF Operations VM to target: curl -k https://vcenter.lab.local/rest/com/vmware/cis/session. (4) Check VCF Operations logs: /var/log/vmware/vcf-operations/collector/. (5) Restart adapter: Administration → Solutions → select adapter → Manage → Restart.

Alert Configuration Failures: Symptoms: alerts not firing despite threshold breaches, or false-positive alerts flooding notification channels. Diagnostic steps: (1) Verify alert definition: correct metric, correct threshold, correct comparison operator. Common mistake: setting "greater than 80" when metric reports as decimal (0.80 vs 80). (2) Check alert scope — is it applied to the correct object type (VM, host, cluster)? (3) Verify notification channel: test email/webhook connectivity. Common failure: SMTP relay blocks VCF Operations IP. (4) Check alert suppression rules — an overly broad suppression may silence legitimate alerts. (5) For false positives: adjust threshold or add hysteresis (sustained condition duration before firing).

Metric Collection Gaps: Symptoms: gaps in metric graphs, "no data" for specific time periods. Causes: VCF Operations maintenance/restart during collection window, network connectivity interruption to monitored infrastructure, resource exhaustion on VCF Operations node (CPU/disk). Fix: verify VCF Operations node health, check disk space (metric storage can fill up), verify collection interval settings.

Troubleshoot Operations — Log Analysis: VCF Operations for Logs (formerly vRealize Log Insight / Aria Operations for Logs) centralizes syslog from all VCF components. Troubleshooting steps: (1) Verify syslog forwarding from ESXi hosts: esxcli system syslog config get. (2) Check log ingestion rate — if rate exceeds node capacity, logs are dropped. Scale with additional nodes. (3) Use structured queries to correlate events: filter by timestamp + hostname + severity to isolate incidents. (4) Create log-based alerts for critical patterns: "PSOD", "vSAN object lost", "NSX controller disconnected".

Objective 4.8 — Troubleshoot VCF Automation Issues

Deployment Failures: Symptoms: cloud template deployment fails or hangs in "CREATE_IN_PROGRESS" state. Diagnostic steps: (1) Check deployment details in VCF Automation UI → Deployments → select failed deployment → History tab → expand failed step. (2) Common failure: "No matching placement found" — the constraint tags in the cloud template don't match any cloud zone capability tags. Fix: verify cloud zone tags match template constraints. (3) "Resource quota exceeded" — project has reached CPU/memory/storage limit. Fix: increase quota or remove unused deployments. (4) "Network provisioning failed" — on-demand NSX network creation failed. Check NSX cloud account connectivity and network profile IP range availability. (5) Check extensibility action logs if ABX actions are configured — custom code failures block deployment pipeline.

Template Errors: Cloud template (YAML) errors are caught at design time or deployment time.

Design-time errors: Syntax validation in Cloud Assembly canvas. Common issues: incorrect indentation (YAML is whitespace-sensitive), invalid resource type reference, missing required property (e.g., image or flavor not specified), constraint tag syntax error.

Deployment-time errors: Template validates but fails during provisioning. Common issues: flavor mapping doesn't exist in target cloud zone (e.g., "small" flavor not defined), image mapping references non-existent template/OVA, network profile has no available IP addresses in the range, storage profile references non-existent vSAN policy.

Troubleshoot Automation — Integration Failures:

vCenter Cloud Account: "Failed to validate cloud account" — verify vCenter API endpoint URL, service account credentials, and network connectivity from VCF Automation appliance to vCenter (port 443). Check if vCenter certificate has changed (re-accept certificate in cloud account config).

NSX Cloud Account: "NSX integration failed" — verify NSX Manager VIP is reachable, credentials are valid, and NSX Manager version is compatible with VCF Automation version. Check if NSX Manager certificate chain is trusted.

Active Directory Integration: "User sync failed" — verify LDAP connectivity (port 389/636), bind DN credentials, base DN configuration. Test with ldapsearch command from VCF Automation appliance.

Custom Form Rendering: "Form not loading" — verify custom form JSON schema is valid, all referenced fields exist in the cloud template inputs section, and conditional visibility rules have correct syntax.

Troubleshoot Automation — Performance: Slow deployments often caused by: (1) VCF Automation database growth — PostgreSQL vacuum and index maintenance needed. (2) Large number of concurrent deployments exceeding appliance capacity. (3) Extensibility actions with external API calls timing out. (4) Event subscription backlog — check event broker queue depth.

Key Takeaways

• Obj 4.1: esxtop 'n' view for network troubleshooting — watch %DRPTX/%DRPRX (drops), MbTX/MbRX (throughput), USED-BY (VM-to-pNIC mapping). vMotion failures: check VMkernel adapter, MTU consistency, port 8000, EVC mode.
• Obj 4.6: SDDC Manager LCM troubleshooting — logs at /var/log/vmware/vcf/lcm/, bundle failures (connectivity/proxy/disk), upgrade failures (check sub-task via API, pre-check remediation, vCenter snapshot rollback), retry failed tasks via PATCH API.
• Obj 4.7: VCF Operations troubleshooting — adapter collection failures (credentials, API connectivity, restart adapter), alert misfire (threshold units, scope, notification channel), metric gaps (disk space, node health, collection interval).
• Obj 4.8: VCF Automation troubleshooting — deployment failures (placement mismatch, quota exceeded, network provisioning), template errors (YAML syntax, missing flavor/image mapping, IP range exhaustion), integration failures (cloud account validation, certificate trust, LDAP connectivity).
• Cross-cutting: Always correlate timestamps across SDDC Manager tasks, vCenter events, NSX audit log, and VCF Operations alerts to build a unified incident timeline.