Your enterprise SaaS company is designing a multi-tenant data analytics architecture on Google Cloud. Each enterprise customer (tenant) requires dedicated BigQuery datasets and Compute Engine workloads with strict resource isolation, granular IAM access control, and dedicated lifecycle boundaries. The architecture must satisfy the following requirements: Resource isolation and lifecycle: Ensure tenant resources cannot outlive their organizational container and can be decommissioned cleanly without impacting other tenants. Cost attribution and capacity management: Accurately attribute outbound networking and data storage costs to each tenant, while centralizing BigQuery slot commitments in an administration project with shared idle capacity across tenant reservations. Network governance: Attach tenant compute workloads to a centrally governed Shared VPC network while ensuring network egress costs remain attributed directly to the tenant's cost center. Which resource hierarchy and project management strategy should you implement?

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.: What the Solution Is This strategy uses dedicated Google Cloud projects as the core tenancy and lifecycle container for each customer, integrates them into a Shared VPC architecture as service projects, and leverages a centralized BigQuery administration project for commitment and capacity management. How It Meets the Requirements Resource isolation and lifecycle: In Google Cloud, a project acts as an absolute policy, IAM, and lifecycle boundary. Service resources inside a project cannot outlive the project itself, enabling clean, self-contained tenant decommissioning without residual orphaned infrastructure. Cost attribution and capacity management: Storage costs accrue directly to the tenant project holding the BigQuery datasets. By using a centralized administration project (bq-admin) to purchase slot commitments, the organization centralizes baseline billing while allocating distinct reservations to tenant projects. Crucially, idle slots can be shared across all reservations managed within that same administration project. Network governance and egress billing: With Shared VPC, network administrators maintain centralized control in the host project, while Service Project Admins deploy instances in tenant service projects. Outbound network egress generated by instances in a service project is billed directly to that service project, ensuring exact cost center attribution. Quota management: Projects that are deleted enter a 30-day soft-delete state and continue to count against the organization's cloudresourcemanager.googleapis.com/projects_count quota until fully purged, making proactive quota planning essential. Key Advantages and Capabilities Strict Blast Radius Containment: Misconfigurations or project deletions in one tenant container never impact neighbor tenants. Optimal Slot Utilization: Sharing idle capacity across reservations avoids paying for unused dedicated capacity. Decoupled Network Control: Centralizes firewall and subnet configuration while preserving granular service-level cost tracking. Why This Is Optimal This architecture strictly aligns with Google Cloud landing zone and multi-tenant best practices by leveraging projects as the fundamental boundary for security, billing attribution, and resource lifecycle.

Tenant Projects with Shared VPC and Shared BigQuery Slots

Tenant Isolation with Shared VPC Projects

Your enterprise SaaS company is designing a multi-tenant data analytics architecture on Google Cloud. Each enterprise customer (tenant) requires dedicated BigQuery datasets and Compute Engine workloads with strict resource isolation, granular IAM access control, and dedicated lifecycle boundaries.

The architecture must satisfy the following requirements:

Resource isolation and lifecycle: Ensure tenant resources cannot outlive their organizational container and can be decommissioned cleanly without impacting other tenants.
Cost attribution and capacity management: Accurately attribute outbound networking and data storage costs to each tenant, while centralizing BigQuery slot commitments in an administration project with shared idle capacity across tenant reservations.
Network governance: Attach tenant compute workloads to a centrally governed Shared VPC network while ensuring network egress costs remain attributed directly to the tenant's cost center.

Which resource hierarchy and project management strategy should you implement?

Create dedicated projects per tenant, but purchase individual BigQuery slot commitments and reservations independently inside each tenant project while interconnecting workloads using VPC Network Peering.

Provision a dedicated Shared VPC host project for each tenant, configure on-demand BigQuery billing across all projects, and grant developers the Project Deleter role to bypass the 30-day soft-delete quota retention window.

Consolidate all tenants into a single shared production project using Kubernetes namespaces and distinct BigQuery dataset IDs, purchase slot commitments directly in that project, and rely entirely on resource labels for billing export filtering.

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.

Explanations

Create dedicated projects per tenant, but purchase individual BigQuery slot commitments and reservations independently inside each tenant project while interconnecting workloads using VPC Network Peering.

What the Option Is

This approach deploys isolated projects per tenant but decentralizes BigQuery capacity management by purchasing commitments locally in each tenant project, and decentralizes networking by creating local VPC networks connected via VPC Network Peering.

