PCNE Practice Test 36 — 15 Questions

Question 1

A company is migrating its on-premises data center to Google Cloud. They currently have a Cloud VPN tunnel with dynamic routing (BGP) connecting their on-premises router (ASN 65001) to a Cloud Router in us-central1 (ASN 64512). The on-premises network uses IP range 10.0.0.0/8, and the Google Cloud VPC uses 172.16.0.0/12. After migration, they notice intermittent connectivity issues: traffic from on-premises to a new VM (172.16.1.2) is sometimes dropped, while other VMs in the same subnet work fine. The VM 172.16.1.2 is fine when accessed from other Google Cloud VMs. The team suspects asymmetric routing. Investigation shows that the on-premises router receives two routes for 172.16.1.2/32: one with next-hop as the Cloud VPN tunnel and another with next-hop as the internet (default route). No custom route advertisements are configured on the Cloud Router. The VPC has a default route (0.0.0.0/0) pointing to the internet gateway. What should the network engineer do to resolve the issue without breaking other connectivity?

Accepted Answer

Configure an inbound route filter on the Cloud Router to reject the BGP route 0.0.0.0/0 from the on-premises router.. The intermittent connectivity to 172.16.1.2 is caused by asymmetric routing: on-premises traffic uses the BGP-learned /32 route (via VPN) to reach the VM, but return traffic from the VM follows the VPC's default route (0.0.0.0/0) to the internet gateway, which drops the packet because the source IP is from the on-premises range. By configuring an inbound route filter on the Cloud Router to reject the BGP route 0.0.0.0/0 from the on-premises router, the on-premises router will no longer have a default route pointing to the VPN tunnel, forcing it to use the more specific /32 route for 172.16.1.2 and eliminating the asymmetric path.

Answer

Enable global routing on the VPC and create a more specific static route for 172.16.1.2/32 with next-hop as the VPN tunnel.

Answer

Create a second Cloud VPN tunnel from a different region and establish a new BGP session to load balance traffic.

Answer

Change the Cloud Router's BGP advertise-mode to 'custom' and advertise only the subnets that contain migrated VMs.

Question 2

A large enterprise has multiple on-premises data centers connected to Google Cloud via a combination of Dedicated Interconnect and Cloud VPN. They have a VPC with subnets in us-east1 and us-west1. The on-premises network advertises a prefix 10.0.0.0/8 to both Cloud Routers (each in different regions) via BGP. The Cloud Routers are configured with 'global' dynamic routing mode. The network team notices that traffic from Google Cloud instances in us-west1 to on-premises destinations in 10.0.0.0/8 is always taking the path to the closest on-premises data center (west coast) even though the west coast data center is currently under high load, causing performance degradation. The east coast data center is underutilized. They want to influence the path selection so that the west coast instances prefer the east coast data center during peak times. They are using BGP. What is the most effective method to achieve this?

Accepted Answer

Use BGP communities to tag routes from the west coast data center under load, and configure Cloud Router to match these communities and adjust the route priority (MED) accordingly.. Option D is correct because BGP communities allow the west coast data center to tag its routes with a community value indicating high load. The Cloud Router can then be configured to match this community and adjust the route priority by lowering the MED (or local preference) for those routes, making the east coast data center's routes more preferred. This dynamic, policy-based approach directly addresses the need to shift traffic away from the overloaded west coast data center without manual reconfiguration.

Answer

Set a higher local preference on the west coast Cloud Router for routes received from the east coast data center.

Answer

Set a higher MED on the west coast data center's BGP advertisements to increase its desirability.

Answer

Configure the east coast data center to prepend one additional AS path hop to its advertised routes.

Question 3

A service provider uses a Shared VPC with multiple service projects. The host project has a Cloud NAT configured for subnet 10.1.0.0/24 to provide outbound internet access to all service projects using that subnet. A new service project needs to use its own Cloud NAT for its VM instances in subnet 10.1.0.0/24 to meet compliance requirements. The network engineer attempts to create a Cloud NAT in the service project for that subnet but receives an error that the subnet already has a NAT gateway. What action should the engineer take to meet the compliance requirement?

Accepted Answer

Remove the host project's NAT from the subnet and create a Cloud NAT in the service project for that subnet.. Option B is correct because a subnet can have only one NAT gateway associated. To use a different NAT for the service project, the host project's NAT must be removed from that subnet first, then the service project's NAT can be created. Option A is impossible due to the conflict. Option C (VPC peering) would not allow the service project to have its own NAT on the same subnet. Option D (proxy instance) is not a native solution and introduces management overhead.

