Google Professional Cloud Network Engineer

Incorrect. Shared VPC can centralize networking, but it requires migrating/standardizing projects to use those host projects and doesn’t automatically cover all existing VPCs in all projects under the folders. It also adds operational complexity (host/service project model, IAM, attachment management). The question asks for enforcement across all VMs in every project under folders, which hierarchical firewall policies address more directly.

Incorrect. Creating VPC firewall rules in every VPC of every project is not scalable and is prone to configuration drift and human error. It also increases operational cost over time as new projects/VPCs are created. This approach does not provide strong guardrails: a project owner could accidentally remove or change rules, especially in Compliance where “must be denied” implies a centrally enforced control.

Incorrect. Anthos Config Connector is primarily a Kubernetes-based configuration management tool to create/manage Google Cloud resources declaratively. It is not the most appropriate or lowest-cost mechanism for org-wide VM firewall enforcement, and it introduces additional platform dependencies (GKE/Anthos, controllers, lifecycle management). Even if used, the underlying correct control would still be hierarchical firewall policies, making this option indirect and unnecessarily complex.

Incorrect. Access Context Manager policies and VPC Service Controls perimeters are designed to restrict access to Google Cloud APIs and managed services to reduce data exfiltration risk. They do not enforce source IP allowlists for raw L4 traffic from the internet to an external passthrough Network Load Balancer VIP. Health checks and client TCP flows to port 1935 are not controlled by VPC Service Controls.

Incorrect. You cannot meaningfully “add the external load balancer as a protected service” in VPC Service Controls to restrict who can open TCP connections to the load balancer’s public IP. VPC Service Controls applies to supported Google services (API endpoints) and does not function as an internet-facing L4 firewall for passthrough NLB traffic.

Incorrect. VPC firewall rules cannot target instances by labels. Firewall rule targets can be specified using network tags or service accounts (and apply within the VPC). While labeling is useful for organization and billing, it is not a valid selector for firewall enforcement, so this option is not implementable as stated.

This leaves Cloud Storage on its default public endpoint along with every other Google API and service. As a result, on-premises Cloud Storage access would continue to use the public internet path through NAT rather than traversing Dedicated Interconnect. That directly violates the compliance requirement. Although it preserves the current behavior for other APIs, it fails the most important condition in the question.

This option would direct Cloud Storage to restricted.googleapis.com, but it would also direct all other Google APIs and services to private.googleapis.com. Both restricted.googleapis.com and private.googleapis.com are private Google API VIPs intended to be reached over private connectivity, so this would move other API traffic off the public NAT path. That contradicts the explicit requirement that all non-Cloud Storage Google API traffic must continue to egress over the public internet. Therefore, C over-applies private access and does not satisfy the selective-routing requirement.

This option sends Cloud Storage to private.googleapis.com and all other Google APIs and services to restricted.googleapis.com. In either case, both categories are still being directed to private Google API VIPs rather than leaving non-Storage APIs on public endpoints. That means other Google API traffic would no longer continue over the public internet via NAT, which violates the requirement. It also inverts the intended control posture by applying the more restrictive endpoint to the broader set of services.

This option is not the best choice because it places the inspection appliance in a Service Project even though the question emphasizes centralized Shared VPC management by the Network Operations team. While service-project VMs can attach to Shared VPC subnets, hosting a shared inline security function there creates split ownership and is less aligned with centralized governance. It also omits enabling IP forwarding, which is required for a VM to operate as a transit appliance. Because of both the governance mismatch and the missing forwarding requirement, this is inferior to A.

Incorrect. Using a single VPC with two NICs on different subnets can be used for some appliance patterns, but it does not provide the same strong segmentation and forced transit boundary as two separate VPCs. In a single VPC, it is easier to inadvertently allow bypass paths via routing, and the design is less aligned with a clear north–south “outside/inside” separation for URL filtering appliances.