Why It Doesn't Meet the Requirement

Capacity management and idle slot sharing: When slot commitments are purchased across separate administration projects (or directly in individual workload projects), idle slots cannot be shared between those reservations. This leads to substantial compute inefficiency and increased costs because underutilized tenant slots cannot be repurposed by busier tenants.
Network governance: VPC Network Peering decentralizes firewall and route management across dozens or hundreds of tenant VPCs, significantly increasing administrative burden compared to a centralized Shared VPC host project.

Key Characteristics and Limitations

Idle BigQuery capacity is strictly constrained to reservations within the same administration project.
Replicating commitments across individual tenant projects multiplies upfront financial commitments.
VPC Network Peering does not scale easily for enterprise multi-tenant hub-and-spoke topologies due to peering limits and decentralized governance.

This Answer Would Be Correct If

Each tenant required legally isolated billing contracts with entirely separate credit lines and zero shared infrastructure or pooled capacity across the entire organization.

View source documentation

Provision a dedicated Shared VPC host project for each tenant, configure on-demand BigQuery billing across all projects, and grant developers the Project Deleter role to bypass the 30-day soft-delete quota retention window.

What the Option Is

This strategy attempts to isolate tenants by provisioning a dedicated Shared VPC host project for every single tenant, leaving all analytics workloads on on-demand BigQuery pricing, and trying to manually purge projects to immediately reclaim project quota.

Why It Doesn't Meet the Requirement

Capacity management and commitments: Using on-demand billing fails the requirement to utilize centralized BigQuery slot commitments and reservations with pooled idle capacity.
Quota and lifecycle management: In Google Cloud, there is no IAM role or API mechanism that allows an administrator to bypass the mandatory 30-day soft-delete period for deleted projects. Soft-deleted projects strictly consume organization project quota until the 30-day window elapses.
Network architecture: Shared VPC host projects are meant to centralize networking across multiple service projects. Creating a host project per tenant defeats the purpose of centralized Shared VPC governance.

Key Characteristics and Limitations

The 30-day project soft-delete lifecycle is immutable and enforced platform-wide.
On-demand BigQuery queries are subject to per-query data scan pricing rather than predictable committed capacity.
Sprawling host projects creates massive management overhead for network and security teams.

This Answer Would Be Correct If

The workload experienced highly infrequent, unpredictable query bursts where slot reservations are uneconomical, and tenant creation rates were low enough not to impact project quotas.

View source documentation

Consolidate all tenants into a single shared production project using Kubernetes namespaces and distinct BigQuery dataset IDs, purchase slot commitments directly in that project, and rely entirely on resource labels for billing export filtering.

What the Option Is

This pattern uses a single, monolithic Google Cloud project to host all tenant workloads, relying on logical soft multi-tenancy constructs such as Kubernetes namespaces, BigQuery dataset naming conventions, and resource labels to separate tenant data and attribute costs via Cloud Billing export.

Why It Doesn't Meet the Requirement

Resource isolation and lifecycle: Projects are the fundamental tenancy, policy, and quota boundary in Google Cloud. Consolidating tenants into a single project creates shared IAM attack surfaces and shared API quota limits (such as VPC quotas and BigQuery job limits). Deleting a tenant cannot be done via project lifecycle management and requires complex, error-prone manual resource deletion.
Cost attribution: Resource labels do not cover every Google Cloud SKU or shared platform overhead (such as inter-zone network traffic and shared load balancers), leading to incomplete and imprecise cost tracking compared to project-level billing boundaries.

Key Characteristics and Limitations

Lacks hard security boundaries between tenants at the Google Cloud control plane level.
Risks cross-tenant resource starvation when hitting per-project API quotas.
Increases IAM complexity to prevent cross-dataset access within the same project.

This Answer Would Be Correct If

The organization had a flat pricing model for micro-tenants where overhead costs are negligible, and individual tenant environments did not require dedicated lifecycle, billing, or security boundaries.

View source documentation

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.

What the Solution Is

This strategy uses dedicated Google Cloud projects as the core tenancy and lifecycle container for each customer, integrates them into a Shared VPC architecture as service projects, and leverages a centralized BigQuery administration project for commitment and capacity management.

How It Meets the Requirements

