PCNE · topic practice
Practise Google Professional Cloud Network Engineer Troubleshooting practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.
Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.
What the exam tests
Troubleshooting questions test whether you can apply the concept in context, not just recognise a definition.
How the topic appears in realistic exam-style scenarios.
Which detail in the question changes the correct answer.
How to eliminate plausible but wrong options.
How to connect the question back to the wider exam objective.
Watch out for
Practice set
20 questions · select your answer, then reveal the explanation
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Trap 1: Ensure that the VPC has a default route to the internet gateway.
Cloud NAT automatically uses the default route; no explicit route to internet gateway needed.
Trap 2: Check the DNS resolution for the external service.
DNS resolution is not related to Cloud NAT functionality.
Check if the external service is blocking the Cloud NAT IP addresses.
Some external services may block specific IP ranges, including NAT IPs.
Verify that the VPC firewall rules allow egress traffic from the instances.
Cloud NAT requires firewall rules to allow outbound traffic.
Ensure that the VPC has a default route to the internet gateway.
Why wrong: Cloud NAT automatically uses the default route; no explicit route to internet gateway needed.
Verify that the Cloud Router associated with Cloud NAT is healthy and has established BGP sessions.
Cloud NAT uses routes from Cloud Router; if BGP is down, NAT may not work properly.
Check the DNS resolution for the external service.
Why wrong: DNS resolution is not related to Cloud NAT functionality.
Trap 1: Ensure that the Cloud Router is configured with the correct BGP ASN
Incorrect ASN would prevent BGP session from establishing, but it is already up.
Trap 2: Check that GCP has a static route for 10.0.1.0/24 pointing to the…
With dynamic routing, routes are learned via BGP; static routes are not needed.
Trap 3: Check GCP firewall rules to allow ingress from 10.0.1.0/24
Firewall rules control inbound traffic; the issue is outbound from GCP to on-premises.
Verify that the on-premises router is advertising the 10.0.1.0/24 prefix via BGP
If the prefix is not advertised, GCP will not have a route to reach it.
Ensure that the Cloud Router is configured with the correct BGP ASN
Why wrong: Incorrect ASN would prevent BGP session from establishing, but it is already up.
Check that GCP has a static route for 10.0.1.0/24 pointing to the VPN tunnel
Why wrong: With dynamic routing, routes are learned via BGP; static routes are not needed.
Check GCP firewall rules to allow ingress from 10.0.1.0/24
Why wrong: Firewall rules control inbound traffic; the issue is outbound from GCP to on-premises.
Trap 1: Verify that the on-premises network has IAM permissions to access…
IAM is not a factor in network connectivity.
Trap 2: Ensure that the VLAN attachment IP is in the same subnet as the…
VLAN attachment IP is separate.
Trap 3: Check that BGP sessions are established between Cloud Router and…
BGP is not strictly required if static routes are used.
Verify that the on-premises network has IAM permissions to access instances
Why wrong: IAM is not a factor in network connectivity.
Confirm that the subnet routes for the instance IP ranges are present in the VPC
Routes must exist for return traffic.
Verify that VPC firewall rules allow traffic from the on-premises subnets
Firewall rules must permit the traffic.
Ensure that the VLAN attachment IP is in the same subnet as the instances
Why wrong: VLAN attachment IP is separate.
Check that BGP sessions are established between Cloud Router and on-premises router
Why wrong: BGP is not strictly required if static routes are used.
Trap 1: Delete and recreate the VLAN attachment.
That is a destructive step; better to check configurations first.
Trap 2: Revert all BGP routes to static routes.
This is a drastic measure and not a troubleshooting step.
Trap 3: Increase the bandwidth of the interconnect.
Bandwidth does not cause flapping; flapping is usually due to configuration or link stability.
Check the MTU size on the VPN tunnel or interconnect.
MTU mismatches can cause packet loss and BGP session drops.
Delete and recreate the VLAN attachment.
Why wrong: That is a destructive step; better to check configurations first.
Revert all BGP routes to static routes.
Why wrong: This is a drastic measure and not a troubleshooting step.
Verify BGP timers and hold time settings.
Incorrect timers can cause premature session termination.
Increase the bandwidth of the interconnect.
Why wrong: Bandwidth does not cause flapping; flapping is usually due to configuration or link stability.
Trap 1: Change the BGP ASN on the Cloud Router to a different number
They have verified the ASNs; this step might be needed only if ASN mismatch, but they said they are same. However, if same ASN, BGP may need 'allow-as' or 'as-override', but the question indicates they've already checked, so not the most likely next step.
Trap 2: Increase the BGP hold timer on the Cloud Router
Changing hold timer would not affect session establishment if the problem is connectivity.
Trap 3: Change the BGP keepalive interval to 10 seconds
Keepalive interval is not related to CONNECT state.
Change the BGP ASN on the Cloud Router to a different number
Why wrong: They have verified the ASNs; this step might be needed only if ASN mismatch, but they said they are same. However, if same ASN, BGP may need 'allow-as' or 'as-override', but the question indicates they've already checked, so not the most likely next step.
Ensure the on-premises router has a route to the Cloud Router's BGP peer IP address
Without a return route, BGP packets cannot reach the Cloud Router.
Increase the BGP hold timer on the Cloud Router
Why wrong: Changing hold timer would not affect session establishment if the problem is connectivity.
Change the BGP keepalive interval to 10 seconds
Why wrong: Keepalive interval is not related to CONNECT state.
Verify the Cloud VPN tunnel is established and passing traffic
A non-working tunnel can prevent BGP from establishing.
Trap 1: The Cloud Router is not configured for dynamic routing.
Dynamic routing is enabled via BGP; if BGP sessions are up, routing is dynamic.
Trap 2: One of the IPsec tunnels is in a dead state.
If a tunnel is dead, BGP would also be down, not established.
Trap 3: The on-premises router is setting a higher local preference on one…
Local preference is used for inbound decisions on the receiving router; it would affect on-premises routing to Google, not Google routing to on-premises.
The on-premises router is sending different BGP metrics (MED) for the same route on the two BGP sessions.
If MED differs, Cloud Router will prefer lower MED, leading to single-path use.
The Cloud Router is not configured for dynamic routing.
Why wrong: Dynamic routing is enabled via BGP; if BGP sessions are up, routing is dynamic.
One of the IPsec tunnels is in a dead state.
Why wrong: If a tunnel is dead, BGP would also be down, not established.
The on-premises router is setting a higher local preference on one route.
Why wrong: Local preference is used for inbound decisions on the receiving router; it would affect on-premises routing to Google, not Google routing to on-premises.
Drag a concept onto its matching description — or click a concept then click the description.
Tests basic connectivity to an IP address
Traces the path packets take to a destination
Displays network connections and listening ports
Queries DNS to resolve a hostname
Captures and analyzes network packets
Refer to the exhibit.
```
$ gcloud compute routers get-status my-router --region=us-central1
kind: compute#routerStatusResponse
result:
router: my-router
bgpPeerStatus:
- name: peer-a
ipAddress: 169.254.1.1
peerIpAddress: 169.254.1.2
status: UP
numUp: 1
numLearned: 0
advertisedRoutes:
- 10.0.0.0/8
learnedRoutes: []
- name: peer-b
ipAddress: 169.254.2.1
peerIpAddress: 169.254.2.2
status: DOWN
numUp: 0
numLearned: 0
advertisedRoutes: []
learnedRoutes: []
```Trap 1: Both BGP sessions are down
peer-a is UP.
Trap 2: The BGP session for peer-a is down
peer-a status is UP.
Trap 3: The Cloud Router is not advertising any routes to on-premises
The Cloud Router is advertising routes (10.0.0.0/8), but that is not the issue.
Both BGP sessions are down
Why wrong: peer-a is UP.
The BGP session for peer-a is down
Why wrong: peer-a status is UP.
The on-premises router is not advertising any routes to the Cloud Router
learnedRoutes is empty for peer-a, indicating no routes received from on-premises.
The Cloud Router is not advertising any routes to on-premises
Why wrong: The Cloud Router is advertising routes (10.0.0.0/8), but that is not the issue.
Trap 1: Check the VM's OS firewall to see if it is blocking incoming traffic
While possible, the VPC firewall is the first layer of defense and easier to check.
Trap 2: Verify that the VPN tunnel is using the correct pre-shared key
If the tunnel is established, the PSK is correct.
Trap 3: Review Cloud Armor security policies that may be blocking the…
Cloud Armor applies to load-balanced traffic, not direct VPN traffic.
Check VPC firewall rules to ensure ingress traffic from the on-premises subnet is allowed to the VM
Firewall rules must allow traffic from the on-premises IP range to the VM's target tags or service account.
Check the VM's OS firewall to see if it is blocking incoming traffic
Why wrong: While possible, the VPC firewall is the first layer of defense and easier to check.
Verify that the VPN tunnel is using the correct pre-shared key
Why wrong: If the tunnel is established, the PSK is correct.
Review Cloud Armor security policies that may be blocking the traffic
Why wrong: Cloud Armor applies to load-balanced traffic, not direct VPN traffic.
Refer to the exhibit. ``` gcloud compute networks subnets describe subnet-a --region us-central1 creationTimestamp: '2024-01-15T10:00:00.000-08:00' description: '' enableFlowLogs: false gatewayAddress: 10.0.0.1 id: '123456789' ipCidrRange: 10.0.0.0/24 kind: compute#subnetwork logConfig: null name: subnet-a network: https://www.googleapis.com/compute/v1/projects/my-project/global/networks/vpc-1 privateIpGoogleAccess: false purpose: PRIVATE region: https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1 role: null secondaryIpRanges: [] selfLink: https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1/subnetworks/subnet-a state: READY ```
Trap 1: The subnet purpose is PRIVATE, which blocks Google APIs.
Purpose PRIVATE is standard for regular subnets.
Trap 2: The subnet CIDR range is too small.
The /24 range is sufficient for typical use.
Trap 3: Flow logs are disabled, so traffic is not logged.
Flow logs are for monitoring, not enabling connectivity.
The subnet purpose is PRIVATE, which blocks Google APIs.
Why wrong: Purpose PRIVATE is standard for regular subnets.
Private Google Access is disabled on the subnet.
Private Google Access must be enabled for instances without external IPs to access Google APIs.
The subnet CIDR range is too small.
Why wrong: The /24 range is sufficient for typical use.
Flow logs are disabled, so traffic is not logged.
Why wrong: Flow logs are for monitoring, not enabling connectivity.
Refer to the exhibit. Output from a Cloud Router BGP session: ``` show ip bgp summary BGP router identifier 10.0.0.1, local AS number 64512 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 169.254.1.1 4 65001 10 12 0 0 0 00:01:23 1 169.254.1.1 4 65001 0 0 0 0 0 00:00:34 Active ```
Trap 1: The Cloud Router is using the same BGP identifier for both…
Cloud Router uses the same router ID for both interfaces; but that is allowed and shouldn't cause Active state.
Trap 2: The on-premises router is configured with BGP MD5 authentication…
MD5 mismatch would result in an Open message error, not persistent Active state.
Trap 3: The MTU on the second tunnel is not matching between the two ends.
MTU mismatch would affect data traffic, not BGP session establishment.
The on-premises router does not have a BGP configuration for the second peer IP address (169.254.x.x).
If the on-premises router is not expecting a connection from the second peer IP, it will not respond, leaving the Cloud Router in Active state.
The Cloud Router is using the same BGP identifier for both sessions, causing a conflict.
Why wrong: Cloud Router uses the same router ID for both interfaces; but that is allowed and shouldn't cause Active state.
The on-premises router is configured with BGP MD5 authentication that only matches the first peer.
Why wrong: MD5 mismatch would result in an Open message error, not persistent Active state.
The MTU on the second tunnel is not matching between the two ends.
Why wrong: MTU mismatch would affect data traffic, not BGP session establishment.
Trap 1: Packet Mirroring
Packet Mirroring copies traffic for analysis but is more complex than needed for simple logs.
Trap 2: Cloud Audit Logs
Audit logs capture API calls, not network traffic.
Trap 3: Firewall Rules Logging
Firewall rules logging only logs packets that are allowed or denied by firewall rules, not all traffic.
Packet Mirroring
Why wrong: Packet Mirroring copies traffic for analysis but is more complex than needed for simple logs.
VPC Flow Logs
VPC Flow Logs sample and log network flows with metadata.
Cloud Audit Logs
Why wrong: Audit logs capture API calls, not network traffic.
Firewall Rules Logging
Why wrong: Firewall rules logging only logs packets that are allowed or denied by firewall rules, not all traffic.
Trap 1: The advertised route from the on-premises router is a default route.
BGP is established, so routes are exchanged; whether it is default or not, on-premises can still initiate traffic.
Trap 2: The MTU size of the VPN tunnel.
MTU mismatch can cause issues but is less likely than firewall rules.
Trap 3: The Cloud VPN gateway is assigned an external IP address.
The gateway's external IP is required for the tunnel; if the tunnel is up, it must have one.
The advertised route from the on-premises router is a default route.
Why wrong: BGP is established, so routes are exchanged; whether it is default or not, on-premises can still initiate traffic.
The MTU size of the VPN tunnel.
Why wrong: MTU mismatch can cause issues but is less likely than firewall rules.
The Cloud VPN gateway is assigned an external IP address.
Why wrong: The gateway's external IP is required for the tunnel; if the tunnel is up, it must have one.
The firewall rules in the VPC allowing incoming traffic from the on-premises CIDR.
Firewall rules control inbound traffic; without an allow rule, traffic is denied.
Trap 1: Cloud NAT logging
NAT logging only covers NATted traffic.
Trap 2: Packet Mirroring
Packet Mirroring copies traffic for inspection but is very resource-intensive.
Trap 3: Traffic Director
Traffic Director is for service mesh, not traffic logging.
Cloud NAT logging
Why wrong: NAT logging only covers NATted traffic.
VPC Flow Logs
VPC Flow Logs sample and log network flows, useful for diagnostics.
Packet Mirroring
Why wrong: Packet Mirroring copies traffic for inspection but is very resource-intensive.
Traffic Director
Why wrong: Traffic Director is for service mesh, not traffic logging.
Trap 1: The firewall rules are blocking BGP traffic.
If BGP traffic was blocked, the session would not be CONNECTED.
Trap 2: The VPN tunnel is down.
The BGP session being CONNECTED indicates the tunnel is up.
Trap 3: The cloud router is not advertising any routes.
The exhibit shows advertised groups: ALL_SUBNETS, so cloud router is advertising.
The firewall rules are blocking BGP traffic.
Why wrong: If BGP traffic was blocked, the session would not be CONNECTED.
The on-premises router is not configured to advertise routes.
Since the BGP session is CONNECTED but no routes received, the on-premises side is not advertising.
The VPN tunnel is down.
Why wrong: The BGP session being CONNECTED indicates the tunnel is up.
The cloud router is not advertising any routes.
Why wrong: The exhibit shows advertised groups: ALL_SUBNETS, so cloud router is advertising.
Trap 1: A firewall rule is blocking ingress traffic from the on-premises…
Firewall rules would block all traffic, not just return.
Trap 2: The BGP session is down.
If BGP session is down, no routes are exchanged, so no connectivity.
Trap 3: The Cloud Router is not configured.
Cloud Router is needed for BGP, but static routes can be used; missing Cloud Router does not cause asymmetric drop.
The on-premises network does not have a route back to the VPC subnet.
Return traffic requires a route on-premises pointing to the VPN gateway.
A firewall rule is blocking ingress traffic from the on-premises network.
Why wrong: Firewall rules would block all traffic, not just return.
The BGP session is down.
Why wrong: If BGP session is down, no routes are exchanged, so no connectivity.
The Cloud Router is not configured.
Why wrong: Cloud Router is needed for BGP, but static routes can be used; missing Cloud Router does not cause asymmetric drop.
Trap 1: Reducing network latency.
Flow logs do not affect network performance.
Trap 2: Real-time network monitoring.
Flow logs are aggregated and have a delay, not real-time.
Compliance and audit requirements.
Flow logs provide records of network traffic for compliance.
Troubleshooting connectivity issues.
Flow logs help identify dropped packets and connectivity problems.
Detecting DDoS attacks.
Flow logs can show anomalous traffic patterns indicative of DDoS.
Reducing network latency.
Why wrong: Flow logs do not affect network performance.
Real-time network monitoring.
Why wrong: Flow logs are aggregated and have a delay, not real-time.
Trap 1: Ensure that the subnets in both VPCs don't overlap.
Overlapping subnets are not allowed in peering, but that would prevent peering, not drops.
Trap 2: Disable the firewall rules to see if traffic flows.
This would bypass security and not pinpoint the issue.
Trap 3: Verify that the VPCs are in the same project.
VPC peering can work across projects.
Ensure that the subnets in both VPCs don't overlap.
Why wrong: Overlapping subnets are not allowed in peering, but that would prevent peering, not drops.
Use Packet Mirroring to capture traffic on both sides and compare.
Packet Mirroring can help identify if traffic is reaching the destination instance.
Check for asymmetric routing by reviewing the VPC peering routes and Cloud Router sessions.
Asymmetric routing can cause drops.
Disable the firewall rules to see if traffic flows.
Why wrong: This would bypass security and not pinpoint the issue.
Verify that the VPCs are in the same project.
Why wrong: VPC peering can work across projects.
Trap 1: VPC Flow Logs capture only egress traffic.
They capture both ingress and egress traffic.
Trap 2: VPC Flow Logs only capture traffic that is allowed by firewall…
They capture both allowed and denied traffic (if logging is enabled for the rule).
Trap 3: VPC Flow Logs capture all packets for every flow in the VPC.
Flow logs are sampled (default 1 per 10 packets) and not all flows are captured.
VPC Flow Logs capture only egress traffic.
Why wrong: They capture both ingress and egress traffic.
VPC Flow Logs only capture traffic that is allowed by firewall rules.
Why wrong: They capture both allowed and denied traffic (if logging is enabled for the rule).
VPC Flow Logs can be used to diagnose overly permissive firewall rules.
By analyzing logs, you can see allowed traffic and identify rules that are too broad.
VPC Flow Logs capture all packets for every flow in the VPC.
Why wrong: Flow logs are sampled (default 1 per 10 packets) and not all flows are captured.
VPC Flow Logs do not capture traffic that is generated by GCP health checks.
Health check traffic is excluded from flow logs.
Free account
Create a free account to save your results and see which topics improve across sessions.
Focused Troubleshooting sessions
Every question in these sessions is drawn from the Troubleshooting domain — nothing else.
Related practice questions
Move into related areas when this topic feels solid.
Practise PCNE questions linked to Designing, planning, and prototyping a GCP network.
Practise PCNE questions linked to Implementing hybrid interconnectivity.
Practise PCNE questions linked to Configuring network services.
Practise PCNE questions linked to Implementing network security.
Practise PCNE questions linked to Implementing a Virtual Private Cloud.
Practise PCNE questions linked to PCNE fundamentals.
Practise PCNE questions linked to PCNE scenario.
Practise PCNE questions linked to PCNE troubleshooting.
A free account saves results across sessions and highlights which topics need work.
Sign up free