Shared VPC Subnet Management and Cost Optimization

PCNE By islever Editorial Last updated

Designing VPC networks. Configuring and managing NGFW policies and VPC Firewall rules.

Short answer

C Enable the existing project as a Shared VPC host, create a dedicated subnet for the new division, and grant roles/compute.networkUser on that subnet.

Question

Your company acquired a new division. The new division's network team requires complete control over their networking infrastructure. You need to extend your existing Google Cloud network infrastructure, that consists of a single VPC, to allow workloads from all divisions to communicate with each other. You want to avoid incurring extra costs and granting unnecessary permissions to the new division's networking team. What should you do?
  1. Create a new project for the new division's network team. • Create a new VPC within the new project. • Establish a VPC peering between your existing VPC and the new division’s VPC. • Create a new subnet dedicated to the new division's workloads. • Grant roles/compute.networkUser on the new project to the new division’s network team group.
  2. Create a new project for the new division's network team. • Create a new VPC within the new project. • Establish a VPC peering between your existing VPC and the new division’s VPC. • Grant roles/compute.networkAdmin on the newly created project to the new division's network team group.
  3. Ensure that the project hosting the existing network infrastructure is enabled as a host project. • Create a new subnet dedicated to the new division's workloads in the existing VPC. • Grant roles/compute.networkUser on the newly created subnet to the new division’s network team group. Correct Answer
  4. Create a new project for the new division's network team. • Create a new VPC within the new project. • Establish a VPN connection between your existing VPC and the new division's VPC. • Grant roles/compute.networkAdmin on the newly created project to the new division's network team group.

Key Takeaways

The main trap is choosing VPC peering (Option B) which incurs data transfer costs, whereas Shared VPC (Option C) allows granular subnet-level control with no additional networking fees.

This page explains how to use Google Cloud Shared VPC to grant isolated network control to new teams without incurring VPC peering costs or over-provisioning IAM permissions.

Common mistake: Choosing Option B because it seems to offer more isolation; however, it fails the cost constraint due to peering data transfer fees and grants overly broad project-level admin rights.

Expert Analysis

The question presents a conflict between two primary requirements: granting the new division 'complete control' over their infrastructure while simultaneously avoiding 'extra costs' and 'unnecessary permissions'. Option B proposes creating a separate project with VPC peering. While this provides isolation, VPC peering in Google Cloud incurs egress data transfer costs when traffic leaves the network boundary, violating the cost constraint. Furthermore, granting roles/compute.networkAdmin on a new project is a broad permission that exceeds the principle of least privilege if they only need to manage their specific subnets.

Option C leverages Shared VPC (Host Project). By enabling the existing project as a host project, you can create service projects for each division. The key mechanism here is attaching subnets from the host VPC to the service project. This allows the new division's team to be granted roles/compute.networkUser specifically on their dedicated subnet within the shared VPC. This role grants them full control over the resources (instances, firewall rules associated with those instances) within that subnet without giving them admin rights to the entire VPC or other divisions' resources. Since the VPC and subnets are already provisioned, there are no extra setup costs beyond standard compute usage, and inter-division communication happens via internal IP addresses within the same VPC, incurring zero data transfer fees.

The trap in Option B is assuming that 'complete control' requires a completely separate VPC project structure, ignoring the cost implications of peering and the granularity of IAM roles available in Shared VPC. Comments supporting B often overlook the explicit 'avoid extra costs' constraint and misinterpret 'control' as needing admin access to the whole project rather than scoped user access to specific subnets.

Official Reference

https://cloud.google.com/vpc/docs/shared-vpc

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always map 'avoid extra costs' to internal VPC communication when possible. If the scenario involves multiple teams needing isolated management but sharing underlying infrastructure, prioritize Shared VPC with subnet-level IAM (compute.networkUser) over separate VPCs with peering, which introduces egress charges.

Frequently Asked Questions

Why is VPC peering considered an 'extra cost' in this context?

VPC peering incurs data transfer charges for traffic leaving the network boundary. In a Shared VPC, all traffic remains within the same VPC network, so there are no inter-zone or inter-region data transfer fees for internal communication.

Does compute.networkUser provide complete control over a subnet?

Yes, within the scope of that subnet. It allows users to create, configure, and delete resources like VMs and firewall rules associated with the subnet, fulfilling the 'complete control' requirement for their specific workloads without accessing other parts of the VPC.

More PCNE FAQ →

Community Votes

B
100%

100% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. zzaric 👍 1 Answered B
    By creating a brand new project and VPC for the acquired division and granting them the compute.networkAdmin role specifically on that new project, you give them full autonomy to manage their own subnets, firewall rules, and routing. Because this permission is isolated to their project, you avoid granting them unnecessary permissions in your existing, primary environment.
  2. ulkerra 👍 1 Answered B
    "The new division's network team requires complete control over their networking infrastructure" is the requirement. networkuser role does not give complete control.Networkadmin is needed
  3. 8e50960 👍 1 Answered B
    Complete control over the network bandwidth means, networkAdmin. Also peering two VPCs is more cost effective and has better performance than VPN.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Configuring Policy-Based VPN for Non-BGP On-Premises Networks

S-grade

Deploying Packet Mirroring Policies in GCP Regions

S-grade

Troubleshooting Asymmetric Traffic on Google Cloud Interconnect

S-grade

Hub-and-Spoke Centralized Egress with VPC Peering

S-grade

Practice All PCNE Questions

Access 80 questions with complete answers and detailed explanations.

View Full PCNE Practice Test →

← Back to PCNE Study Guide