Google Professional Cloud Network Engineer (PCNE) — Questions 376–450

To create subnets, a user needs the Compute Network Admin role on the host project. To use subnets, a user needs the Compute Network User role on the host project or specific subnets.

Firewall rules in Google Cloud are applied at the network level, not the instance level. To allow inbound SSH traffic from VPC-A to instances in VPC-B, the firewall rule must be created in VPC-B (the destination network) with the source range set to 10.0.0.0/16. Creating the rule in VPC-A would only affect traffic destined for instances in VPC-A, not VPC-B.

Cloud Armor evaluates rules in order of priority (lowest number = highest priority). The rule with priority 200 matches the request (User-Agent 'GoodBot' and path '/admin') and explicitly allows it. Once a matching allow rule is found, evaluation stops, and the request is allowed, overriding any lower-priority rules.

Cloud CDN caches content at edge locations closer to users, reducing egress costs by serving cached responses from the edge. For users in Europe, if the origin is in the US, Cloud CDN will serve from European caches after the first request, minimizing cross-region egress.

The 'Connection refused' error on the on-premises router indicates that the Cloud Router is actively rejecting the TCP connection attempt for the BGP session. This typically occurs when the Cloud Router does not have a BGP peer configured with the on-premises router's IP address, or the peer is in an 'inactive' state. Since the Cloud VPN tunnel itself can be established (option A is not necessarily true), the most likely cause is that the Cloud Router is not configured to accept BGP connections from this specific on-premises peer.

Secondary IP ranges on a subnet can be designated for GKE pods and services. These ranges are separate from the primary subnet range.

The Cloud NAT configuration only includes subnet-a, so subnet-b is not NATed.

Network Connectivity Center (NCC) is the correct choice because it provides a centralized hub-and-spoke topology for connecting multiple on-premises sites (via VPN, Interconnect, or third-party SD-WAN appliances) and multiple GCP VPCs. It manages routing and policy distribution across spokes, eliminating the need for individual peering or complex route tables, and supports both intra- and cross-region connectivity.

Cloud NAT is a regional resource that applies to all instances within a given region. The exhibit shows subnet-a is in a different region than us-central1, so the NAT gateway cannot route traffic from instances in that subnet. Even though the instance is in us-central1, the subnet's region mismatch means the NAT configuration does not apply, leaving the instance without internet access.

In GKE, pods are assigned IP addresses from the secondary pod range, and services (of type ClusterIP) are assigned IPs from the secondary service range. For on-premises resources to allow traffic from pods via a VPN, the firewall must see the pod IPs (not node IPs), so the secondary pod range must be configured on the VPC subnet. The secondary service range is also required for service discovery and proper routing, but the source IP seen by on-premises will be the pod IP from the secondary pod range.

The BGP session is 'ESTABLISHED', confirming that the TCP connection and BGP peering are working correctly. However, the on-premises router is not receiving any VPC subnet routes because the Cloud Router's 'Advertised IP ranges' list is empty, meaning it is not advertising any routes to the peer. This is a common misconfiguration where the Cloud Router is configured to use custom route advertisements but the list of prefixes to advertise is left blank.

Cloud CDN must be enabled on the backend service of the HTTP(S) load balancer, and the frontend must use HTTP or HTTPS because Cloud CDN only supports HTTP(S) protocols. This is the minimal configuration; no changes to the backend bucket or instance group are required beyond ensuring the backend service is correctly associated with the load balancer.

GKE clusters can specify secondary IP ranges for pods and services during creation. To avoid conflicts, the engineer must explicitly define these ranges using the --cluster-secondary-range-name and --service-secondary-range-name flags.

Correct matches: Egress charges for outbound data; Ingress is free; Cloud Interconnect charges by bandwidth; VPN charges hourly plus egress. Common confusions include swapping egress/ingress definitions and confusing Interconnect with VPN.

Using unique RFC 1918 IP address ranges for each VPC prevents overlapping IP spaces, which is critical when connecting multiple VPCs and on-premises networks via Cloud VPN. Overlapping ranges would cause routing conflicts and make it impossible for Cloud Router and BGP to establish proper path selection, leading to dropped or misrouted traffic.