Answer

Create a new Cloud NAT in the service project for the same subnet, overwriting the existing one.

Answer

Use VPC peering to connect the service project to a different network that has a Cloud NAT.

Answer

Implement a proxy instance with an external IP in the service project.

Question 4

A company has two VPC networks (VPC-A and VPC-B) in the same project. They are connected via VPC peering. VPC-A contains an internal TCP load balancer with IP 10.1.2.3 serving on port 80. VPC-B needs to access this load balancer. The network engineer has verified that the firewall rules allow traffic from VPC-B to the load balancer's IP and port. However, instances in VPC-B cannot connect to 10.1.2.3:80. What is the most likely reason for this failure?

Accepted Answer

Internal load balancers are regional; clients must be in the same region as the load balancer when using VPC peering.. Option C is correct: Internal TCP/UDP load balancers are regional and only accept traffic from clients in the same region when using VPC peering. The load balancer is in a specific region (e.g., us-central1), but if VPC-B's instances are in a different region (e.g., us-west1), they will not be able to reach the internal LB via peering unless the LB has global access enabled (which is only available for external LBs). Option A is incorrect because firewall rules are already verified. Option B is irrelevant; VPC peering does not insert a default route for load balancer IPs. Option D is incorrect because health checks are for the load balancer to backends, not client connectivity.

Answer

The VPC peering connection does not propagate routes for the load balancer IP.

Answer

The backend instances are unhealthy and the load balancer is not serving traffic.

Answer

Firewall rules in VPC-B are not allowing egress to the load balancer IP.

Question 5

A large enterprise has a Google Cloud environment with multiple projects under an organization. They have a Shared VPC host project with a VPC named 'shared-vpc' that has subnets in us-central1 and europe-west1. Several service projects are attached to this host project. One service project, 'proj-analytics', has a Compute Engine instance 'vm-analytics' in us-central1 that needs to connect to a Cloud SQL PostgreSQL instance (private IP) also in us-central1, but within a different service project 'proj-db'. The Cloud SQL instance is configured with a private IP address 10.0.1.5 from a subnet in 'shared-vpc' (the same VPC). The vm-analytics instance has an internal IP 10.0.0.5 from a different subnet in 'shared-vpc'. The two subnets are in the same region, and there is a firewall rule allowing all traffic from 10.0.0.0/16 (the entire VPC range) to the Cloud SQL subnet. However, vm-analytics cannot connect to the Cloud SQL instance. The error on vm-analytics is 'Connection timed out'. There are no firewall rules blocking egress from vm-analytics. What is the most likely cause and solution?

Accepted Answer

Grant the service project's compute engine default service account the Compute Network User role on the host project.. Cloud SQL with private IP uses Private Service Access, which requires a VPC peering connection between the VPC and the service producer VPC (Google's). The Cloud SQL instance's private IP is accessible only from the VPC network where the peering is established. However, the issue often arises because the service project does not have the necessary IAM permissions or the VPC peering is set up in the host project but not propagated to service projects. In this case, vm-analytics is in a service project attached to the Shared VPC, so it should have connectivity to the Cloud SQL private IP because it's in the same VPC. But the timeout suggests no route. One common cause is that the Private Service Access connection (VPC peering) is only set up in the host project's VPC, but the service project's VPC (which is actually the same VPC via Shared VPC) may not have routes to the peered network. Actually, when using Shared VPC, the service projects use the host project's VPC, so routes from VPC peering are automatically propagated. However, there is a known issue: if the Cloud SQL instance is created in a service project that is attached to the same Shared VPC, the private service access must be configured in the host project. Also, the service project's service accounts may need the compute.networkUser role on the host project's VPC. The most likely cause is that the VPC peering is set up but the service project's project does not have the necessary IAM role to use the peering. Option C is correct: Grant the service project's compute service account the Compute Network User role on the host project.

Answer

Enable Private Google Access on the vm-analytics subnet.

Answer

Create a firewall rule in the host project allowing ingress from the service project's subnets to the Cloud SQL subnet.

Answer

Configure a Cloud Router in the service project to advertise routes to the Cloud SQL subnet.

Question 6

A company is migrating from an on-premises data center to Google Cloud. They have set up a High-Availability VPN (with two tunnels) between their on-premises router and a Cloud VPN gateway in a VPC. They use static routing. The on-premises network uses RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and the VPC uses 10.1.0.0/16. They have configured static routes in the VPC for the on-premises ranges pointing to the VPN gateway. However, they notice that traffic from on-premises to the VPC is intermittent: sometimes packets go through tunnel 1, sometimes through tunnel 2, and sometimes they drop. The on-premises router is configured to use both tunnels in an active-active mode with equal-cost multipath (ECMP). What is the most likely cause of the intermittent drops?

