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.

Gcp Multi Tenant Project Hierarchy Billing Management | Professional Cloud DevOps Engineer

StudyCerts

Explanations

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

Professional Cloud DevOps Engineer

Gcp Multi Tenant Project Hierarchy Billing Management