An architect is working with a service provider to design a VMware Cloud Foundation (VCF) solution that is required to host workloads for multiple…

To determine the appropriate VMware Cloud Foundation (VCF) architecture for this scenario, we

need to evaluate each option against the provided requirements and the capabilities of VCF 5.2 as

outlined in official documentation.

Requirement Analysis:

Each tenant requires full access to their own vCenter: This implies that each tenant needs a

dedicated vCenter Server instance for managing their workloads, ensuring isolation and

administrative control.

Each tenant will utilize and manage their own identity provider: This requires separate Single Sign-On

(SSO) domains or identity sources per tenant, as tenants must integrate their own identity providers

(e.g., Active Directory, LDAP) independently.

A total of 28 tenants: The solution must scale to support 28 isolated environments.

Independent VCF lifecycle maintenance schedule: Each tenant’s environment must support its own

lifecycle management (e.g., upgrades, patches) without impacting others, implying separate VCF

instances or fully isolated workload domains.

VCF Architecture Models Overview (Based on VCF 5.2 Documentation):

Standard Architecture Model: A single VCF instance with one vCenter Server managing all workload

domains under a single SSO domain. Additional workload domains share the same vCenter and SSO

infrastructure.

Consolidated Architecture Model: A single VCF instance where the management domain and

workload domains are managed by one vCenter Server, but workload domains can be isolated at the

cluster level.

Multiple VCF Instances: Separate VCF deployments, each with its own management domain, vCenter

Server, and SSO domain, enabling full isolation and independent lifecycle management.

Option Analysis:

A . A single VCF instance consolidated architecture model with 28 tenant clusters:

In a consolidated architecture, a single vCenter Server manages the management domain and all

workload clusters. While 28 tenant clusters could be created, all would share the same vCenter and

SSO domain. This violates the requirements for each tenant having their own vCenter and managing

their own identity provider, as a single SSO domain cannot support 28 independent identity

providers. Additionally, lifecycle management would be tied to the single VCF instance, conflicting

with the independent maintenance schedule requirement. This option does not meet the

requirements.

B . A single VCF instance standard architecture model and 28 isolated SSO domains:

In a standard architecture, a single VCF instance includes one vCenter Server and one SSO domain for

all workload domains. While workload domains can be created for isolation, VMware Cloud

Foundation 5.2 does not support multiple isolated SSO domains within a single vCenter instance. The

vSphere SSO architecture allows only one SSO domain per vCenter Server. Even with creative

configurations (e.g., identity federation), managing 28 independent identity providers within one

SSO domain is impractical and unsupported. Furthermore, all workload domains share the same

lifecycle schedule under one VCF instance, failing the independent maintenance requirement. This

option is not viable.

C . Two VCF instances consolidated architecture model with 14 tenant clusters each:

With two VCF instances, each instance has its own management domain, vCenter Server, and SSO

domain. Each instance operates in a consolidated architecture, where tenant clusters (workload

domains) are managed by the instance’s vCenter. However, the key here is that each VCF instance

can be fully isolated from the other, allowing:

Each tenant cluster to be assigned a dedicated vCenter (via separate workload domains or vSphere

clusters with permissions).

Independent SSO domains per instance, with tenant-specific identity providers configured through

federation or external identity sources.

Independent lifecycle management, as each VCF instance can be upgraded or patched separately.

Splitting 28 tenants into 14 per instance is feasible, as VCF 5.2 supports up to 25 workload domains

per instance (per the VCF Design Guide), and tenant isolation can be achieved at the cluster level

with proper permissions and NSX segmentation. This option meets all requirements.

D . Two VCF instances with standard architecture model and 14 isolated SSO domains each:

In a standard architecture, each VCF instance has one vCenter Server and one SSO domain. While

having two instances provides lifecycle independence, the mention of “14 isolated SSO domains

each” is misleading and unsupported. A single vCenter Server (and thus a single VCF instance)

supports only one SSO domain. It’s possible this intends to mean 14 tenants with isolated identity

configurations, but this would still conflict with the single-SSO limitation per instance. Even with two

instances, achieving 14 isolated SSO domains per instance is not architecturally possible in VCF 5.2.

This option fails the identity provider and vCenter requirements.

Conclusion:

Option C (Two VCF instances consolidated architecture model with 14 tenant clusters each) is the

only architecture that satisfies all requirements. It provides tenant isolation via separate clusters,

supports dedicated vCenter access through permissions or additional vCenter deployments, allows

independent identity providers via SSO federation, scales to 28 tenants across two instances, and

ensures independent lifecycle management.

Reference:

VMware Cloud Foundation 5.2 Design Guide (Section: Architecture Models)

VMware Cloud Foundation 5.2 Planning and Preparation Workbook (Section: Multi-Tenancy

Considerations)

VMware Cloud Foundation 5.2 Administration Guide (Section: Lifecycle Management)

VMware vSphere 8.0 Update 3 Documentation (Section: SSO and Identity Federation)