Accepted Answer

Change from static routing to dynamic routing (BGP) to allow the Cloud VPN gateway to advertise routes and avoid ECMP issues.. Cloud VPN with static routing does not support ECMP for traffic going from the VPC to on-premises, but from on-premises to VPC, ECMP is possible if the on-premises router distributes traffic across multiple tunnels. However, Cloud VPN gateways have a known limitation: when using static routing, the Cloud VPN gateway treats each tunnel as a separate next-hop, and the VPC routes point to the gateway, not individual tunnels. Actually, for incoming traffic from on-premises, the Cloud VPN gateway receives the packets on either tunnel and forwards them to the VPC. The issue is that the on-premises router may be sending packets out of order due to ECMP, and the Cloud VPN gateway may not reassemble them correctly, causing drops. But more commonly, if the on-premises router uses ECMP across tunnels that terminate on the same Cloud VPN gateway, the gateway may see packets from different flows on different tunnels, but the gateway will forward them correctly. A more likely cause is that the VPN tunnels do not have matching encryption domains or the on-premises router's ECMP algorithm is not consistent. The correct action is to use BGP dynamic routing to avoid ECMP issues, or to use active-passive mode. Option A is correct: Switch to BGP routing, which allows better path selection and route advertisement.

Answer

Increase the number of tunnels to four to distribute traffic better.

Answer

Set the on-premises router to active-passive mode using only one tunnel at a time.

Answer

Configure traffic selector policies on the VPN tunnels to ensure each tunnel only handles specific subnets.

Question 7

A small company has a single VPC with one subnet in us-central1 (10.0.1.0/24). They have a Compute Engine instance that needs to be reachable from the internet via HTTP (port 80) and HTTPS (port 443). The instance has an external IP address (ephemeral). They have created firewall rules allowing ingress on TCP 80 and 443 from 0.0.0.0/0, with target tags 'web-server'. The instance has been assigned the tag 'web-server'. However, external users report that they cannot access the instance's public IP on either port. The instance's OS firewall (iptables) is default allow. What is the most likely cause?

Accepted Answer

The instance's external IP is ephemeral and may have changed, so users should use the new IP or reserve a static IP.. The instance likely has an ephemeral external IP that may have changed after a stop/start, or the firewall rules are not properly applied. Since they have a tag, the rule should work. But a common mistake is not having a default route (0.0.0.0/0) in the VPC to allow internet traffic to reach the instance. Actually, the VPC automatically has a default route that sends traffic to the internet gateway, so that should be fine. Another possibility is that the instance's firewall (iptables) is blocking. But the most likely cause is that the external IP is ephemeral and may have changed, and users are using the old IP. Option B is correct: The external IP might have changed after a restart.

Answer

The instance's OS firewall is blocking the traffic; check iptables.

Answer

The VPC needs a custom route for the internet gateway.

Answer

The firewall rules must be applied to the subnet, not the instance tag.

Question 8

A company has a VPC with a single subnet in us-central1 (10.0.0.0/24). They have a Compute Engine instance running a database that uses an internal IP address 10.0.0.10. They need to ensure that this database instance can be accessed by a legacy on-premises application via a Cloud VPN tunnel. The on-premises network uses 192.168.0.0/16. They have set up a HA VPN gateway with two tunnels and BGP routing. The Cloud Router is configured to advertise the subnet 10.0.0.0/24. On the on-premises side, the router receives the route for 10.0.0.0/24 and has a static route for 10.0.0.0/24 pointing to the VPN tunnel. However, the on-premises application cannot reach the database. The application's server can ping the on-premises gateway, but not the database IP. The database instance's OS firewall allows all traffic from 0.0.0.0/0. What is the most likely cause?

Accepted Answer

The VPC firewall rules are blocking ingress from on-premises; add a rule allowing traffic from 192.168.0.0/16 to the database IP.. The issue is likely that the VPC firewall rules are blocking ingress traffic from the on-premises network. Even though the database OS firewall is permissive, the VPC firewall must allow ingress from the on-premises IP range (192.168.0.0/16) to the database's IP. Option B is correct: Create a firewall rule allowing ingress from 192.168.0.0/16 to 10.0.0.10 on the required port.

Answer

The database instance's OS firewall is blocking the traffic despite the setting.