The error indicates a mismatch between the authentication methods configured on both ends, such as pre-shared key vs certificate, or different authentication types.

Cloud Armor security policies can be attached to HTTP(S) load balancers. They support geo-based access control (allow/deny by country) using preconfigured or custom rules.

Private Google Access allows Compute Engine instances without external IP addresses to reach Google APIs and services, including Cloud Storage, through the VPC network's default route to the internet gateway, but only to Google's published IP ranges. This is the correct solution because it provides the required access without exposing the instances to the general internet.

A single Dedicated Interconnect connection can support multiple VLAN attachments (each with a unique VLAN ID) to connect multiple VPCs in different regions to the same on-premises data center. This minimizes cost by using one physical connection and reduces complexity by avoiding separate interconnects or VPNs for each VPC.

Serverless NEG for Cloud Run requires that the Cloud Run service is publicly accessible or that the ingress is set to allow all traffic. Additionally, the load balancer's health checks must pass. A common cause is that the Cloud Run service has ingress restricted to internal traffic only.

The error message 'BGP_OPEN_MSG_ERROR: unsupported capability' indicates that during the BGP OPEN message exchange, the on-premises router advertised a BGP capability (such as 4-byte ASN support or IPv6 unicast address family) that the Cloud Router does not support. This causes the Cloud Router to reject the OPEN message and reset the session. Option D correctly identifies this mismatch in negotiated capabilities.

Shared VPC allows granting IAM roles on individual subnets. The Compute Network User role (roles/compute.networkUser) allows a principal to use a subnet to create resources, without giving them broader network management permissions.

The Performance Dashboard measures packet loss and latency between regions. Packet loss without latency increase often indicates transient congestion or minor issues that cause drops but not queuing delay. It is normal to see some loss; the dashboard shows real measurements.

By default, VPC peering is non-transitive, so VPC-A cannot reach on-premises through VPC-B. To enable this, VPC-B must export custom routes to VPC-A, and the on-premises network's routes must be learned via BGP on Cloud Router in VPC-B.

VPC Service Controls use a perimeter to restrict access to managed services like BigQuery. Adding the project containing the service account to the perimeter allows that service account to access the protected BigQuery datasets, as the perimeter explicitly includes the project as an allowed member.

Cloud DNS response policies (RPZ) allow you to override DNS responses for domains within a VPC. You can create a response policy with rules that modify DNS responses for specified domains.

Hierarchical firewall policies provide centralized management, inherit down the resource hierarchy, and can apply at the organization level. They support both allow and deny rules, and can be used to enforce baseline security.

B is correct because the BGP session state IDLE indicates that BGP is not configured or enabled on the Cloud Router. Even though the IPsec tunnels are UP, no BGP routes can be exchanged if the BGP process itself is not running. In Google Cloud, you must explicitly enable BGP on the Cloud Router for each VPN tunnel; otherwise, the BGP session cannot transition from IDLE to any other state.

Private Service Connect requires a service producer to create a service attachment (which uses a load balancer as the backend), and consumers to create Private Service Connect endpoints. The producer must also enable Private Service Connect on the subnet where the load balancer resides.

The External HTTP(S) Load Balancer is a global load balancer that can distribute traffic to backends in multiple regions using anycast IP addresses and Google's global network. It supports cross-regional backend services, making it suitable for global applications.

B is correct because MACsec (IEEE 802.1AE) provides encryption at Layer 2, which is required for Cloud Interconnect to secure traffic between on-premise and GCP. Unlike VPN solutions, MACsec allows the customer to manage encryption keys on-premise and rotate them every 30 days, meeting strict compliance requirements. Cloud Interconnect with MACsec ensures low-latency, high-bandwidth connectivity while keeping key management under the customer's control.

Cloud Router requires a router first, then a tunnel, followed by BGP configuration. Custom advertisements and verification complete the setup.

Creating two VPN tunnels with Cloud Router using BGP and the same ASN on both on-prem routers enables dynamic routing and automatic failover. Cloud Router establishes BGP sessions with each on-prem router, and when both tunnels advertise the same routes with the same ASN, Cloud Router can detect a BGP session failure and automatically route traffic through the remaining healthy tunnel. This setup ensures seamless failover without manual intervention.