Incorrect. This violates the stated requirement that Shared VPC is centrally managed and also misstates Shared VPC structure: a “Shared VPC Service Project” does not own the VPC network; the Host Project does. Creating the VPC in a service project would not meet the Shared VPC governance model described, and it would not provide the centralized control expected for an inline security enforcement point.

Incorrect. While 10.30.20.0/22 and 172.25.40.0/22 summarize the three /24s, they also include an extra /24 on each side (10.30.23.0/24 and 172.25.43.0/24). Policy-based VPNs often require selectors to match the actual encryption domains exactly; adding unintended ranges can cause negotiation mismatch or encrypt traffic you did not intend.

Incorrect. This option reverses the meaning of LOCAL_TS and REMOTE_TS from the perspective of the on-prem firewall. LOCAL_TS must represent the local (warehouse) networks behind the firewall, and REMOTE_TS must represent the remote (Google Cloud VPC) networks. Swapping them commonly prevents the tunnel from establishing because the proposed selectors do not match expectations.

Incorrect. Using REMOTE_TS as 0.0.0.0/0 is characteristic of route-based VPN designs (often with dynamic routing/BGP) and creates an overly broad encryption domain. With a policy-based VPN requirement, Google Cloud expects specific remote prefixes; 0.0.0.0/0 may be rejected, fail to match configured routes/selectors, or unintentionally send all traffic into the tunnel.

Incorrect because it sets Peer ASN to 65001, which is Google Cloud’s ASN, not the partner’s. In Cloud Router BGP peer configuration, “Peer ASN” must be the remote ASN (here 65044). The IPs and MD5 setting are otherwise aligned, which can make this option tempting, but the ASN mismatch prevents a proper eBGP session.

Incorrect because it swaps the local and peer BGP IP addresses. Google’s local BGP IP should be 169.254.22.2 and the partner’s peer IP should be 169.254.22.1, per the provided parameters. Reversing these addresses will cause BGP neighbor establishment to fail even though the IPSec tunnel is up.

This option is incorrect because it enables MD5 authentication even though the partner explicitly stated that MD5 authentication is disabled. BGP authentication settings must match on both sides, and a mismatch will prevent the BGP session from establishing even if the IPSec tunnel itself is up. The local and peer IPs and peer ASN are otherwise aligned, which makes this a plausible distractor. The route priority value of 1000 is not the key problem here; the MD5 mismatch is sufficient to make the configuration fail.

Firewall rules logging records allow/deny decisions and some connection metadata in Cloud Logging, but it does not capture full packets or payloads. Forwarding logs to an IDS would not provide the raw traffic needed for deep packet inspection and signature-based detection. It also introduces log processing latency and does not meet the explicit “packet payloads” requirement.

VPC Flow Logs capture network flow metadata (e.g., src/dst IP, ports, protocol, bytes, packets, start/end time) and are useful for visibility and troubleshooting, not payload inspection. Even with a Logging sink and filtering for egress, you still cannot reconstruct packet contents. This fails the IDS requirement for mirrored packets with payloads.

An internal HTTP(S) load balancer is a proxy-based Layer 7 service and is not used as a Packet Mirroring collector. Packet Mirroring collectors require an internal passthrough Network Load Balancer (TCP/UDP) so the mirrored packets are delivered without L7 termination or protocol constraints. Additionally, “HTTP(S)” would not cover arbitrary egress traffic (non-HTTP) from the subnets.

Incorrect. A Kubernetes Service does not contain HTTP path rules; it is primarily an L4 construct (ClusterIP/NodePort/LoadBalancer) that selects Pods and exposes ports. Adding a “*” path rule to a Service is not a valid or effective way to influence a Google Cloud HTTP(S) Load Balancer URL map. Path-based routing is configured in the Ingress resource, not the Service.

Incorrect. While the Ingress is the right place to change routing, adding a path rule for “*” is not the correct or portable approach. Kubernetes Ingress path matching is typically Prefix or Exact; “*” is not a standard path pattern and may not be accepted or may behave unexpectedly. The clean, supported solution for unmatched paths is to use a default backend (or explicitly add a “/” prefix rule).