Answer

The Cloud Router is not advertising the specific database IP 10.0.0.10, only the subnet 10.0.0.0/24.

Answer

The BGP session is not establishing properly; check the shared secret and IP addresses.

Question 9

A large organization uses Shared VPC with hundreds of projects. They want to implement fine-grained access control for SSH access to Compute Engine instances using IAP TCP forwarding. They have created a custom IAM role with the necessary permissions (iap.tunnel.dest, iap.tunnel.getIamPolicy, compute.instances.use) and granted it to a group of developers. The developers have also been granted the iap.tunnelUser role on the project. However, when they try to use `gcloud compute ssh --tunnel-through-iap instance-name`, they get a permission error: "Permission 'iap.tunnel.dest' denied on resource 'projects/project/zones/zone/instances/instance'". The network admin has verified that the custom role includes the required permissions and that the developers are members of the group with the role. What is the most likely missing configuration?

Accepted Answer

IAP TCP forwarding is not enabled for the project or VPC.. IAP TCP forwarding requires the IAP API to be enabled on the project and the service to be activated for the VPC. Without this, the IAP proxy cannot intercept and forward TCP traffic to the instance, even if the IAM permissions are correctly assigned. The error 'Permission 'iap.tunnel.dest' denied' typically occurs when the IAP TCP forwarding service itself is not enabled, as the permission check fails at the service level before evaluating the IAM role.

Answer

The developers need the `iap.tunnel` resource-level permission on the IAP TCP forwarding resource.

Answer

The instances do not have the required network tags for IAP.

Answer

The developers need the `compute.instances.osLogin` permission.

Question 10

Your company has two on-premises data centers, DC1 and DC2, each connected to a separate Google Cloud VPC via Dedicated Interconnect. Both VPCs are connected via VPC Network Peering. A new application deployed in VPC1 needs to communicate with a database in DC2. The database IP range is 10.0.0.0/16. You have configured firewall rules to allow the traffic. However, the application cannot reach the database. You have verified that routes for 10.0.0.0/16 exist in VPC1's route table with next hop to VPC Peering, and in VPC2's route table with next hop to the interconnect attachment. The BGP sessions on both interconnects are up. What is the most likely reason for the connectivity failure?

Accepted Answer

VPC Network Peering does not support transitive routing through a peered VPC. VPC Network Peering does not support transitive routing. In this topology, VPC1 is peered with VPC2, but traffic from VPC1 to DC2 must pass through VPC2 and then over the interconnect. Since VPC1's route for 10.0.0.0/16 points to the VPC peering as next hop, VPC1 expects the traffic to be forwarded directly to VPC2. However, VPC2 cannot forward that traffic to DC2 because Google Cloud VPC peering does not allow a peered VPC to act as a transit hub; each VPC can only communicate directly with its peer, not with resources reachable through that peer. This is a fundamental limitation of VPC Network Peering, which is non-transitive.

Answer

The route for 10.0.0.0/16 in VPC1 is not imported correctly from VPC Peering

Answer

BGP session on the interconnect between VPC2 and DC2 is down

Answer

Firewall rules in VPC2 are blocking traffic

Question 11

A company uses a VPC with two subnets: subnet-a (10.0.1.0/24) with VMs tagged 'web', and subnet-b (10.0.2.0/24) with VMs tagged 'db'. They have a Cloud VPN tunnel to an on-premises network (172.16.0.0/16). The VPN tunnel is up and BGP is exchanging routes. A custom route for 172.16.0.0/16 with next hop VPN gateway exists, but it has a tag 'web', meaning it applies only to VMs with the 'web' tag. VMs in subnet-a can reach on-premises, but VMs in subnet-b cannot. Which step should be taken to allow subnet-b VMs to reach on-premises?

Accepted Answer

Add the 'db' tag to the custom route.. The custom route for 172.16.0.0/16 is tagged with 'web', so it only applies to VMs that have the 'web' tag. Subnet-b VMs are tagged 'db', so they do not match the route and cannot reach on-premises. Adding the 'db' tag to the route makes it apply to both tagged groups, enabling connectivity for subnet-b VMs without affecting existing traffic.

Answer

Create a new route for 172.16.0.0/16 with priority 1000 and no tag.

Answer

Remove the tag from the existing route.

Answer

Add a firewall rule to allow egress traffic from subnet-b.

Question 12