BigQuery is the best choice for querying large volumes of VPC Flow Logs with SQL, enabling cost-effective analysis of top talkers. Stackdriver (Cloud Monitoring) is for metrics, not log analysis; Cloud Storage is for archival; Pub/Sub for streaming.

Hierarchical firewall policies can be applied at the organization level and are inherited by all folders and projects, ensuring consistent rules across the entire hierarchy.

DNS peering allows you to resolve DNS queries across different GCP projects, even if they are not in the same organization, by establishing a peering relationship between two VPC networks. This enables the private zone (corp.example.com) in one project to be queried from instances in another project without exposing the zone to the internet or requiring shared VPC.

Checking Cloud VPN gateway logs for IKE errors helps identify authentication or configuration mismatch. Verifying that the on-premises firewall allows UDP 500 and 4500 for IPsec is necessary because many failures are due to firewall blocking.

Pre-shared keys (PSKs) are a valid and commonly used authentication method for IPsec VPN tunnels in Google Cloud. They provide a simple, symmetric key-based mechanism to authenticate the VPN peers without requiring a PKI infrastructure, making them a best practice for straightforward deployments.

VPC peering does not enforce symmetric routing by default. If both networks have subnet CIDRs that overlap, or if one network has a route that sends traffic to the other via a different next hop (e.g., VPN or NAT), asymmetric routing can occur. The most common cause is when both VPCs have a default route pointing to different next hops (e.g., one to the internet, one to a VPN), causing different paths.

Split-horizon DNS is achieved by having a public zone for external resolution and a private zone for internal resolution within the same domain.

Deploying two Cloud VPN gateways in different regions with separate Cloud Routers ensures true regional redundancy. If one gateway or its tunnel fails, BGP sessions on the other gateway remain active, and Google Cloud's network can immediately route traffic via the surviving path. This architecture meets the sub-second failover requirement by avoiding a single point of failure at the gateway level and leveraging BGP's fast convergence.

Cloud VPN with dynamic routing (BGP) allows you to control path selection by advertising custom routes with different metrics (MED values) for the primary and backup paths. When the primary path is available, the lower metric route is preferred; if the BGP session fails, the route is withdrawn and traffic automatically fails over to the backup path with a higher metric. This meets the requirement for active/passive failover without manual intervention.

Placing both Compute Engine instances in the same VPC and using internal IP addresses ensures traffic stays within Google's private network backbone, bypassing any external gateways or internet hops. This configuration leverages Google's internal routing with sub-millisecond latency between zones in the same region, as traffic is forwarded at the hypervisor level without encapsulation or additional network hops.

VPC Network Peering allows you to export custom routes (including static and dynamically learned routes) to a peered VPC by enabling the 'Export custom routes' option on the peering connection. Option B is correct because peering is non-transitive: traffic cannot flow through an intermediate VPC to reach a third VPC; each peering connection is direct and isolated. Options C, D, and E are incorrect: global routing mode is a VPC-level setting, not a peering property; peering is never transitive by default; and peered VPCs must have non-overlapping IP ranges to avoid conflicts.

By default, the first interface attached (nic0) is the primary interface and used for default routes and internal DNS.

A single Dedicated Interconnect circuit can have multiple VLAN attachments (up to 8 for 10 Gbps, up to 64 for 100 Gbps). You simply create another VLAN attachment on the same interconnect, using a different VLAN ID and a different Cloud Router if desired.

VPC Network Peering does not support transitive routing by default. To enable spoke-to-spoke communication through the hub, you must configure a managed VPN (Cloud VPN) between the hub and each spoke with dynamic routing (BGP). This creates a routed overlay that allows the hub to forward traffic between spokes, effectively achieving transitive routing.

