PCNE Designing, Planning, and Prototyping a GCP Network Practice Test 7 — 15 Questions

Question 1

A company uses Shared VPC with multiple service projects. They want to ensure that only specific service projects can use the Cloud NAT configured in the host project. What should they do?

Accepted Answer

Configure Cloud NAT with a specific network tag and assign that tag only to VMs in authorized service projects.. Cloud NAT can be restricted to specific VMs using network tags. By configuring the Cloud NAT gateway in the host project with a specific network tag, and then assigning that tag only to the VM instances in authorized service projects, only those tagged VMs can use the NAT gateway. This ensures that only specific service projects (via their tagged VMs) can leverage the Cloud NAT, while all other VMs in the shared VPC are excluded.

Answer

Use firewall rules to restrict traffic from service projects.

Answer

Use VPC Service Controls to restrict access.

Answer

Configure IAM roles on the Cloud NAT resource to allow only specific projects.

Question 2

A company needs to connect on-premises to GCP using Dedicated Interconnect with a 10 Gbps link, and they require high availability. They plan to use a single VLAN attachment. What is the best design?

Accepted Answer

Deploy two interconnects with one VLAN attachment each.. For high availability with Dedicated Interconnect, you need two separate physical connections (interconnects) to avoid a single point of failure. Each interconnect must have its own VLAN attachment and BGP session to ensure that if one link fails, traffic can still flow over the other. A single VLAN attachment cannot provide redundancy because it is tied to one physical interconnect.

Answer

Deploy one interconnect with one VLAN attachment and a VPN as backup.

Answer

Deploy one interconnect with one VLAN attachment and use static routing.

Answer

Deploy two VLAN attachments on the same interconnect with separate BGP sessions.

Question 3

A company wants to allow on-premises servers to access Google APIs and services through a Dedicated Interconnect without using public IPs. What should they configure?

Accepted Answer

Enable Private Google Access on the VPC subnet.. Private Google Access enables on-premises hosts connected via Dedicated Interconnect to reach Google APIs and services using internal IP addresses. When enabled on the VPC subnet, traffic destined for Google APIs is routed through the interconnect without needing public IPs, as the VPC uses its default routes and Cloud NAT-like functionality to forward requests to Google's internal addresses.

Answer

Set up VPC Network Peering.

Answer

Configure Private Service Connect.

Answer

Configure Cloud Router with custom route advertisement.

Question 4

A company has a VPC with several subnets and wants to force traffic between two specific subnets (A and B) to be inspected by a third-party firewall appliance in a separate subnet (C). The firewall has source/destination check disabled. What is the best way to route traffic from A to B through C?

Accepted Answer

Use a policy-based route to redirect traffic from A to B to the firewall's IP.. Policy-based routes allow you to define a forwarding rule that matches traffic based on source and destination IP ranges, then sends it to a next-hop instance (the firewall). Since the firewall has source/destination check disabled, it can forward the inspected traffic to the final destination. This is the only option that directly forces traffic between subnets A and B through the firewall in subnet C.

Answer

Use Cloud NAT to route traffic through the firewall.

Answer

Use a custom route with a lower priority for the destination subnet.

Answer

Use VPC flow logs to monitor traffic.

Question 5

A company is designing a hybrid network with Cloud VPN. Which TWO best practices should they follow? (Choose TWO.)

Accepted Answer

Use pre-shared keys for authentication.. 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.

Answer

Use a VPN tunnel per subnet.

Answer

Use static routes for simplicity.

Answer

Use a single VPN tunnel for all traffic.

Question 6

A company uses Shared VPC. They want to restrict which service project's VMs can use a specific subnet. Which TWO methods can achieve this? (Choose TWO.)

Accepted Answer

Use IAM roles on the subnet resource to grant 'compute.subnetUser' to specific service projects.. IAM roles on a subnet resource allow you to grant the `compute.subnetUser` role to specific service projects, which controls which projects can create VM instances in that subnet. This is a direct method to restrict subnet usage within a Shared VPC environment, as the role grants permission to use the subnet without granting broader network access.

Answer

Use VPC network peering.

Answer

Use firewall rules to deny traffic from other service projects.

Answer

Use network tags on VMs and associate the subnet with those tags.

Question 7

A company is planning to migrate to Google Cloud and needs to design a VPC network for a multi-tier application (web, app, database). Which THREE best practices should they follow? (Choose THREE.)

Accepted Answer

Create separate subnets for each tier and use firewall rules to control traffic between them.. 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.

