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

Gcp Multi Tenant Project Hierarchy Billing Management

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

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.

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 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.

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.

Professional Cloud DevOps Engineer

Gcp Multi Tenant Project Hierarchy Billing Management

Related questions