Cloud NAT uses a source IP address (either a static IP you assign or an ephemeral IP from the NAT gateway's IP range) when translating outbound traffic from private VMs. If the external service's firewall only allows traffic from specific IP addresses, and the Cloud NAT gateway is using a static IP that is not on that allowlist, the affected VMs' traffic will be blocked. Other VMs might reach the service if they use a different NAT gateway or if the service's firewall permits their translated IP.

A Shared VPC (XPN) allows an organization to connect resources from multiple service projects to a common host project's VPC network, enabling isolated projects to communicate with shared services while centralizing network administration. This minimizes administrative overhead because network policies, firewall rules, and routing are managed in one place, and service projects do not need to manage their own VPC infrastructure.

Separating each application tier into its own subnet allows you to apply VPC firewall rules to control ingress and egress traffic between tiers based on source and destination CIDR ranges or service accounts. This follows the principle of least privilege, ensuring that only necessary traffic (e.g., web-to-app on TCP port 8080, app-to-database on TCP port 3306) is permitted, while all other traffic is denied by default.

AS path prepending is done on the on-premises router by adding the on-premises AS number multiple times in the BGP updates sent to Google Cloud. Google Cloud Router will then prefer the path with the shorter AS path length (fewer prepends). To make one connection less preferred, the on-premises router should prepend AS numbers on the BGP updates sent over that connection.

Cloud CDN cache modes: CACHE_ALL_STATIC caches static content based on cache directives, USE_ORIGIN_HEADERS respects origin headers, FORCE_CACHE_ALL forces caching for all responses regardless of headers. FORCE_CACHE_ALL is used to override origin headers and cache everything.

NIC0 is the primary interface; default routes and instance metadata are tied to it. Adding extra interfaces (NIC1, NIC2, etc.) is for specific networking scenarios like network appliances.

Cloud CDN supports signed URLs and signed cookies to restrict access to content. Signed URLs are used for individual files, while signed cookies work for multiple files. IAP is for access control at the load balancer level but not specifically for CDN content.

A VLAN attachment (option B) is required because it defines the connection between your VPC and the partner's network over a Partner Interconnect, specifying the VLAN ID and IP addressing for the BGP session. Without a VLAN attachment, the Layer 2 and Layer 3 parameters for the interconnect cannot be established.

Private Google Access enables Compute Engine instances that have only internal IP addresses (no external IPs) to reach Google APIs and services such as Cloud Storage and BigQuery. It works by routing traffic destined for Google API IP ranges through the default internet gateway, using the VPC's internal DNS resolution to map the API hostnames to Google's internal IP addresses, without requiring a public IP on the instance.

The default sampling rate for VPC Flow Logs is 50%. This can be adjusted to reduce costs but may miss some flows.

Failover routing policy allows you to set primary and secondary targets; DNS automatically responds with the secondary if the primary is unhealthy.

When a Cloud Router is configured in custom advertise mode, it only advertises the routes explicitly specified in the custom advertisement list. If the VPC subnets are not included in that list, the on-premises network will not receive any routes from Google Cloud, even if the BGP session is established. This is the most likely cause because the question states the on-premises network is not receiving any routes, which aligns with a missing custom advertisement rather than a session or timer issue.

Cloud NAT logging captures connection and allocation failures, which helps troubleshoot NAT resource exhaustion and other issues.

Deploying two Cloud VPN tunnels from two Cloud Routers with BGP sessions provides high availability and automatic failover. The two Cloud Routers in different zones ensure redundancy, and BGP (Border Gateway Protocol) dynamically advertises routes and detects tunnel failures, allowing traffic to automatically switch to the healthy tunnel without manual intervention. This meets the requirement for an IPsec VPN connection to a third-party SaaS provider that only supports IPsec VPN.

In active-active mode, both circuits are used simultaneously. When one fails, traffic is re-routed to the remaining one. If there is insufficient bandwidth on the remaining circuit, packet loss may occur due to congestion.

Traffic Director supports traffic splitting via the service routing API (TrafficDirectorService). You can define weighted destinations in the routing rule to split traffic between versions.

Cloud CDN with an external origin requires the origin to return explicit cache headers (Cache-Control or Expires) to enable caching. If the origin does not return caching headers, Cloud CDN will not cache the content. Force cache all mode can override this, but if not set, caching may not occur.

To enable CDN for a specific path, you must create a backend bucket (or backend service with CDN enabled) and configure a URL map rule that routes the path /images/* to that backend. Enabling CDN on the backend service itself will apply to all paths served by that backend.