Answer

Use one subnet for all tiers to simplify routing.

Answer

Use instance-level firewalls instead of VPC firewall rules.

Question 8

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 9

A company uses a Shared VPC with a host project and multiple service projects. They have deployed Cloud NAT in the host project's network to provide internet access for service project instances. The Cloud NAT is configured to use a network tag 'nat'. Instances in service projects that have the tag 'nat' can reach the internet. A new service project is added and its instances are created with the same tag 'nat' in a subnet in europe-west1. However, these instances cannot reach the internet. Other service project instances with the tag 'nat' in us-central1 work fine. The Cloud NAT is deployed in us-central1. What is the most likely cause?

Accepted Answer

The Cloud NAT is not in the same region as the new service project's instances.. Cloud NAT is a regional resource; it only provides outbound internet access to instances within the same region. Since the Cloud NAT is deployed in us-central1, instances in europe-west1 cannot use it, regardless of their network tag. The instances in the new service project must have a Cloud NAT deployed in europe-west1 to reach the internet.

Answer

The Cloud NAT's UDP timeout is too short.

Answer

The firewall rules in the host project block traffic from the new service project's subnets.

Answer

The new service project's instances are not tagged with 'nat'.

Question 10

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.. 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.

Question 11

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 12

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 13

A company has a VPC with a subnet 10.0.1.0/24 in us-central1. They have deployed Compute Engine instances that need to communicate with an on-premises database via a Cloud VPN tunnel using BGP. The on-premises network advertises the database subnet 192.168.0.0/16. The instances can reach the database for a few minutes after reboot, but then connectivity drops. The Cloud VPN logs show no errors. The BGP session remains established. What is the most likely issue?

Accepted Answer

The on-premises firewall has an idle timeout that kills the TCP session.. The on-premises firewall is likely configured with an idle timeout that terminates TCP sessions when no traffic is exchanged for a certain period. After the instances reboot, they initiate new connections that work briefly, but once the session becomes idle (e.g., no keepalives or application traffic), the firewall drops the stateful session, causing connectivity loss. The Cloud VPN and BGP session remain up, indicating the issue is at the application or firewall layer, not the tunnel or routing.

Answer

The GCP route to the on-premises database is being preempted by a more specific route.

Answer

The VPN tunnel's IKE session expires.

Answer

The BGP session is flapping.

Question 14

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 15

A large multinational corporation uses a Shared VPC in Google Cloud with multiple service projects. They have a central Cloud NAT configured in the host project in the us-central1 region to provide internet egress for all VMs. Recently, the IT team added a new subnet (10.0.10.0/24) in a service project and deployed VMs there. All other VMs in the same project but in different subnets (e.g., 10.0.1.0/24) can reach the internet, but the new VMs in 10.0.10.0/24 cannot. The Cloud NAT gateway is configured in us-central1 with all IP ranges allowed. The VPC firewall rules allow egress traffic to the internet. The team verified that the VMs have a default route (0.0.0.0/0) with next-hop 'default-internet-gateway' and that the Cloud NAT router's NAT IPs are properly assigned. However, the new subnet's VMs are unable to connect to any external IP. The network engineer suspects that the Cloud NAT's NAT reservations might be the issue, but all NAT IPs are ephemeral. Further investigation shows that the Cloud Router used by Cloud NAT is advertising custom IP ranges via BGP to an on-premises router for a different use case. What is the most likely cause and solution?

Accepted Answer

Remove the new subnet range (10.0.10.0/24) from the custom advertised routes on the Cloud Router associated with the Cloud NAT.. The Cloud Router associated with Cloud NAT is advertising custom IP ranges via BGP to an on-premises router. If the new subnet range (10.0.10.0/24) is included in those custom advertised routes, the on-premises router may advertise a more specific route back to the VPC, causing the VMs in that subnet to prefer the on-premises route over the default route (0.0.0.0/0) for internet-bound traffic. Since the on-premises router does not have internet access, the traffic is blackholed. Removing the subnet range from the custom advertised routes on the Cloud Router resolves the issue by ensuring the default route remains the preferred path for internet egress.

Answer

Add a static route for 0.0.0.0/0 with next-hop set to the Cloud NAT gateway's IP address in the VPC.

Answer

Update the VPC firewall rules to explicitly allow egress traffic from the new subnet's IP range to 0.0.0.0/0.

Answer

Reserve static NAT IPs for the new subnet in the Cloud NAT configuration to ensure that the VMs have a consistent egress IP.