PCNE Implementing a Virtual Private Cloud Practice Test 6 — 15 Questions

Question 1

A network engineer is configuring VPC peering between two VPCs in the same project. The peering status is ACTIVE, but instances in one VPC cannot reach instances in the other VPC using internal IPs. The firewall rules are default (ingress deny all). What is the most likely cause?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The engineer forgot to add firewall rules to allow traffic from the peer range.. The most likely cause is that the engineer forgot to add firewall rules to allow traffic from the peer range. Even though VPC peering is ACTIVE, the default ingress deny all firewall rule blocks incoming traffic. To allow communication between instances in peered VPCs, you must create ingress firewall rules in each VPC that permit traffic from the other VPC's subnet CIDR ranges.

Answer

The VPCs use different routing modes.

Answer

The IAM permissions for the peering are missing.

Answer

The VPCs have overlapping subnet CIDR ranges.

Question 2

A network engineer wants to allow specific instances to use Cloud NAT while others should not. Which configuration step should be taken?

Accepted Answer

Apply a network tag to instances that should use NAT and create a Cloud NAT with that tag.. Cloud NAT in Google Cloud can be scoped to specific instances using network tags. By applying a network tag to the instances that should use NAT and then creating a Cloud NAT gateway with that tag, only those tagged instances will have their traffic NATed. This allows granular control without affecting other instances in the same subnet.

Answer

Assign external IPs to non-NAT instances.

Answer

Use firewall rules to allow NAT for tagged instances.

Answer

Create separate subnets for NAT instances.

Question 3

Which of the following is a benefit of using Shared VPC?

Accepted Answer

Centralized network administration and separation from application projects.. Shared VPC allows a host project's network to be shared with service projects, enabling centralized network administration (subnets, firewalls, routes managed in one place) while keeping application resources isolated in separate projects. This separation of duties between network admins and app teams is the primary benefit.

Answer

Lower cost compared to VPC peering.

Answer

Automatic failover for applications.

Answer

Reduced latency between instances.

Question 4

A company needs to connect on-premises to Google Cloud with overlapping IP ranges. The on-premises network uses 10.0.0.0/16 and the VPC uses 10.0.0.0/16. What is the best approach?

Accepted Answer

Use Cloud VPN with source NAT on the on-premises side.. When on-premises and VPC CIDR ranges overlap (both 10.0.0.0/16), routing breaks because the same destination prefix exists on both sides and Cloud Router/VPN cannot distinguish them. The only way to make a Cloud VPN work is to hide the on-premises addresses behind a non-overlapping range before they enter the tunnel — i.e., apply source NAT (SNAT) on the on-premises VPN gateway so packets arrive at the Google Cloud VPN with a translated source IP (e.g., 192.168.0.0/24). Google Cloud then routes return traffic back to that translated range, and the on-premises device un-NATs it. This preserves connectivity without renumbering either network.

Answer

Use Cloud NAT.

Answer

Use VPC peering.

Answer

Use Private Google Access.

Question 5

A security team wants to restrict which Google services can be accessed from their VPC without external IPs. They use Private Google Access. What should they use to block access to specific services?

Accepted Answer

VPC Service Controls. VPC Service Controls allows creating security perimeters that restrict access to services.

Answer

Firewall rules blocking destination IPs

Answer

Cloud NAT with a specific IP range

Answer

Private Google Access with restricted VIPs

Question 6

Which THREE statements about Shared VPC are correct?

Accepted Answer

The Shared VPC admin role can be assigned to manage the host VPC network.. Option A is correct because the Shared VPC Admin role (roles/compute.xpnAdmin) is the IAM role granted at the organization or host project level that allows a principal to enable Shared VPC, designate host projects, and manage the host VPC network configuration. Option B is correct because the core purpose of Shared VPC is to let service projects deploy resources (such as Compute Engine VMs) into subnetworks that are defined and centrally managed in the host project's VPC network. Option C is correct because Shared VPC requires that the host project and all attached service projects belong to the same Google Cloud organization; cross-organization attachment is not supported. Option D is not correct because subnet administration, including creating and deleting subnets, is performed by the Shared VPC Admin in the host project, not by service projects, which only consume the shared subnets. Option E is not correct because service projects do not create their own VPCs to peer with the host VPC; instead they attach to the host project's VPC and use its subnetworks directly.

