Google Professional Cloud Network Engineer (PCNE) — Questions 301–375

IAM roles with the `compute.firewalls.create` permission at the host project level allow you to precisely control which service projects can create firewall rules in the Shared VPC host project. By assigning a custom or predefined role (e.g., Compute Security Admin) that includes this permission to specific service project identities, you can restrict firewall rule creation to only authorized service projects while preventing others from doing so.

Private Service Connect allows publishing internal services via private endpoints in your VPC and enabling consumption from other VPCs using private IPs.

DNS forwarding zones in Cloud DNS allow you to forward queries for a specific domain to a set of on-premises DNS server IPs. This is achieved by creating a forwarding zone with the target name servers pointing to the on-premises DNS servers.

VPC Service Controls allow you to define perimeters around Google Cloud resources, restricting access to Google APIs based on the perimeter's configuration. VPC accessible services is a feature within VPC Service Controls that limits access to only the APIs listed in the perimeter.

Cache invalidation removes objects from cache but does not prevent new requests from being served stale content if the origin returns a 304 Not Modified or if there is a propagation delay. However, the most common cause is that the invalidation has not propagated to all edge caches yet.

It defines an ingress firewall rule that allows TCP traffic on port 3306 (MySQL) from VMs using the service account 'web-sa@project.iam.gserviceaccount.com' as the source, targeting VMs with the network tag 'db'. In GCP VPC firewall rules, source service accounts can be used to filter traffic based on the identity of the source VM, while target tags apply the rule to destination VMs that have the specified tag, enabling identity-based access control without relying on IP addresses.

FORCE_CACHE_ALL overrides origin Cache-Control headers and caches all responses. CACHE_ALL_STATIC attempts to cache static content but respects Cache-Control. USE_ORIGIN_HEADERS respects origin headers.

Route-based VPN uses routing (BGP or static routes) to determine which traffic goes through the tunnel, as opposed to policy-based which uses security policies.

Private Google Access for on-premises hosts requires firewall rules that allow traffic from on-premises to the restricted VIP IP range (199.36.153.4/30). This is necessary because on-premises hosts must be able to reach the restricted Google APIs VIP over the VPN or Interconnect, and firewall rules control which source IPs can access that VIP. Without these rules, traffic from on-premises would be blocked at the Google Cloud perimeter.

A Cloud VPN gateway is required because it acts as the Google Cloud-side endpoint for the VPN tunnel, handling the encryption and encapsulation of traffic. Without a VPN gateway, there is no secure tunnel termination point in GCP, making it impossible to establish the VPN connection.

Partner Interconnect is the most cost-effective option because it provides a dedicated, low-latency connection through a supported service provider that can extend connectivity from the colocation facility to a Google Cloud region. Unlike Dedicated Interconnect, it does not require physical cross-connects in a Google Cloud colocation facility, making it ideal when the on-premises site is not directly served by Google Cloud. It meets the real-time synchronization latency requirement by offering a reliable, high-bandwidth connection with SLA-backed uptime.

HA VPN supports dynamic peer IP addresses through its use of IKEv2 and route-based VPN tunnels. When the branch office has a dynamic public IP, HA VPN can establish tunnels using the peer's current IP address, which is discovered during IKE negotiation. Classic VPN (option A) requires a static peer IP, and option D requires two static peer IPs, making them unsuitable for a dynamic IP scenario.

HA VPN requires IKEv2 and dynamic routing (BGP). Classic VPN supports IKEv1 and static routing.

Cloud NAT with a static IP is the most cost-effective approach because it allows multiple VMs to share a single static IP address for outbound internet access, eliminating the need for individual external IPs. This reduces costs since external IP addresses incur charges, and Cloud NAT provides managed, scalable outbound connectivity without requiring a VPN or dedicated gateway.

Global external TCP Proxy Load Balancer provides a single anycast IP and handles TCP traffic without SSL offload (though it supports SSL offload optionally). It is the only global TCP load balancer that does not require SSL termination.

DNS peering allows you to set up cross-project DNS resolution by peering a private zone in one project to a VPC in another project.

