How to Scale Hub-and-Spoke Topology Beyond 50 Spokes in GCP?

PCNE By islever Editorial Last updated

Short answer

C Connect all the spokes to the hub with Cloud VPN. Use a third-party network appliance as a default gateway to prevent connectivity between the spokes.

Question

You are a network administrator at your company planning a migration to Google Cloud and you need to finish the migration as quickly as possible. To ease the transition, you decided to use the same architecture as your on-premises network: a hub-and-spoke model. Your on-premises architecture consists of over 50 spokes. Each spoke does not have connectivity to the other spokes, and all traffic is sent through the hub for security reasons. You need to ensure that the Google Cloud architecture matches your on-premises architecture. You want to implement a solution that minimizes management overhead and cost, and uses default networking quotas and limits. What should you do?
  1. Connect all the spokes to the hub with Cloud VPN.
  2. Connect all the spokes to the hub with VPC Network Peering.
  3. Connect all the spokes to the hub with Cloud VPN. Use a third-party network appliance as a default gateway to prevent connectivity between the spokes. Correct Answer
  4. Connect all the spokes to the hub with VPC Network Peering. Use a third-party network appliance as a default gateway to prevent connectivity between the spokes.

Key Takeaways

Evaluates your ability to choose scalable networking solutions while avoiding the VPC peering quota trap that blocks large-scale deployments.

This scenario tests scalable GCP hub-and-spoke design and spoke isolation enforcement. The community consensus confirms that Cloud VPN paired with a centralized firewall appliance is required due to strict VPC peering quotas.

Common mistake: Candidates frequently select VPC Network Peering for its seamless routing and low latency, overlooking the hard limit of 25 connections per VPC which makes it unviable for 50+ spokes.

Expert Analysis

Why the Answer Is Correct

Cloud VPN provides virtually unlimited scalability for attaching dozens of spokes to a central hub, comfortably handling the 50+ requirement. Deploying a third-party network appliance in the hub serves as a centralized default gateway, enforcing strict isolation between spokes while permitting controlled egress traffic. This design directly mirrors the requested on-premises security model while adhering to default quota constraints. It eliminates the need for complex transitive routing configurations by relying on explicit firewall rules at the hub level.

Why the Other Options Are Wrong

VPC Network Peering is strictly capped at 25 connections per VPC, rendering options B and D architecturally impossible for this scale. Even with higher quotas, peering operates on a non-transitive basis, meaning spoke traffic cannot naturally flow through the hub without additional routing policies or external gateways. Option A fails to address the mandatory security requirement, as raw VPN tunnels alone cannot block unauthorized spoke-to-spoke communication without a dedicated inspection appliance.

Community Comment Notes

Multiple contributors identified the 25-connection VPC peering ceiling as the primary reason to eliminate peering-based answers entirely [1][2][4]. Several test-takers initially favored peering for its simplicity and bandwidth benefits but corrected their selection after consulting official Google topology guides [5][7]. Experienced users strongly advocated for marketplace third-party firewalls to satisfy both the isolation mandate and the scalability constraint efficiently [3][6].

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Always cross-check service-specific quotas and architectural limits before selecting managed networking features during migration scenarios. Prioritize solutions that explicitly satisfy both functional isolation requirements and administrative constraints like default resource caps.

Community Votes

C
100%

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

Discussion 8 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 8

  1. 3fd692e 👍 4 Answered C
    Correct answer is C. Forget the points about non-transitive routing that folks are making. The key point is in the question that they want to stay within the GCP quotas and limits. VPC peering max is 25. The customer has 50 spokes in their on-premises hub-n-spoke design and the want to "replicate" that design in the cloud. VPC peering won't work as 50 is beyond the limit. Answer is C.
  2. gonlafer 👍 3 Answered C
    VPC Network Peering connections are limited to 25 connections per VPC network.
  3. ian_gcpca 👍 2 Answered C
    I considered D, since best answer if you think about latency, ha, setup complexity. But with the non-transitive routing point and the number of spokes (50) beyond vpc peering limit (25), and they just want to keep the same archi of on-prem, the best answer is using VPN then use 3rd party network appliance (can be in marketplace) to address the other requirement to prevent other spokes to communicate
  4. PeppaPig 👍 2
    Can't be VPC peering. Google VPC supports up to 25 peering connections per VPC, here we need to connect 50 spokes. C is correct
  5. [Removed] 👍 1 Answered D
    VPC Network Peering is a simple and a low cost way to connect VPC networks without using any external IP addresses or VPN gateways. It does not consume any quota or limit for VPN tunnels, external IP addresses, or forwarding rules. So, use it to conect the spokes to the hub. To fully prevent connectivity between the spokes, use a third-party network appliance as a default gateway (also if by default spokes can't communicate with the hub)
Show 3 more comments
  1. netmaster81 👍 1 Answered B
    VPC Network Peering has the non-transitivity constraint, but it supports the full bandwidth defined by the machine type of the VMs and other factors that determine network bandwidth. However, you can add transitive routing by adding VPN tunnels. https://cloud.google.com/architecture/deploy-hub-spoke-vpc-network-topology VPC peering can't provide interconnection between spokes
  2. hamish88 👍 1 Answered A
    As per the following link, we should use a third-party network appliance or an NGFW as a default gateway in providing inter-spoke communications, not to prevent connectivity between spokes https://cloud.google.com/architecture/deploy-hub-spoke-vpc-network-topology
  3. desertlotus1211 👍 2
    It either A or C

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.

Submitted for moderation before publishing. Keep it helpful and respectful.

How to Resolve BGP Session Failures on Cloud Interconnect?

S-grade

Deploying Packet Mirroring Policies in GCP Regions

S-grade

Troubleshooting Asymmetric Traffic on Google Cloud Interconnect

S-grade

How to Configure DNS Forwarding Across Isolated VPC Networks?

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