Incorrect. Services do not support defining an Ingress-style default backend. The concept of a default backend belongs to the Ingress/HTTP(S) load balancing layer (URL map). Editing the Service YAML cannot change how the external HTTP(S) Load Balancer matches paths or what it does when no path rule matches; only the Ingress configuration can do that.

This option is incomplete because it leaves the spokes’ own default internet gateway routes in place. In Google Cloud, a local route in the spoke VPC is preferred over a route learned through VPC peering, so the imported 0.0.0.0/0 from the hub would not actually be used for internet egress. As a result, spoke workloads would continue to exit directly to the internet instead of traversing the hub firewalls. That violates the explicit requirement that every spoke must use the hub firewalls for all internet-bound traffic.

This option uses individual firewall instances as route next hops instead of the internal passthrough NLB VIP, which is not the best high-availability design for the stated architecture. The question explicitly says the firewalls are deployed behind a regional internal passthrough Network Load Balancer, and that VIP is the supported resilient next hop for steering traffic to the active appliance. Using per-instance next hops complicates failover and can lead to asymmetric or failed routing during appliance outages. It also does not address the spoke-side route-precedence problem as clearly as the best answer does.

This option is invalid because a spoke VPC cannot create a static route with a next hop that is an internal passthrough load balancer VIP located in a different VPC over VPC peering. The supported model is to create the custom route in the hub and exchange it through peering by enabling export and import of custom routes. Directly referencing the remote VIP from the spoke bypasses the peering route-exchange mechanism and is not how next hops work across peered VPCs. Therefore, it does not meet the technical constraints or the intended centralized egress design.

Incorrect. You cannot create Cloud Router “in the VPC networks of all projects” to solve Shared VPC hybrid routing. Cloud Router is tied to a specific VPC network, and in Shared VPC the VPC network exists in the host project. Service projects don’t have separate VPC networks for the shared subnets; they attach to the host’s VPC. Multiple routers in multiple projects would not provide shared VPC route exchange.

Incorrect. Creating the Cloud Router in the Finance service project would not attach it to the Shared VPC host project’s VPC network. Service projects typically do not own the shared VPC network; they only use subnets from the host. As a result, the VLAN attachments/BGP sessions for the Dedicated Interconnect would not be correctly associated with the central VPC used by all departments.

Incorrect. R&D, HR, and Finance are service projects and do not each have their own VPC network for the shared subnets; they attach to the host project’s VPC. Creating separate Cloud Routers in each service project would not connect those routers to the shared VPC, and would not correctly terminate the VLAN attachments for the Dedicated Interconnect that must be associated with the host VPC.

compute.networkUser is intended for service projects or principals that need to attach resources such as VMs or load balancers to a shared VPC network or subnet. It does not provide the broad read-only visibility into firewall rules across projects that the troubleshooting requirement calls for, nor does it align with administering network topology resources. This role is about consuming networks, not inspecting firewall policy. Therefore it does not meet the stated operational need.

compute.networkAdmin is too permissive because it includes the ability to manage firewall rules in addition to other networking resources. That directly violates the separation-of-duties requirement that the Compliance team owns firewall rules and SSL certificates for audit purposes. Even though it would let the networking team troubleshoot, it would also let them create, modify, or delete firewall rules, which the question explicitly forbids. Least privilege rules this option out immediately.

A custom role containing only compute.networks.* and compute.firewalls.list is incomplete for the responsibilities described. The scenario says the Platform Networking team administers VPCs, subnets, routes, and peering, but compute.networks.* covers only network resources and does not include the separate permission families for subnetworks, routes, and network peerings. In addition, limiting firewall access to only list is narrower than the stated read/list need and may not support full troubleshooting visibility. Because the custom role omits required networking administration permissions, it does not satisfy the full requirement.

Incorrect. Regional network load balancers are L4 and regional; they don’t provide a single global anycast endpoint. Cloud CDN is not enabled on a regional TCP/UDP network load balancer (CDN integrates with external HTTP(S) load balancing). Using two IPs in DNS (round-robin) is not health-aware and can continue sending users to an unhealthy region due to DNS caching/TTL, hurting outage resilience.