Asymmetric routing in VPC peering often occurs when VPCs have overlapping CIDR ranges or when one VPC has a default route that points to another peering, causing the return traffic to take a different path that may be blocked by firewall rules or not have a route.

To target instances based on service account, use --target-service-accounts. To specify the source from internet, use --source-ranges with 0.0.0.0/0.

The requirement for high availability (redundancy) and bandwidth up to 10 Gbps is best met by Partner Interconnect with redundant connections. Partner Interconnect supports bandwidths from 50 Mbps to 10 Gbps and allows you to connect through a supported service provider, while redundant connections ensure failover and meet the high-availability requirement. Dedicated Interconnect offers up to 10 Gbps per circuit but requires two separate connections for high availability, not a single connection.

A common issue is that the subnet's custom routes are not exported. VPC peering allows exporting custom routes, but this must be explicitly enabled. If not, only system-generated routes (subnet routes) are exchanged.

VPC Flow Logs exported to BigQuery allow detailed analysis of traffic patterns, including source IP, destination, and bytes transferred, enabling cost attribution.

When the BGP session state is stuck in 'CONNECT', it indicates that the router is actively trying to initiate a TCP connection to the peer but is not receiving a response. For BGP to establish a TCP session (port 179), the on-premises router must have a valid IP route to the Cloud Router's BGP peer IP address. Without this route, TCP SYN packets are dropped, preventing the session from transitioning to 'ESTABLISHED'.

The Global External HTTPS Load Balancer provides a single anycast IP, SSL termination, and content-based routing via URL maps to backends like serverless NEGs pointing to Cloud Run.

Cloud Armor features include Security Policies (rule-based traffic filtering), WAF Rules (web vulnerability protection), and DDoS Protection (edge mitigation). Common confusions mix WAF with IP lists or rate limiting.

The default MTU for Google Cloud VMs is 1460 bytes to accommodate encapsulation overhead.

Cloud NAT requires a Cloud Router first. Then create NAT, assign IPs, and apply to subnets. Testing confirms internet access.

The instance needs outbound internet access via Cloud NAT, which requires a Cloud Router in the region.

Cloud CDN caches content at Google's edge caches based on the cache-control headers or default cache TTL. When the DNS record is updated to point to a new load balancer, the old load balancer's cached responses may still be served from edge caches until their cache TTL expires, even after the DNS TTL has expired. This is because Cloud CDN caches are independent of DNS resolution and are governed by HTTP caching rules.

Since the VPN tunnel is up and BGP sessions are established, the issue is not with the tunnel or BGP peering itself. Intermittent connectivity to a specific subnet (10.1.0.0/16) while other subnets remain reachable strongly indicates a route advertisement problem. The Cloud Router must be configured to advertise the correct subnet range to the on-premises router via BGP; if it is not, the on-premises router will lack a route for that subnet, causing intermittent or no connectivity.

DNS peering allows on-premises to query GCP private zones, and DNS forwarding (inbound) allows GCP to forward queries to on-premises DNS servers.

To meet a 99.99% SLA, the design must eliminate single points of failure at both the physical interconnect and the logical attachment level. Provisioning two Partner Interconnects from different providers or locations ensures physical diversity, while creating two VLAN attachments (each on a different Interconnect) provides logical redundancy, allowing traffic to fail over if one attachment or interconnect fails.

The on-premises router must have a route for the us-west1 subnets with the VPN tunnel as the next hop. Without this, the on-premises router will use its default route (typically the public internet) to reach us-west1, bypassing the VPN tunnel. The Cloud Router in us-east1 advertises the us-west1 subnets via BGP over the VPN tunnel, but the on-premises router must be explicitly configured to forward traffic for those subnets into the tunnel.

Failover routing policy allows specifying primary and secondary targets with health checks. Geolocation and weighted round robin do not provide failover behavior.

Cloud NAT with a static NAT IP address ensures that all outbound traffic from private instances uses a consistent, predictable source IP. This satisfies the external API's requirement for a static source IP without needing to assign public IPs directly to instances. Option C correctly configures Cloud NAT to use a static IP, which is the intended solution for this scenario.