Resource isolation and lifecycle: In Google Cloud, a project acts as an absolute policy, IAM, and lifecycle boundary. Service resources inside a project cannot outlive the project itself, enabling clean, self-contained tenant decommissioning without residual orphaned infrastructure.
Cost attribution and capacity management: Storage costs accrue directly to the tenant project holding the BigQuery datasets. By using a centralized administration project (bq-admin) to purchase slot commitments, the organization centralizes baseline billing while allocating distinct reservations to tenant projects. Crucially, idle slots can be shared across all reservations managed within that same administration project.
Network governance and egress billing: With Shared VPC, network administrators maintain centralized control in the host project, while Service Project Admins deploy instances in tenant service projects. Outbound network egress generated by instances in a service project is billed directly to that service project, ensuring exact cost center attribution.
Quota management: Projects that are deleted enter a 30-day soft-delete state and continue to count against the organization's cloudresourcemanager.googleapis.com/projects_count quota until fully purged, making proactive quota planning essential.

Key Advantages and Capabilities

Strict Blast Radius Containment: Misconfigurations or project deletions in one tenant container never impact neighbor tenants.
Optimal Slot Utilization: Sharing idle capacity across reservations avoids paying for unused dedicated capacity.
Decoupled Network Control: Centralizes firewall and subnet configuration while preserving granular service-level cost tracking.

Why This Is Optimal

This architecture strictly aligns with Google Cloud landing zone and multi-tenant best practices by leveraging projects as the fundamental boundary for security, billing attribution, and resource lifecycle.

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Tenant Isolation with Shared VPC Projects

The architecture must satisfy the following requirements:

Resource isolation and lifecycle: Ensure tenant resources cannot outlive their organizational container and can be decommissioned cleanly without impacting other tenants.
Cost attribution and capacity management: Accurately attribute outbound networking and data storage costs to each tenant, while centralizing BigQuery slot commitments in an administration project with shared idle capacity across tenant reservations.
Network governance: Attach tenant compute workloads to a centrally governed Shared VPC network while ensuring network egress costs remain attributed directly to the tenant's cost center.

Which resource hierarchy and project management strategy should you implement?

Explanations

Create dedicated projects per tenant, but purchase individual BigQuery slot commitments and reservations independently inside each tenant project while interconnecting workloads using VPC Network Peering.

What the Option Is

Why It Doesn't Meet the Requirement

Capacity management and idle slot sharing: When slot commitments are purchased across separate administration projects (or directly in individual workload projects), idle slots cannot be shared between those reservations. This leads to substantial compute inefficiency and increased costs because underutilized tenant slots cannot be repurposed by busier tenants.
Network governance: VPC Network Peering decentralizes firewall and route management across dozens or hundreds of tenant VPCs, significantly increasing administrative burden compared to a centralized Shared VPC host project.

Key Characteristics and Limitations

Idle BigQuery capacity is strictly constrained to reservations within the same administration project.
Replicating commitments across individual tenant projects multiplies upfront financial commitments.
VPC Network Peering does not scale easily for enterprise multi-tenant hub-and-spoke topologies due to peering limits and decentralized governance.

This Answer Would Be Correct If

Each tenant required legally isolated billing contracts with entirely separate credit lines and zero shared infrastructure or pooled capacity across the entire organization.

View source documentation

Provision a dedicated Shared VPC host project for each tenant, configure on-demand BigQuery billing across all projects, and grant developers the Project Deleter role to bypass the 30-day soft-delete quota retention window.

What the Option Is

Why It Doesn't Meet the Requirement

Capacity management and commitments: Using on-demand billing fails the requirement to utilize centralized BigQuery slot commitments and reservations with pooled idle capacity.
Quota and lifecycle management: In Google Cloud, there is no IAM role or API mechanism that allows an administrator to bypass the mandatory 30-day soft-delete period for deleted projects. Soft-deleted projects strictly consume organization project quota until the 30-day window elapses.
Network architecture: Shared VPC host projects are meant to centralize networking across multiple service projects. Creating a host project per tenant defeats the purpose of centralized Shared VPC governance.

Key Characteristics and Limitations

The 30-day project soft-delete lifecycle is immutable and enforced platform-wide.
On-demand BigQuery queries are subject to per-query data scan pricing rather than predictable committed capacity.
Sprawling host projects creates massive management overhead for network and security teams.

This Answer Would Be Correct If

The workload experienced highly infrequent, unpredictable query bursts where slot reservations are uneconomical, and tenant creation rates were low enough not to impact project quotas.

View source documentation

Consolidate all tenants into a single shared production project using Kubernetes namespaces and distinct BigQuery dataset IDs, purchase slot commitments directly in that project, and rely entirely on resource labels for billing export filtering.

