Key Concepts
Review these important points before starting the quiz
Workload domains are isolation boundaries: Separate lifecycle management, fault isolation, and operational independence
Management Domain is sacred: Never mix application workloads with platform services to protect lifecycle stability
Purpose over capacity: Design workload domains around business purpose, not just resource availability
Lifecycle blast radius: Unrelated workloads in the same domain share upgrade and failure impact
Multiple VCF instances: Driven by organizational, regulatory, or sovereignty boundaries requiring strong separation
Consolidated vs separated: Trade isolation for operational simplicity, or separate for stronger boundaries
Regional designs: Driven by data sovereignty, latency requirements, and regulatory compliance
Availability zones (AZ): Define failure domains and recovery expectations early in design
Workload mobility: Align workloads with lifecycle boundaries to enable flexibility without upgrade impact
Management Domain role: Anchors platform lifecycle and control plane, must remain stable
Cluster vs domain isolation: Clusters share lifecycle context; domains provide stronger separation
Resource pools are not domains: Resource pools provide resource management, not lifecycle isolation
Storage policies are not isolation: vSAN policies manage storage behavior, not operational boundaries
Design for change: Workload domain boundaries should anticipate future lifecycle and operational needs