Classic VPN supports static routing (policy-based or route-based) without BGP. Cloud VPN (HA VPN) and Partner Interconnect require BGP, and Dedicated Interconnect uses BGP for VLAN attachments.

VPC Service Controls allow you to define a service perimeter that restricts access to a Cloud SQL database (or other Google Cloud services) to requests originating from a specific VPC network. This is achieved by configuring an access level that references the VPC network, ensuring that only traffic from that VPC can reach the database, even if the database is exposed via private IP.

The most likely cause is asymmetric routing, where outbound traffic from GCP to on-premises takes one VPN tunnel while return traffic takes the other. Stateful firewalls track connection state based on the first packet seen; if return packets arrive via a different tunnel (and thus a different source IP or interface), the firewall does not recognize them as part of an existing session and drops them. This is a classic symptom of asymmetric routing with multiple BGP sessions over separate tunnels.

Traffic Director uses the mTLS mode in the Envoy configuration. The correct way is to set the tls_mode to STRICT in the TrafficDirector's mesh configuration.

VPC Flow Logs capture metadata about network traffic flowing to and from VPC instances, including latency-related metrics such as packet loss and retransmissions. By analyzing these logs, you can identify if high latency is caused by dropped packets or congestion on the Partner Interconnect link. This makes VPC Flow Logs a direct diagnostic tool for latency issues from within Google Cloud.

Network Connectivity Center (NCC) is the correct choice because it provides a hub-and-spoke topology that connects multiple VPCs across projects and regions to a central hub VPC for centralized inspection, without requiring complex mesh peering. NCC uses a software-defined networking (SDN) controller to manage inter-VPC connectivity and routing, enabling traffic to flow through the hub VPC for inspection appliances like firewalls or IDS/IPS.

A Global VPC (default VPC mode) allows subnets in multiple regions to communicate using private IPs natively, without any additional VPN or peering configuration. This is because a Global VPC spans all regions, and instances within the same VPC can reach each other via internal IPs using Google's global network, providing low-latency communication.

Cloud Router uses BGP to dynamically exchange routes between a VPC network and an on-premises network over a VPN tunnel or Dedicated Interconnect. In this configuration, the purpose is to advertise the VPC's IP range (the custom or auto-mode subnet CIDR) to the on-premises router, enabling on-premises hosts to route traffic back to the VPC. This is achieved by configuring the Cloud Router with a BGP session and setting the advertised route for the VPC's IP range.

Traffic splitting in Traffic Director is configured via routing rules (TrafficDirectorRoute) and backend services (or weighted backends).

Cloud Router uses custom route advertisements, and if the on-premises subnet 10.0.0.0/8 overlaps with the VPC's auto-allocated IP range (e.g., the default or custom subnet ranges within the VPC), Google Cloud will not install or will drop traffic for that route due to a conflict. Overlapping routes cause the VPC to prefer its own local routes, resulting in dropped traffic to the on-premises subnet.

For a single VLAN attachment using Dedicated Interconnect with active/active BGP, only one Cloud Router interface is required. The Cloud Router interface represents the VLAN attachment itself, and BGP sessions are configured as sub-interfaces under that single interface. Active/active BGP does not require multiple interfaces; it uses two BGP sessions (one for each router in the pair) but both sessions share the same VLAN attachment and Cloud Router interface.

Traffic Director supports mTLS through the Mesh TLS configuration, which enforces TLS mutual authentication between sidecars.

To avoid routing conflicts, each VPC and the on-premises network should use unique, non-overlapping RFC 1918 CIDR blocks. Overlap would cause routing issues and potential traffic blackholing.

Using Cloud Router with BGP allows the VPC to dynamically learn specific routes from the on-premises network via the VPN tunnels. The default route (0.0.0.0/0) remains pointing to the internet gateway, so only traffic destined for the learned on-premises prefixes is sent through the VPN, while all other traffic uses the internet. This provides precise control without overriding the default route.

