GCP Professional Cloud Architect Practice Question 7: Shared VPC Network Ownership
Google Cloud Professional Cloud Architect · Test 1 · question 7 of 10
Twelve application teams at a logistics company each own a separate Google Cloud project so that their spend is billed and reported independently. A central network team must remain the sole owner of subnets, firewall rules, Cloud NAT, and hybrid routes, and application teams must be able to create VMs and GKE clusters on those subnets without being able to create or change any network resource. Private RFC 1918 addressing must be shared, non-overlapping, and centrally allocated.
Which design satisfies these requirements?
Show answer and explanation
Answer:
Shared VPC is built for this separation of duties. The host project owns the VPC network, its subnets, firewall rules, Cloud NAT, and hybrid connectivity; service projects attach to it and their workloads consume host-project subnets while remaining separate projects for billing, quota, and IAM. roles/compute.networkUser is the role that lets a principal use a network or subnet, and because it can be granted at the individual subnet level rather than the whole host project, each team gets only the ranges it needs. Nothing in that role permits creating or editing subnets or firewall rules, so the network team keeps ownership. (The Shared VPC Admin who attaches projects holds compute.xpnAdmin plus Project IAM Admin, granted at the organization or folder level.)
Option B gives every application team administrative control of its own VPC, the opposite of the requirement, and peering is non-transitive with no central IP allocation, so twelve peered VPCs means twelve chances of overlapping ranges and a mesh the network team cannot govern.
Option C collapses the project boundary that the company deliberately created for billing and blast radius. Label-based conditions are a weak substitute for project-level isolation, and consolidating twelve teams into one project invites quota contention and accidental cross-team access.
Option D grants exactly the permission the stem forbids: roles/compute.networkAdmin on the host project lets any team create and modify subnets and firewall rules for everyone. Organization policy constraints do not carve a network admin's power down to "these subnets only".
Reference: Shared VPC overview