An enterprise organization is establishing a centralized Shared VPC architecture to host workloads across multiple departments. The central network security team manages the Shared VPC host project, which contains subnet-frontend (in us-central1), subnet-backend (in us-central1), and subnet-analytics (in us-east1). The organization must meet the following access and administrative requirements: The AppDev team manages instances in service-project-app and must only be able to provision VM instances into subnet-frontend. The Analytics team manages instances in service-project-data and must only be able to provision VM instances into subnet-analytics. Neither team should have access or provisioning rights to the remaining subnets in the Shared VPC. Central network administrators must retain exclusive control over network creation, firewall rules, and subnet routing without administering VM instances. How should IAM roles and resource bindings be configured to meet these requirements following the principle of least privilege?

Assign the AppDev team Compute Instance Admin on `service-project-app` and Compute Network User (`roles/compute.networkUser`) specifically on the `subnet-frontend` resource in the host project. Assign the Analytics team Compute Instance Admin on `service-project-data` and Compute Network User specifically on the `subnet-analytics` resource in the host project. Assign the central network team Compute Network Admin (`roles/compute.networkAdmin`) at the host project level.: What Shared VPC Subnet-Level IAM Delegation Is Shared VPC enables centralized management of networking infrastructure by separating host projects from service projects. Subnet-level access control allows administrators to grant the Compute Network User (roles/compute.networkUser) role on individual subnet resources rather than across the entire host project. How it meets the requirements: Least-Privilege Subnet Access: Granting roles/compute.networkUser at the individual subnet resource level (e.g., subnet-frontend or subnet-analytics) grants Service Project Admins permission to attach network interfaces and instantiate VMs in that specific subnet only, preventing unauthorized provisioning into other subnets like subnet-backend. Separation of Duties: Granting Compute Instance Admin (roles/compute.instanceAdmin.v1 or similar) in their respective service projects allows developers to manage virtual machines and application workloads autonomously. Centralized Network Governance: Assigning Compute Network Admin (roles/compute.networkAdmin) to the network team at the host project level provides complete control over routing, peering, subnets, and firewall rules without granting service project workload permissions. Key advantages and capabilities: Granular boundary segmentation: Prevents cross-tenant IP resource consumption and enforces environmental isolation. Administrative decoupling: Developers manage compute resources while the core infrastructure team enforces uniform network security policies. Cost attribution: Outbound network traffic and instance runtime costs remain mapped to the respective service project cost centers. Auditability: Simplifies Cloud Audit Logs by maintaining clear separation between identity actions in service projects and network modifications in the host project. Why this is optimal: Applying the roles/compute.networkUser role directly to target subnets adheres to least privilege by restricting service teams from discovering and deploying into unauthorized subnets, satisfying all architectural and security constraints.

Shared Vpc Iam Role Separation Subnet Access | Professional Cloud Security Engineer

StudyCerts

Explanations

What Shared VPC Subnet-Level IAM Delegation Is

Shared VPC enables centralized management of networking infrastructure by separating host projects from service projects. Subnet-level access control allows administrators to grant the Compute Network User (roles/compute.networkUser) role on individual subnet resources rather than across the entire host project.

How it meets the requirements:

Least-Privilege Subnet Access: Granting roles/compute.networkUser at the individual subnet resource level (e.g., subnet-frontend or subnet-analytics) grants Service Project Admins permission to attach network interfaces and instantiate VMs in that specific subnet only, preventing unauthorized provisioning into other subnets like subnet-backend.
Separation of Duties: Granting Compute Instance Admin (roles/compute.instanceAdmin.v1 or similar) in their respective service projects allows developers to manage virtual machines and application workloads autonomously.
Centralized Network Governance: Assigning Compute Network Admin (roles/compute.networkAdmin) to the network team at the host project level provides complete control over routing, peering, subnets, and firewall rules without granting service project workload permissions.

Key advantages and capabilities:

Granular boundary segmentation: Prevents cross-tenant IP resource consumption and enforces environmental isolation.
Administrative decoupling: Developers manage compute resources while the core infrastructure team enforces uniform network security policies.
Cost attribution: Outbound network traffic and instance runtime costs remain mapped to the respective service project cost centers.
Auditability: Simplifies Cloud Audit Logs by maintaining clear separation between identity actions in service projects and network modifications in the host project.

Why this is optimal:

Applying the roles/compute.networkUser role directly to target subnets adheres to least privilege by restricting service teams from discovering and deploying into unauthorized subnets, satisfying all architectural and security constraints.

View source documentation

Professional Cloud Security Engineer

Shared Vpc Iam Role Separation Subnet Access