Answer

Service projects can delete subnets in the host VPC.

Answer

Service projects can create their own VPCs that peer with the host VPC.

Question 7

Refer to the exhibit. You have two VPCs, vpc-a and vpc-b, with VPC peering configured and custom route import/export enabled. An instance in subnet-a (10.0.1.2) cannot ping an instance in subnet-b (10.0.2.2) using internal IP. Firewall rules are default (deny all ingress). What is the required action?

Accepted Answer

Add a firewall rule allowing ICMP from 10.0.1.0/24 to 10.0.2.0/24.. With VPC peering and custom route import/export enabled, routes are exchanged, so connectivity exists at the network layer. However, the default firewall rules deny all ingress, so ICMP traffic from subnet-a to subnet-b is blocked. To allow ping, a firewall rule must be added in vpc-b (or both VPCs) permitting ICMP from 10.0.1.0/24 to 10.0.2.0/24. This is the required action.

Answer

Add a static route for the peer range.

Answer

Enable Private Google Access.

Answer

Create a Cloud VPN tunnel.

Question 8

Refer to the exhibit. You are troubleshooting an on-premises to Cloud VPN connection with dynamic routing. The BGP session is CONNECTED, but no routes are received from the on-premises router. What is the most likely cause?

Accepted Answer

The on-premises router is not configured to advertise routes.. The BGP session being CONNECTED means that TCP port 179 is open and the BGP handshake completed successfully, so firewall rules are not blocking BGP traffic and the VPN tunnel is up. The lack of received routes indicates that the on-premises router is not sending any BGP UPDATE messages with network layer reachability information (NLRI). This is typically because the on-premises router is not configured to advertise its local routes to the BGP peer, either due to missing network statements, redistribution, or outbound filters. Therefore, option B is the most likely cause.

Answer

The firewall rules are blocking BGP traffic.

Answer

The VPN tunnel is down.

Answer

The cloud router is not advertising any routes.

Question 9

Refer to the exhibit. Instances in subnet-b cannot access the internet through Cloud NAT. What is the most likely reason?

Accepted Answer

Subnet-b is not included in the Cloud NAT configuration.. The most likely reason instances in subnet-b cannot access the internet through Cloud NAT is that subnet-b is not included in the Cloud NAT configuration. Cloud NAT in Google Cloud is configured at the region level and requires specifying which subnets (or all subnets) should use the NAT gateway. If subnet-b is not explicitly included, its instances will not have NAT applied, and thus cannot reach the internet.

Answer

The firewall rules in subnet-b block egress.

Answer

The NAT IP address pool is exhausted.

Answer

Subnet-b has overlapping subnets.

Question 10

A company has two VPC networks in the same project: 'vpc-a' (us-central1) and 'vpc-b' (us-east1). They are connected via VPC Network Peering. An instance in vpc-a can ping the internal IP of an instance in vpc-b, but cannot reach it on TCP port 8080. The firewall rule in vpc-b allows ingress from the peered network's subnets. What is the most likely cause?

Accepted Answer

The firewall rule for port 8080 is missing or uses an incorrect target tag or service account.. VPC Network Peering is not transitive and does not carry firewall rules across networks — each VPC enforces its own firewall policies. Since ping (ICMP) succeeds, routing and peering are working; the failure is isolated to TCP/8080, which means the ingress rule in vpc-b either doesn't exist for that port or doesn't match the source instance via its target tag or service account. Firewall rules in GCP are stateful and applied per-VM based on target tags/service accounts, so a mismatched target is the classic cause of 'some ports work, others don't.'

Answer

The instance in vpc-b has a firewall rule that denies TCP port 8080 explicitly.

Answer

The subnet in vpc-a is in a different region, so peering does not support cross-region communication.

Answer

The firewall rule in vpc-b must allow ingress from the entire CIDR of vpc-a's subnet, not just the peered network.

