GCP-ACE - Planning and implementing a cloud solution (30% of the exam) - Section 2.3
Plan and implement networking resources, creating VPCs with subnets including Shared VPC and VPC Network Peering, creating and applying VPC firewall rules and Cloud NGFW policies, establishing connectivity with Cloud VPN and Cloud Interconnect, choosing load balancers, and differentiating Network Service Tiers.
Design a VPC with custom-mode subnets, and decide between Shared VPC and VPC Network Peering for connecting projects. Author firewall rules and Cloud NGFW policies with the correct direction, priority, action, and targets, connect networks with Cloud VPN, peering, or Cloud Interconnect, choose the load balancer type that matches the traffic and scope, and pick a Network Service Tier for the cost against performance trade-off.
VPC and subnetsShared VPCCloud NGFWCloud InterconnectLoad balancer selectionNetwork Service Tiers
Practice question for this objective
lock_openFree samplePlanning and implementing a cloud solutionhard
An organisation wants a central networking team to own subnets, firewall rules, and IP ranges, while several application teams deploy virtual machines that attach directly into those shared subnets across projects. Which capability meets this requirement?
AVPC Network Peering between each application project and the central project, so workloads reach the shared subnets over private addresses.
BA custom-mode VPC network replicated in each application project, kept aligned by exporting and importing the same subnet definitions across them.
CCloud NGFW policies applied at the organisation node, which let application projects borrow subnets defined higher in the resource hierarchy.
DShared VPC, where the central project is the host project and the application projects are service projects using the shared subnets.check_circle Correct
Shared VPC lets a host project own the network and subnets while service projects deploy resources directly into those shared subnets. Shared VPC centralises the network, subnets, and firewall rules in a host project and grants service projects the ability to attach resources into shared subnets, which peering and copied networks cannot do because they keep each network's subnets separate.
Why A is wrong: Peering connects two separate VPC networks and lets them route to each other privately, but each side keeps its own subnets and firewall rules. It does not let application virtual machines attach into subnets the central team owns, which is the stated need.
Why B is wrong: Copying subnet definitions into separate networks produces independent VPCs, not shared ownership. There is no import mechanism that makes application virtual machines attach into a central team's subnets, so the central control requirement is unmet.
Why C is wrong: Firewall policies can be attached to organisation or folder nodes to govern traffic, but they filter packets rather than share subnets. Subnets are not inherited down the hierarchy, so this does not give application teams access to central subnets.
Why D is correct: Correct: Shared VPC designates a host project that owns the network, subnets, and firewall rules, and service projects place virtual machines directly into those shared subnets, centralising control exactly as described.
Exam traps in Planning and implementing a cloud solution
Answers that look right on this material and are not. Each one is a distractor from a different question in the GCP-ACE bank for this domain.
In each service project separately, an ingress allow rule on TCP 5432 with source tag web and target tag db, so both projects agree on the flow.
errorWhy it is wrong: Service projects do not own the shared network's firewall rules, so rules created there do not apply; the rule must exist in the host project.
Nominate one subsidiary's project as a Shared VPC host and attach the other subsidiary's project as a service project so both can share subnets.
errorWhy it is wrong: Shared VPC centralises network control in the host project, so one subsidiary would administer the other's networking, which directly violates the stated requirement that neither cedes control.
The peerings must share an identical primary subnet range end to end, and a range mismatch between A and C is silently dropping the traffic.
errorWhy it is wrong: Peering actually requires that subnet ranges do not overlap, not that they match. Identical ranges would block the peering, so this reverses the real constraint and does not explain the missing A-to-C path.