Incorrect. You do not need separate VPCs or VPC peering to use a global external HTTP(S) load balancer with backends in multiple regions; a single VPC is standard. Also, Cloud DNS should typically use an A/AAAA record to the load balancer’s IP; a CNAME is not used to point directly “to the load balancer” unless you have a provided DNS name (the LB primarily exposes an IP). This adds complexity without benefit.

Incorrect. Standard Network Tier does not provide a global anycast IP for external HTTP(S) load balancing; it is regional and won’t meet the “single global endpoint minimizing latency” requirement. Additionally, a CNAME record cannot point to an IP address (CNAME targets must be hostnames). Even if corrected to an A record, Standard Tier would still not satisfy the global latency and resilience goals.

Incorrect. Adding 203.51.64.0/19 to nonMasqueradeCIDRs disables pod-to-node SNAT for that destination, which preserves the pod IP rather than translating it to the node IP. That does not inherently cause Cloud NAT to be used, and in a cluster whose nodes have external IPs it does not solve the stated requirement. The explanation confuses disabling ip-masq with forcing Cloud NAT, which are not equivalent behaviors. This option changes pod source preservation, not Cloud NAT eligibility.

Incorrect. Cloud NAT does not provide a destination-based exclusion rule that says 'do not translate traffic to this external CIDR.' Cloud NAT is attached to a Cloud Router and subnet ranges, and its behavior is not configured as per-destination internet exclusions in the way this option describes. Therefore this is not a valid or meaningful configuration change for the requirement. The option is based on a feature that Cloud NAT does not expose.

Incorrect. Cloud NAT has no configuration called nonMasqueradeCIDRs, and it does not consume or mirror ip-masq-agent settings. This option incorrectly mixes Kubernetes pod SNAT controls with VPC egress NAT controls as if they were one system. Because the two layers are independent, duplicating a list in Cloud NAT is not a supported solution. The wording is technically inaccurate and does not describe a real configuration pattern.

A global external HTTP(S) load balancer provides an external anycast VIP and L7 routing, not a way to make VMs natively own addresses from an internal RFC1918 range like 192.168.70.0/24. It also introduces a new front end (a managed gateway) and is protocol-specific (HTTP/S). This violates the requirement to avoid new gateways and doesn’t satisfy “instances have addresses in both ranges.”

DNS records can direct clients to different IPs, but DNS does not assign IP addresses to VM interfaces. If the VM does not actually have 192.168.70.0/24 addresses configured, it cannot receive traffic destined to those IPs (unless another device/load balancer owns them). DNS is a naming solution, not an IP addressing mechanism, so it cannot meet the requirement.

VPC peering connects two separate VPC networks and exchanges routes, but it does not make a single VM interface hold IPs from two unrelated ranges. You would still need the 192.168.70.0/24 range to exist as a subnet/secondary range somewhere and a way to assign those IPs to the VM. Peering also adds architectural complexity and doesn’t meet the “same instances have addresses in both ranges” requirement.

Incorrect. Reserving a static external IP and using an external HTTP(S) load balancer creates an internet-reachable frontend by design. Even if backends are private, the forwarding rule is public and violates the requirement that the service be internal-only and not exposed. It also adds unnecessary cost and complexity compared to built-in internal DNS for VM discovery.

Incorrect. This option explicitly creates a public DNS A record and uses an external HTTP(S) load balancer with a static external IP. That contradicts the requirement to avoid public DNS records and to not expose the service. Even if access is restricted at the firewall, the endpoint is still publicly addressed and increases attack surface and operational overhead.

Incorrect. A short alias like https://metrics/v1/ is not something Compute Engine automatically provides. Default search domains are not guaranteed to resolve arbitrary hostnames unless you configure custom DNS (for example, a private Cloud DNS zone with an A record for “metrics”). Without that configuration, clients will fail to resolve the name, so it is not a reliable built-in solution.