Question 11

A company is planning to migrate its on-premises workloads to Google Cloud. They have a few dedicated servers that need to be reachable from the internet via specific public IPs. Which TWO options should they consider to assign static public IP addresses to their Compute Engine instances? (Choose 2.)

Accepted Answer

Promote an existing ephemeral external IP address to static.. Option A is correct because Compute Engine allows you to promote an ephemeral external IP that is already attached to an instance to a static external IP address, preserving the same public IP for long-term use. Option B is correct because you can reserve a new static external (regional) IP address in the project and then assign it to the instance's network interface, which is the standard way to give an instance a fixed public IP. Option C is incorrect because a static internal IP is only routable inside the VPC and cannot serve as a public IP via DNS. Option D is incorrect because Cloud NAT provides outbound internet access with a static NAT IP for egress, not inbound reachability to instances. Option E is incorrect because internal IP addresses are private and cannot be made public by firewall rules; firewalls control traffic, not address translation.

Answer

Assign a static internal IP address and use it as the public IP via DNS.

Answer

Configure Cloud NAT to assign a static IP for inbound traffic.

Answer

Use the instance's internal IP address as the public IP by configuring the VPC firewall.

Question 12

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 VPC firewall rules are the most likely cause. Google Cloud VPC firewall rules are stateful and must explicitly allow ingress traffic from the on-premises CIDR (192.168.0.0/16) to the database instance's internal IP (10.0.0.10) on the required port. Even though the OS firewall allows all traffic, the VPC-level firewall is evaluated first and will drop packets if no allow rule matches. Since the on-premises server can ping the on-premises gateway but not the database, the issue is likely at the VPC ingress firewall, not routing or BGP.

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 13

A company wants to establish a VPC peering connection between two VPCs in different projects. Which two steps are mandatory to create the peering connection?

Accepted Answer

Ensure the VPCs have non-overlapping subnet IP address ranges.. 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.

Answer

Assign a public IP to the VMs in both VPCs.

Answer

Create a firewall rule allowing all traffic between the VPCs.

Answer

Configure a Cloud Router with BGP sessions.

Question 14

A company has a VPC with two subnets: subnet-a (10.0.1.0/24) in us-central1 and subnet-b (10.0.2.0/24) in europe-west1. They need to create a new subnet in asia-east1 with a secondary IP range for a GKE cluster. Which command should they use?

Accepted Answer

gcloud compute networks subnets create subnet-c --network=my-vpc --region=asia-east1 --range=10.0.3.0/24 --secondary-range=services=10.0.4.0/24. The correct command includes the required --secondary-range flag with a name and CIDR separated by an equals sign. This allows the subnet to host a GKE cluster that needs distinct IP ranges for pods and services. The other options either misuse the flag syntax or add an inappropriate purpose.

Answer

gcloud compute networks subnets create subnet-c --network=my-vpc --region=asia-east1 --range=10.0.3.0/24 --secondary-range=10.0.4.0/24

Answer

gcloud compute networks subnets create subnet-c --network=my-vpc --region=asia-east1 --range=10.0.3.0/24 --secondary-range=services:10.0.4.0/24

Answer

gcloud compute networks subnets create subnet-c --network=my-vpc --region=asia-east1 --range=10.0.3.0/24 --secondary-range=services=10.0.4.0/24 --purpose=PRIVATE

Question 15

A network engineer needs to create a VPC network that allows instances in different regions to communicate using internal IP addresses. The company requires that the VPC automatically creates subnets in each region when a new region is used. Which VPC network type should they choose?

Accepted Answer

Auto mode VPC network. Auto mode VPC networks automatically create a subnet in each Google Cloud region using predefined IP ranges. This satisfies the need for automatic subnet creation and allows instances across regions to communicate internally. Custom mode requires manual subnet creation, legacy networks do not support subnets, and Shared VPC is a sharing mechanism rather than a network type. Therefore, auto mode is the correct choice.

Answer

Legacy network

Answer

Shared VPC network

Answer

Custom mode VPC network