Google ACE Practice Question: Two GCP projects, A and B, have VPC peering…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Yes — VPC peering automatically enables transitive routing through intermediate peered networks

  Why it's wrong here

  GCP's VPC peering is explicitly non-transitive, meaning that if A is peered with B and B is peered with C, A and C do not gain any connectivity through B. The peering session creates an exchange of routes only between the two participating VPCs, and Cloud Router or VPC peering does not re-advertise routes learned from one peer into another peer. This design prevents hairpin traffic and provides predictable, isolated network paths, so a single intermediate peered network cannot serve as a transit hub unless you set up a dedicated appliance (like a VPN gateway or a custom router) with explicit forwarding in a different configuration.

• ✓

  No — VPC peering is non-transitive; A and C must be directly peered to communicate

  Why this is correct

  VPC peering in GCP is a one-to-one relationship that does not support transitive routing, so Project A's VPC can only reach the directly peered VPC in Project B, not any VPC that B happens to be peered with (like C). Even if B's VPC has a peering connection to C, routes learned from C are not propagated through B to A because GCP exchanges only the routes of the two directly peered networks. To allow A and C to communicate, you must create a direct VPC peering between Project A and Project C, or alternatively use a shared VPC, a Cloud VPN, or a proxy/load balancer to bridge the two networks.

• ✗

  Yes — if Project B has IP forwarding enabled, it acts as a router between A and C

  Why it's wrong here

  Enabling IP forwarding on Project B's VM changes how that VM handles packets that arrive on one interface and leave on another, but it cannot create a route between two separate VPCs that are only linked by peering. VPC peering in GCP is a direct, one-hop relationship: a peered VPC appears in the route table only as a next hop for that specific peer, not for any network beyond it. IP forwarding on an instance is relevant for network appliances or NAT instances within a single VPC's routing path, but it does not override the non-transitive peering model, so A→B→C still fails.

• ✗

  It depends on the firewall rules in Project B's VPC

  Why it's wrong here

  Firewall rules in Project B's VPC determine which packets are permitted, dropped, or rejected based on source, destination, port, and protocol — but they do not influence the routing table that decides whether traffic from A can be forwarded to C. In GCP's VPC peering, the peering itself only exchanges routes between the two directly peered networks; it does not propagate routes from C into A's route table, nor from A into C's. Even with permissive firewall rules allowing all traffic in B, the packet from A to C would be dropped at the routing layer because B's VPC has no route to C that is reachable via A — the topology is non-transitive, so firewall rules are not the deciding factor.

Go deeper

Related to this question