A single VPC network is global and can contain subnets in any region. By placing subnets in each required region within the same VPC, instances can communicate using internal IP addresses (RFC 1918) without any additional connectivity services. This is the simplest and most scalable approach because VPCs inherently provide global routing between subnets.

Each NIC in a multi-NIC VM is assigned to a different subnet. By default, the VM only sends traffic out of the NIC that matches the destination subnet's route. To route traffic through a specific NIC, custom routes with next hop set to the VM's IP on that NIC are required.

To fail over traffic, the engineer can use as-path prepending on the active connection to make it less preferred, or adjust MED, or use local preference on the on-premises side. The question implies a GCP-side action: using as-path prepending via Cloud Router BGP configuration.

An HA VPN gateway has two interfaces, each with its own external IP. For each interface, you create a VPN tunnel and attach it to a Cloud Router with a BGP session. The tunnel and BGP session are paired for each interface.

VPC Network Peering allows direct connectivity between two VPCs using internal IPs, with no transitive routing. It is a simple, decentralized option for connecting two VPCs.

Cloud NAT by default uses dynamic port allocation and releases ports after a timeout. With static NAT IP, if port exhaustion occurs or if the connection idle timeout is too low, connections may drop.

To load-balance and provide failover, you need equal-cost multi-path (ECMP) routing. Cloud Router supports ECMP only when the routes have the same MED and AS_PATH length. Setting both on-premises routers to advertise with the same attributes allows ECMP.

VPC peering relies on private IP routing between the two VPCs. If the IP address ranges overlap, the VPC route tables cannot distinguish which VPC a packet belongs to, causing routing conflicts and preventing the peering connection from being established. Google Cloud requires that the VPCs have non-overlapping subnet CIDR blocks for successful peering.

Network Connectivity Center hub-and-spoke and a VPN appliance in a shared VPC can provide transitive routing. VPC peering is non-transitive and would require full mesh.

HA VPN requires two VPN gateways (each with one external IP), two tunnels per gateway (total four tunnels), and BGP sessions on each tunnel for dynamic routing.

VPC quotas are documented in the Quotas page under VPC Network, showing limits per VPC such as firewall rules, routes, etc.

The most likely cause is that the user's source IP is being translated by a NAT or proxy before reaching the load balancer. Cloud Armor evaluates the source IP as seen by the load balancer, which may differ from the original client IP if traffic passes through an intermediate device. The logs confirm the source IP matches the allowed range, but if the request arrives via a proxy, the actual source IP in the packet could be the proxy's IP, not the user's, causing the deny rule to match.

Cloud Armor security policies evaluate rules in priority order, with lower numbers having higher priority. The deny rule at priority 1000 matches the source IP range 10.0.0.0/8, which includes the user's IP 10.0.1.1, and is evaluated before the allow rule at priority 2000. Since the deny rule is matched first, the request is blocked, preventing access to the HTTPS load balancer.

Inbound DNS server policy allows on-premises to forward queries to Cloud DNS. Outbound DNS server policy allows GCP to forward queries to on-premises DNS.

An auto mode subnet automatically creates subnets in each region and assigns IP address ranges from a predefined pool that can expand as you add more VM instances. This allows the subnet to grow without manual intervention, making it ideal for startups that need dynamic scaling.

Cloud CDN uses Google's globally distributed edge caches to serve content from locations closer to users, reducing round-trip time and latency. For users in Europe, cached static or dynamic content is delivered from a nearby edge PoP, bypassing the need to fetch from the origin server in a potentially distant region.

ECMP is achieved by having multiple BGP paths with equal MED and AS path length. The Cloud Router automatically load balances if routes have equal metrics.

Hierarchical firewall policies can be applied at the organization, folder, or project level and apply to all VPCs in the resource hierarchy. VPC-level firewall rules are per VPC and require duplication.

VPC Service Controls allows you to define a service perimeter that includes a Cloud Storage bucket, and within that perimeter you can restrict access to only trusted VPC networks. This prevents data exfiltration by ensuring that only resources within the specified VPC networks can access the bucket, blocking any access from outside the perimeter, including the public internet or other networks.