An enterprise security architect is designing a multi-project network topology in Google Cloud using Shared VPC. The organization requires strict separation of duties, resource isolation, and centralized network governance between the central cloud infrastructure team and individual application development teams. The design must meet the following requirements: Central infrastructure administrators must retain exclusive control over VPC networks, IP address allocations, routes, and firewall rules within the host project. Application teams managing service-project-a must only be able to deploy Compute Engine virtual machines and internal load balancers into an assigned subnet (subnet-app-prod) in us-central1. Application developers must be prevented from provisioning workloads into any other subnets (such as subnet-management or subnet-app-dev) and must not have permissions to modify host network security policies. Which IAM role delegation strategy should the architect implement?

Grant the application team the `roles/compute.networkUser` role specifically on the `subnet-app-prod` resource in the host project, and grant the `roles/compute.instanceAdmin.v1` role in `service-project-a`.: What Subnet-Level IAM Delegation Is Subnet-level IAM delegation in Google Cloud Shared VPC architectures allows administrators to grant granular permissions on individual subnet resources rather than at the overall host project level. By assigning the Compute Network User role (roles/compute.networkUser) directly to specific subnets, organizations establish granular administrative boundaries that adhere to the principle of least privilege. How It Meets the Requirements Subnet-specific deployment: Assigning roles/compute.networkUser exclusively on subnet-app-prod permits developers in service-project-a to attach network interfaces and deploy VM instances or internal load balancers into that specific subnet only. Preventing unauthorized subnet access: Because the role is bound to subnet-app-prod rather than the host project, developers have no rights to use subnet-management, subnet-app-dev, or any other shared subnets. Separation of administrative duties: Granting Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) within service-project-a gives developers full control over workload provisioning inside their own project while denying permissions to modify firewall rules, routes, or VPC structures in the host project. Key Advantages and Capabilities Precise access control: Prevents accidental or malicious workload provisioning in sensitive network segments. Centralized security governance: Network and Security Admins manage all routing, firewall configurations, and IP assignments centrally in the host project. Environment isolation: Guarantees that separate teams operating in distinct service projects cannot interfere with each other's network allocations. Independent workload lifecycle: Service project administrators can manage instance configurations, persistent disks, and scaling without requiring elevated networking permissions. Why This Is Optimal This configuration represents the recommended security baseline for enterprise Shared VPC deployments. It cleanly separates non-network workload administration in service projects from centralized network policy enforcement in the host project.

Shared Vpc Subnet Level Iam Delegation | Professional Cloud Security Engineer

StudyCerts

Explanations

What Subnet-Level IAM Delegation Is

Subnet-level IAM delegation in Google Cloud Shared VPC architectures allows administrators to grant granular permissions on individual subnet resources rather than at the overall host project level. By assigning the Compute Network User role (roles/compute.networkUser) directly to specific subnets, organizations establish granular administrative boundaries that adhere to the principle of least privilege.

How It Meets the Requirements

Subnet-specific deployment: Assigning roles/compute.networkUser exclusively on subnet-app-prod permits developers in service-project-a to attach network interfaces and deploy VM instances or internal load balancers into that specific subnet only.
Preventing unauthorized subnet access: Because the role is bound to subnet-app-prod rather than the host project, developers have no rights to use subnet-management, subnet-app-dev, or any other shared subnets.
Separation of administrative duties: Granting Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) within service-project-a gives developers full control over workload provisioning inside their own project while denying permissions to modify firewall rules, routes, or VPC structures in the host project.

Key Advantages and Capabilities

Precise access control: Prevents accidental or malicious workload provisioning in sensitive network segments.
Centralized security governance: Network and Security Admins manage all routing, firewall configurations, and IP assignments centrally in the host project.
Environment isolation: Guarantees that separate teams operating in distinct service projects cannot interfere with each other's network allocations.
Independent workload lifecycle: Service project administrators can manage instance configurations, persistent disks, and scaling without requiring elevated networking permissions.

Why This Is Optimal

This configuration represents the recommended security baseline for enterprise Shared VPC deployments. It cleanly separates non-network workload administration in service projects from centralized network policy enforcement in the host project.

View source documentation

Professional Cloud Security Engineer

Shared Vpc Subnet Level Iam Delegation