How to Route Inter-Subnet Traffic Through NVAs Using Policy-Based Routing?

Your frontend application VMs and your backend database VMs are all deployed in the same VPC but across different subnets. Global network firewall policy rules are configured to allow traffic from the frontend VMs to the backend VMs. Based on a recent compliance requirement, this traffic must now be inspected by network virtual appliances (NVAs) firewalls that are deployed in the same VPC. The NVAs are configured to be full network proxies and will source NAT-allowed traffic. You need to configure VPC routing to allow the NVAs to inspect the traffic between subnets. What should you do?

Place your NVAs behind an internal passthrough Network Load Balancer named ILB1. Add the global network firewall policy rules to allow traffic through your NVAs. Create a policy-based route (PBR) with the source IP range of the backend VM subnet, destination IP range of the frontend VM subnet, and the next hop of ILB1. Scope the PBR to the VMs with the backend network tag. Add a backend network tag to your backend servers.
Place your NVAs behind an internal passthrough Network Load Balancer named ILB1. Add global network firewall policy rules to allow traffic through your NVAs. Create a custom static route with the destination IP range of the backend VM subnet, frontend instance tag, and the next hop of ILB1. Add a frontend network tag to your frontend VMs.
Create your NVA with multiple interfaces. Configure NIC0 for NVA in the backend subnet. Configure NIC1 for NVA in the frontend subnet. Place your NVAs behind an internal passthrough Network Load Balancer named ILB1. Add global network firewall policy rules to allow traffic through your NVAs. Create a custom static route with the destination IP range of the backend VM subnet, frontend instance tag, and the next hop of ILB1. Add a frontend network tag to your frontend VMs.
Place your NVAs behind an internal passthrough Network Load Balancer named ILB1. Add global network firewall policy rules to allow traffic through your NVAs. Create a policy-based route (PBR) with the source IP range of the frontend VM subnet, destination IP range of the backend VM subnet, and the next hop of ILB1. Scope the PBR to the VMs with the frontend network tag. Add a frontend network tag to your frontend servers. Source Reference Answer

Community Votes

100%

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

Community Insight

Tests PBR configuration for traffic inspection; the common trap is misidentifying the source and destination subnets or incorrectly applying instance tags.

This question tests configuring Google Cloud VPC policy-based routes (PBR) to direct inter-subnet traffic through network virtual appliances (NVAs). The community unanimously agrees that scoping PBR to the frontend subnet ensures traffic flows through the proxy NVAs while respecting global firewall policies.

Option A incorrectly reverses the source and destination IP ranges and scopes the route to backend servers, which would intercept return traffic instead of outbound frontend traffic.

Community Discussion (3 comments)

Gwendal 👍 1 Selected: D

https://cloud.google.com/vpc/docs/policy-based-routes

RKS_2021 👍 1 Selected: D

D is correct

09bd94b 👍 2 Selected: D

D looks correct to me

Comments & Corrections

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

Expert Analysis

Why the Answer Is Correct

Policy-based routing (PBR) is required because static routes cannot match source IP ranges or instance tags. By defining a PBR with the frontend subnet as the source and the backend subnet as the destination, all outbound application traffic is explicitly directed to the internal load balancer fronting the NVAs. Scoping the route using the frontend instance tag ensures precise targeting without affecting other VPC traffic. The global firewall policy permits this flow once the NVA performs its proxy inspection and forwards the traffic.

Why the Other Options Are Wrong

Option A reverses the source and destination logic, causing return traffic to be misrouted rather than initial requests. Option B uses a custom static route, which lacks the capability to filter by source IP range or instance tags, making it incapable of selectively steering frontend traffic. Option C unnecessarily complicates the architecture with multi-NIC configurations and static routes, ignoring the native PBR feature designed specifically for this use case.

Community Comment Notes

Candidates consistently validate Option D by referencing official Google Cloud documentation on policy-based routes. Comments highlight that PBR is the standard mechanism for integrating third-party firewalls and NVAs into existing VPC topologies. Several users note that correctly tagging the frontend instances is critical for the scope parameter to function as intended.

Official Reference

https://cloud.google.com/vpc/docs/policy-based-routes

Exam Strategy

Always identify whether the routing requirement demands source-based filtering or tag-based scoping before choosing between static and policy-based routes. When designing transparent or proxy firewall deployments, remember that PBR must point to the next hop that actually receives the unencrypted traffic before the NVA processes it.

Related Analysis

Practice All PCNE Questions

Access 80 questions with complete answers and detailed explanations.

View Full PCNE Practice Test →

← Back to PCNE Study Guide