Your organization is establishing a centralized network topology in Google Cloud to support multiple autonomous application teams while enforcing strict security and environment boundaries. You have designated a central host project (net-host-prod) containing a Shared VPC network with two distinct subnets: team-a-subnet and team-b-subnet. You have created two dedicated service projects: service-team-a for Team A and service-team-b for Team B. You need to configure IAM roles and subnet access to satisfy the following requirements: Centralized network management (creating and managing VPCs, subnets, and routing) must be restricted exclusively to the central Cloud Network Engineering team. Team A engineers and their automated workload deployment service accounts must only be permitted to provision Compute Engine instances and Managed Instance Groups (MIGs) attached to team-a-subnet. Team B engineers and their automated workload deployment service accounts must only be permitted to provision Compute Engine instances and MIGs attached to team-b-subnet. Cross-subnet provisioning between teams must be prevented, following the principle of least privilege. How should you configure the IAM role assignments across the host and service projects?

Grant the central Network Engineering team the Compute Network Admin (`roles/compute.networkAdmin`) role on the host project. In the host project, grant Team A principals and the `service-team-a` Google APIs service account the Compute Network User (`roles/compute.networkUser`) role specifically on `team-a-subnet`, and grant Team B principals and the `service-team-b` Google APIs service account `roles/compute.networkUser` specifically on `team-b-subnet`. Grant each team Instance Admin (`roles/compute.instanceAdmin.v1`) within their respective service project.: ### What this solution is This architecture establishes a **Shared VPC** design where a single central **host project** manages underlying network topology and routing, while separate **service projects** host workloads managed by decentralized application teams. Subnet-level IAM access binding provides granular network segregation across service projects. ### How it meets the requirements * **Centralized Network Administration**: Granting `roles/compute.networkAdmin` exclusively to the central team on the host project (`net-host-prod`) guarantees that only network engineers can modify network routes, subnets, and global configurations. * **Subnet Isolation and Least Privilege**: Applying the **Compute Network User** (`roles/compute.networkUser`) role directly to individual subnets (`team-a-subnet` and `team-b-subnet`) ensures that each team can only attach network interfaces to their authorized IP range. Team A cannot provision resources into Team B's subnet. * **Workload and MIG Provisioning**: Granting `roles/compute.instanceAdmin.v1` inside the respective service projects allows developers to manage virtual machines and templates. Binding `roles/compute.networkUser` on the subnet to the service project's **Google APIs service account** (`SERVICE_PROJECT_NUM@cloudservices.gserviceaccount.com`) is a mandatory requirement for automated instance provisioning in **Managed Instance Groups (MIGs)**. ### Key advantages and capabilities * **Prevents Configuration Drift**: Centralized VPC governance prevents individual application teams from altering network topologies or IP allocations. * **Enforces Security Boundaries**: Eliminates unauthorized cross-tenant subnet usage without requiring complex firewall rules. * **Automates Scaling Securely**: Grants service robots the exact permissions needed to provision instances during autoscaling events. * **Accurate Cost Attribution**: Resource and egress billing remains attributed to the service project where instances reside. ### Why this is optimal Subnet-level IAM role delegation is the Google-recommended best practice for multi-tenant and multi-environment Shared VPC deployments. It separates administrative duties while strictly constraining resource placement across service projects.

Shared Vpc Host Service Project Iam Subnet Allocation | Professional Cloud DevOps Engineer

Shared Vpc Host Service Project Iam Subnet Allocation

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 organization is establishing a centralized network topology in Google Cloud to support multiple autonomous application teams while enforcing strict security and environment boundaries. You have designated a central host project (net-host-prod) containing a Shared VPC network with two distinct subnets: team-a-subnet and team-b-subnet.

You have created two dedicated service projects: service-team-a for Team A and service-team-b for Team B. You need to configure IAM roles and subnet access to satisfy the following requirements:

Centralized network management (creating and managing VPCs, subnets, and routing) must be restricted exclusively to the central Cloud Network Engineering team.
Team A engineers and their automated workload deployment service accounts must only be permitted to provision Compute Engine instances and Managed Instance Groups (MIGs) attached to team-a-subnet.
Team B engineers and their automated workload deployment service accounts must only be permitted to provision Compute Engine instances and MIGs attached to team-b-subnet.
Cross-subnet provisioning between teams must be prevented, following the principle of least privilege.

How should you configure the IAM role assignments across the host and service projects?

Professional Cloud DevOps Engineer

Shared Vpc Host Service Project Iam Subnet Allocation

Related questions