What the Option Is

Why It Doesn't Meet the Requirement

Resource isolation and lifecycle: Projects are the fundamental tenancy, policy, and quota boundary in Google Cloud. Consolidating tenants into a single project creates shared IAM attack surfaces and shared API quota limits (such as VPC quotas and BigQuery job limits). Deleting a tenant cannot be done via project lifecycle management and requires complex, error-prone manual resource deletion.
Cost attribution: Resource labels do not cover every Google Cloud SKU or shared platform overhead (such as inter-zone network traffic and shared load balancers), leading to incomplete and imprecise cost tracking compared to project-level billing boundaries.

Key Characteristics and Limitations

Lacks hard security boundaries between tenants at the Google Cloud control plane level.
Risks cross-tenant resource starvation when hitting per-project API quotas.
Increases IAM complexity to prevent cross-dataset access within the same project.

This Answer Would Be Correct If

View source documentation

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.

What the Solution Is

How It Meets the Requirements

Resource isolation and lifecycle: In Google Cloud, a project acts as an absolute policy, IAM, and lifecycle boundary. Service resources inside a project cannot outlive the project itself, enabling clean, self-contained tenant decommissioning without residual orphaned infrastructure.
Cost attribution and capacity management: Storage costs accrue directly to the tenant project holding the BigQuery datasets. By using a centralized administration project (bq-admin) to purchase slot commitments, the organization centralizes baseline billing while allocating distinct reservations to tenant projects. Crucially, idle slots can be shared across all reservations managed within that same administration project.
Network governance and egress billing: With Shared VPC, network administrators maintain centralized control in the host project, while Service Project Admins deploy instances in tenant service projects. Outbound network egress generated by instances in a service project is billed directly to that service project, ensuring exact cost center attribution.
Quota management: Projects that are deleted enter a 30-day soft-delete state and continue to count against the organization's cloudresourcemanager.googleapis.com/projects_count quota until fully purged, making proactive quota planning essential.

Key Advantages and Capabilities

Strict Blast Radius Containment: Misconfigurations or project deletions in one tenant container never impact neighbor tenants.
Optimal Slot Utilization: Sharing idle capacity across reservations avoids paying for unused dedicated capacity.
Decoupled Network Control: Centralizes firewall and subnet configuration while preserving granular service-level cost tracking.

Why This Is Optimal

View source documentation

Last updated August 28, 2026Validated August 28, 2026

Tenant Isolation with Shared VPC Projects

Explanations

Create dedicated projects per tenant, but purchase individual BigQuery slot commitments and reservations independently inside each tenant project while interconnecting workloads using VPC Network Peering.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Provision a dedicated Shared VPC host project for each tenant, configure on-demand BigQuery billing across all projects, and grant developers the Project Deleter role to bypass the 30-day soft-delete quota retention window.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Consolidate all tenants into a single shared production project using Kubernetes namespaces and distinct BigQuery dataset IDs, purchase slot commitments directly in that project, and rely entirely on resource labels for billing export filtering.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.

What the Solution Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Staging Organization for Policy Validation

Infrastructure Manager Managed Terraform

Cloud Trace Critical Path Analysis

Active Assist VM Rightsizing

Folder IAM Admin Role

SQL GROUP BY with Aggregate Functions

Tenant Isolation with Shared VPC Projects

Explanations

Create dedicated projects per tenant, but purchase individual BigQuery slot commitments and reservations independently inside each tenant project while interconnecting workloads using VPC Network Peering.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Provision a dedicated Shared VPC host project for each tenant, configure on-demand BigQuery billing across all projects, and grant developers the Project Deleter role to bypass the 30-day soft-delete quota retention window.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Consolidate all tenants into a single shared production project using Kubernetes namespaces and distinct BigQuery dataset IDs, purchase slot commitments directly in that project, and rely entirely on resource labels for billing export filtering.

What the Option Is

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Provision dedicated projects for each tenant as service projects attached to a central Shared VPC host project, assign tenant projects to reservations managed within a centralized BigQuery administration project, and factor in the 30-day soft-delete lifecycle against project quotas.

What the Solution Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Try 10 interactive questions like this one, free

Related questions

Staging Organization for Policy Validation

Infrastructure Manager Managed Terraform

Cloud Trace Critical Path Analysis

Active Assist VM Rightsizing

Folder IAM Admin Role

SQL GROUP BY with Aggregate Functions