Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Prepare and test your skills
Prepare and test your skills
Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise designs a multi-VPC architecture on Google Cloud featuring a central hub VPC network connected to multiple independent spoke VPC networks using VPC Network Peering. The central hub hosts shared security and management tools and provides the sole connection to the corporate on-premises data center.
Security policies require workloads in Spoke-A to communicate with workloads in Spoke-B, while ensuring all inter-spoke traffic is inspected centrally within the hub network. Direct VPC peering connections between spokes are prohibited.
Which network design should you implement to enable inter-spoke communication?
Migrate all workloads to a single Shared VPC network and create overlapping subnet CIDR blocks across the different service projects for workload segregation.
Deploy Private Service Connect endpoints in Spoke-A that point directly to the default internet gateway of Spoke-B.
Deploy redundant Network Virtual Appliances (NVAs) behind an internal Network Load Balancer in the hub VPC, and configure custom route exchange across the VPC peering connections.
Enable transitive route propagation on Cloud Router instances in the hub VPC network to automatically advertise spoke subnets to all peered spoke VPCs.
Migrate all workloads to a single Shared VPC network and create overlapping subnet CIDR blocks across the different service projects for workload segregation.
Deploy Private Service Connect endpoints in Spoke-A that point directly to the default internet gateway of Spoke-B.
Deploy redundant Network Virtual Appliances (NVAs) behind an internal Network Load Balancer in the hub VPC, and configure custom route exchange across the VPC peering connections.
Network Virtual Appliances (NVAs) are third-party or custom routing and firewall instances deployed within a Virtual Private Cloud (VPC). In a Google Cloud hub-and-spoke model using VPC Network Peering, NVAs deployed behind an internal Network Load Balancer serve as next-hop gateways that inspect, allow, or deny network traffic passing between peered networks.
StudyCerts
StudyCertsSpoke-A cannot communicate directly with Spoke-B through the hub VPC using native VPC routing alone.This architecture complies strictly with Google Cloud network design best practices for hub-and-spoke topologies. It respects the non-transitive property of VPC peering while satisfying enterprise governance requirements for central traffic inspection.
Enable transitive route propagation on Cloud Router instances in the hub VPC network to automatically advertise spoke subnets to all peered spoke VPCs.