A company uses Dedicated Interconnect to connect their on-premises data center to Google Cloud. They have enabled Private Google Access on the VPC subnet to allow on-premises hosts to access Google APIs via private IPs over the interconnect. Performance tests show that throughput to Google APIs is lower than expected, and the interconnect link utilization is below 30%. What should they do to improve throughput?

Accepted Answer

Create a Private Service Connect endpoint for Google APIs with multiple IP addresses.. Private Google Access (PGA) uses the default Internet Gateway to route traffic to Google APIs, which can lead to throughput limitations due to source NAT and flow hashing constraints. Creating a Private Service Connect (PSC) endpoint for Google APIs with multiple IP addresses allows traffic to be load-balanced across multiple endpoints, improving throughput by enabling ECMP (Equal-Cost Multi-Path) routing over the Dedicated Interconnect, thus better utilizing the available bandwidth.

Answer

Reduce the MTU on the interconnect to reduce packet loss.

Answer

Add another Dedicated Interconnect attachment.

Answer

Enable Cloud NAT to provide multiple public IPs.

Question 13

A company has two VPCs in the same project, VPC-A and VPC-B. They have set up VPC peering between them. In VPC-A, there is a subnet 10.0.1.0/24. In VPC-B, there are subnets 10.0.2.0/24 and 10.0.3.0/24. A compute instance in VPC-A can ping an instance in VPC-B with IP 10.0.2.10, but fails to ping an instance in VPC-B with IP 10.0.3.10. All subnets are in the same region. Firewall rules allow all traffic between VPC-A and VPC-B. What is the most likely cause?

Accepted Answer

VPC-A has a static route to 10.0.3.0/24 that preempts the peering route.. VPC peering routes are automatically added to the route tables of both VPCs when the peering is established. However, if a more specific static route (e.g., to 10.0.3.0/24) exists in VPC-A, it will take precedence over the peering route due to longest prefix match routing. Since the instance in VPC-A can reach 10.0.2.10 but not 10.0.3.10, the most likely cause is that VPC-A has a static route that preempts the peering route for the 10.0.3.0/24 subnet.

Answer

The peering is not bidirectional; VPC-B is not exporting routes.

Answer

The firewall rules in VPC-B block ICMP from VPC-A to 10.0.3.0/24.

Answer

The subnet 10.0.3.0/24 was added after the peering, and the peering routes were not updated. Recreate the peering.

Question 14

Your company has a VPC with two subnets: 10.0.1.0/24 in us-central1 and 10.0.2.0/24 in us-east1. They have a Cloud VPN tunnel to the on-premises data center using dynamic routing (BGP). The Cloud Router was created in the us-central1 region with default settings. On-premises hosts can successfully communicate with instances in the 10.0.1.0/24 subnet, but cannot reach instances in the 10.0.2.0/24 subnet. All instances have appropriate firewall rules allowing traffic from on-premises. The BGP session is established and routes from on-premises are received in Cloud Router. What is the most likely reason for the issue?

Accepted Answer

Cloud Router by default only advertises subnets in its own region.. Cloud Router with default settings only advertises subnets that are in the same region as the Cloud Router itself. Since the Cloud Router was created in us-central1, it only advertises the 10.0.1.0/24 subnet to the on-premises BGP peer. The 10.0.2.0/24 subnet in us-east1 is not advertised, so on-premises hosts have no route to it, even though the BGP session is up and firewall rules are correct.

Answer

The firewall rules in us-east1 are blocking incoming traffic from on-premises.

Answer

The BGP session is down for the us-east1 region.

Answer

The VPN tunnel is only configured to route traffic for us-central1.

Question 15

A company has an external HTTP(S) load balancer with a backend service pointing to an instance group in us-east1. They enable Cloud CDN to improve performance for global users. After enabling, they observe that users in Asia still experience high latency. They verify that the backend instances respond with Cache-Control headers that allow caching. What is the most likely reason for the high latency?

Accepted Answer

The load balancer is a regional load balancer, not a global one.. Option C is correct because an external HTTP(S) load balancer that is regional (e.g., a regional external HTTP(S) load balancer) cannot serve traffic globally with low latency; it is confined to a single region. Cloud CDN caches content at edge locations, but if the load balancer itself is regional, the cache points are also regional, so users in Asia still route to us-east1 for cache misses or even for cache hits if the edge is not globally distributed. Only a global external HTTP(S) load balancer (with a global anycast IP) can leverage Cloud CDN's global edge cache locations to serve users from the nearest point of presence.

Answer

The cache TTL is too short.

Answer

Cloud CDN is not enabled on the correct backend.

Answer

The backend instances are in us-east1, too far from Asia.