A Cloud Architect is designing the IAM strategy for a multi-team project. Developers need full access to deploy and manage resources in their own…

This solution correctly implements the principle of least privilege and separation of duties within a Shared VPC architecture. Granting developers the Compute Network User (roles/compute.networkUser) role on the Host project is the standard practice. This role provides the necessary permissions to use the shared network resources (e.g., create VM instances that connect to shared subnets) without granting any administrative privileges to modify the VPC network or its firewall rules. Concurrently, granting the Project Owner role within their own service projects gives them the required autonomy to manage their applications and resources.

A. Organization Policies are used to enforce constraints on resource configurations (e.g., disabling public IPs), not to grant or deny permissions to specific IAM principals like a user group.

B. VPC Peering is a different networking architecture. It would decentralize network control, which contradicts the goal of having a centrally managed network in a Host project.

C. Granting the Project Editor role on the Host project is overly permissive. It includes permissions to modify networks and firewalls, directly violating the core security requirement.

1. Google Cloud Documentation, "Shared VPC", Section: "Administrators and users of Shared VPC": This document explicitly outlines the IAM roles for Shared VPC. It states, "Service Project Admins... need the compute.networkUser role... This role allows them to use the Shared VPC network but does not grant them any permission to make administrative changes to the Shared VPC network." This directly supports the use of the Compute Network User role for developers on the Host project as described in option D.

2. Google Cloud Documentation, "IAM basic and predefined roles reference", Section: "Compute Engine roles": The description for the roles/compute.networkUser role confirms it grants permissions to use networks and subnets but not to create or modify them. Conversely, the documentation for the roles/editor primitive role shows it contains broad permissions, including compute.networks.update, which validates why option C is incorrect.

3. Google Cloud Documentation, "Introduction to the Organization Policy Service", Section: "Overview": This page clarifies the distinction between IAM and Organization Policies. It states, "IAM focuses on who, and lets the administrator authorize who can take action on specific resources based on user permissions. Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured." This confirms that an Organization Policy (Option A) is the incorrect tool for this scenario.