Sample questions
Google Professional Cloud Network Engineer practice questions
An organization is migrating to Google Cloud and requires connectivity between their on-premises network and VPC. They plan to use Cloud VPN with dynamic routing (BGP). Which VPC feature is required for this setup?
Trap 1: Cloud NAT
Cloud NAT provides internet access for private instances, not VPN routing.
Trap 2: VPC peering
VPC peering connects two VPCs, not on-premises to VPC.
Trap 3: VPC Flow Logs
Flow Logs record traffic metadata, not routing.
- A
Cloud NAT
Why wrong: Cloud NAT provides internet access for private instances, not VPN routing.
- B
VPC peering
Why wrong: VPC peering connects two VPCs, not on-premises to VPC.
- C
Cloud Router
Cloud Router manages BGP sessions for dynamic routing with VPN or Interconnect.
- D
VPC Flow Logs
Why wrong: Flow Logs record traffic metadata, not routing.
A company is migrating on-premises DNS to Google Cloud. They have a hybrid network using Cloud VPN and want to resolve on-premises hostnames from Compute Engine instances without custom scripts. Which service should they use?
Trap 1: Create a forwarding zone in Cloud DNS and associate it with the VPC.
Forwarding zones resolve from GCP to other DNS servers; inbound server policy is needed for the reverse direction (GCP querying on-prem).
Trap 2: Enable Private Google Access on the VPC subnet.
Private Google Access allows instances to reach Google APIs and services, not on-premises DNS.
Trap 3: Configure Cloud NAT to forward DNS queries to on-premises DNS…
Cloud NAT does not support DNS forwarding; it provides outbound internet connectivity.
- A
Use Cloud DNS inbound server policy to forward queries to on-premises DNS.
Cloud DNS inbound server policy enables DNS queries from GCP to be forwarded to on-premises DNS servers via VPN or Interconnect.
- B
Create a forwarding zone in Cloud DNS and associate it with the VPC.
Why wrong: Forwarding zones resolve from GCP to other DNS servers; inbound server policy is needed for the reverse direction (GCP querying on-prem).
- C
Enable Private Google Access on the VPC subnet.
Why wrong: Private Google Access allows instances to reach Google APIs and services, not on-premises DNS.
- D
Configure Cloud NAT to forward DNS queries to on-premises DNS servers.
Why wrong: Cloud NAT does not support DNS forwarding; it provides outbound internet connectivity.
A network engineer is configuring a Cloud Router for BGP peering with an on-premises router over a VPN tunnel. The on-premises router uses 169.254.x.x link-local addresses. Which BGP peer IP should the engineer use in the Cloud Router configuration?
Trap 1: 10.0.0.1
Private IPs are not allowed for BGP over Cloud VPN; must use 169.254.x.x.
Trap 2: The tunnel's external IP address
The tunnel's external IP is used for the VPN, not for BGP peering.
Trap 3: The on-premises router's external IP address
External IPs are not used for BGP; BGP uses link-local addresses for the VPN.
- A
169.254.0.1
Google requires BGP peer IPs to be in the 169.254.0.0/16 range for Cloud VPN tunnels.
- B
10.0.0.1
Why wrong: Private IPs are not allowed for BGP over Cloud VPN; must use 169.254.x.x.
- C
The tunnel's external IP address
Why wrong: The tunnel's external IP is used for the VPN, not for BGP peering.
- D
The on-premises router's external IP address
Why wrong: External IPs are not used for BGP; BGP uses link-local addresses for the VPN.
A company uses Cloud NAT to allow private instances to reach the internet. They notice that egress traffic from Compute Engine VMs is intermittently failing. The VMs are in us-central1-a and use the default VPC network. Cloud NAT is configured with a single NAT IP address. What is the most likely cause?
Trap 1: Missing default route to Internet gateway
Default VPC has a default route.
Trap 2: Cloud NAT not configured in the correct region
Cloud NAT is regional; VMs in us-central1-a are in the same region.
Trap 3: Firewall rule blocking egress traffic from VM
Default VPC allows egress; no evidence of custom rules.
- A
Missing default route to Internet gateway
Why wrong: Default VPC has a default route.
- B
Port exhaustion due to insufficient NAT IP addresses
A single NAT IP provides limited ports; many VMs can exhaust them.
- C
Cloud NAT not configured in the correct region
Why wrong: Cloud NAT is regional; VMs in us-central1-a are in the same region.
- D
Firewall rule blocking egress traffic from VM
Why wrong: Default VPC allows egress; no evidence of custom rules.
Match each VPC networking concept to its definition.
Drag a concept onto its matching description — or click a concept then click the description.
Regional IP range within a VPC
Connection between two VPCs for private IP communication
VPC from one project shared with other projects
Outbound internet access for private instances
Access Google APIs from on-premises or other clouds
Drag and drop the steps to troubleshoot a VPN tunnel that is not passing traffic into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
A company has a VPC with subnets in us-east1 and europe-west1. They have deployed a global external HTTP(S) load balancer with backend services in both regions. Users in Europe report high latency. What is the most likely cause?
Trap 1: Incorrect health check configuration causing backends to be marked…
Would cause errors, not high latency.
Trap 2: Firewall rules blocking traffic from the load balancer's health…
Health checks are separate from user traffic.
Trap 3: The load balancer is not enabled for global access
Global load balancer is global by default.
- A
Incorrect health check configuration causing backends to be marked unhealthy
Why wrong: Would cause errors, not high latency.
- B
Firewall rules blocking traffic from the load balancer's health check probes
Why wrong: Health checks are separate from user traffic.
- C
The load balancer is not enabled for global access
Why wrong: Global load balancer is global by default.
- D
Session affinity set to CLIENT_IP, causing sticky sessions to a distant backend
Traffic might be pinned to us-east1 even for European users.
A company uses an internal TCP/UDP load balancer to distribute traffic to a backend service. The backend instances are in an unmanaged instance group. Some instances fail health checks and are removed. What happens to existing connections to failed instances?
Trap 1: The load balancer drains existing connections before removing the…
Internal TCP/UDP load balancers do not support connection draining.
Trap 2: Existing connections are seamlessly redirected to healthy instances.
The load balancer does not maintain session state for existing connections after instance removal.
Trap 3: The load balancer waits for all existing connections to close…
The load balancer removes the instance immediately without waiting.
- A
The load balancer drains existing connections before removing the instance.
Why wrong: Internal TCP/UDP load balancers do not support connection draining.
- B
Existing connections are seamlessly redirected to healthy instances.
Why wrong: The load balancer does not maintain session state for existing connections after instance removal.
- C
Existing connections are terminated immediately.
Internal TCP/UDP load balancers do not provide connection draining; connections are dropped.
- D
The load balancer waits for all existing connections to close before removing the instance.
Why wrong: The load balancer removes the instance immediately without waiting.
An organization has multiple VPCs in Google Cloud that need to communicate with an on-premises network through a single Dedicated Interconnect. All VPCs are in the same project. What is the most efficient way to enable connectivity from all VPCs to on-premises?
Trap 1: Create a separate Interconnect for each VPC
This is costly and inefficient; a single Interconnect can serve multiple VPCs.
Trap 2: Create a single VLAN attachment and use it for all VPCs
A VLAN attachment can only be attached to one VPC.
Trap 3: Use VPC Network Peering to connect VPCs and attach one VPC to…
Peering does not support transitive routing for Interconnect.
- A
Create a separate Interconnect for each VPC
Why wrong: This is costly and inefficient; a single Interconnect can serve multiple VPCs.
- B
Create a single VLAN attachment and use it for all VPCs
Why wrong: A VLAN attachment can only be attached to one VPC.
- C
Create a Cloud Router per VPC, each with its own VLAN attachment on the same Interconnect
Each VPC gets its own Cloud Router and VLAN attachment, allowing all to use the same Interconnect.
- D
Use VPC Network Peering to connect VPCs and attach one VPC to Interconnect
Why wrong: Peering does not support transitive routing for Interconnect.
A startup wants to create a VPC with a subnet that can grow automatically as they add more VM instances. Which subnet type should they use?
Trap 1: Custom mode subnet
Custom mode gives full control but requires manual range expansion.
Trap 2: Dynamic subnet
No such subnet mode exists in Google Cloud.
Trap 3: Legacy network
Legacy networks are deprecated and not recommended.
- A
Custom mode subnet
Why wrong: Custom mode gives full control but requires manual range expansion.
- B
Dynamic subnet
Why wrong: No such subnet mode exists in Google Cloud.
- C
Legacy network
Why wrong: Legacy networks are deprecated and not recommended.
- D
Auto mode subnet
Auto mode subnets automatically allocate IP ranges and expand as needed.
A company is deploying a multi-tier web application on Google Cloud. The web tier must be accessible from the internet, while the application tier should only be accessible from the web tier. The database tier must not have any public IP addresses. Which VPC design should be used?
Trap 1: Use a Shared VPC with separate subnets in different projects for…
Shared VPC is for multi-project environments, not for tier isolation within one organization.
Trap 2: Use a single VPC and connect the database tier via Cloud VPN to…
Cloud VPN does not address isolation between tiers within a VPC.
Trap 3: Use a single VPC with separate subnets for each tier and configure…
Single VPC does not provide network isolation at the VPC level; firewall rules alone can be misconfigured.
- A
Use a Shared VPC with separate subnets in different projects for each tier.
Why wrong: Shared VPC is for multi-project environments, not for tier isolation within one organization.
- B
Use three separate VPCs for each tier and connect them using VPC peering.
Separate VPCs provide full isolation; peering allows controlled communication.
- C
Use a single VPC and connect the database tier via Cloud VPN to on-premises.
Why wrong: Cloud VPN does not address isolation between tiers within a VPC.
- D
Use a single VPC with separate subnets for each tier and configure firewall rules to restrict traffic.
Why wrong: Single VPC does not provide network isolation at the VPC level; firewall rules alone can be misconfigured.
A developer created a Compute Engine instance in the default VPC network. The instance needs to communicate with an on-premises server over a Cloud VPN tunnel. The developer configured the VPN tunnel but the instances cannot ping the on-premises server. What is the most likely cause?
Trap 1: The subnet IP range overlaps with the on-premises network.
Default VPC uses Auto mode subnets with non-overlapping ranges; overlap is unlikely but would cause routing issues, not firewall.
Trap 2: The instance has IP forwarding disabled.
IP forwarding is required only for instances acting as routers, not for general communication.
Trap 3: The default VPC does not have a default route to the internet.
Default VPC has a default route (0.0.0.0/0) to the internet via the default internet gateway.
- A
The subnet IP range overlaps with the on-premises network.
Why wrong: Default VPC uses Auto mode subnets with non-overlapping ranges; overlap is unlikely but would cause routing issues, not firewall.
- B
The instance has IP forwarding disabled.
Why wrong: IP forwarding is required only for instances acting as routers, not for general communication.
- C
The default VPC does not have a default route to the internet.
Why wrong: Default VPC has a default route (0.0.0.0/0) to the internet via the default internet gateway.
- D
The firewall rules in the VPC are blocking ingress traffic from the on-premises network.
Default firewall rules allow only certain ingress; ICMP from on-premises is not allowed by default.
An organization has a VPC with custom mode subnets in us-central1 and europe-west1. They create a VM instance in us-central1 with an internal IP 10.0.1.2 and a VM in europe-west1 with internal IP 10.0.2.2. They want to enable communication between these instances using internal IPs. What must be configured?
Trap 1: Set up VPC peering between the two regions.
VPC peering is used between separate VPCs, not within the same VPC.
Trap 2: No additional configuration is needed because internal IPs are…
While internal IPs are routable, firewall rules must permit the traffic. Default rules allow it, but if custom rules are applied, they may block it.
Trap 3: Enable Cloud NAT for the VPC.
Cloud NAT is for internet access, not internal communication.
- A
Ensure the VPC firewall rules allow ingress from the source subnet or instance.
Firewall rules control traffic within a VPC; by default, all internal traffic is allowed, but custom rules could block it.
- B
Set up VPC peering between the two regions.
Why wrong: VPC peering is used between separate VPCs, not within the same VPC.
- C
No additional configuration is needed because internal IPs are routable within the VPC.
Why wrong: While internal IPs are routable, firewall rules must permit the traffic. Default rules allow it, but if custom rules are applied, they may block it.
- D
Enable Cloud NAT for the VPC.
Why wrong: Cloud NAT is for internet access, not internal communication.
A company has deployed a global application on Compute Engine instances in multiple regions. Users are experiencing high latency connecting to the application. The network team wants to use Google Cloud's global network to improve performance. Which approach should they take?
Trap 1: Use Cloud DNS with geo-routing to direct users to regional load…
DNS-based routing does not provide the performance of proximity-based anycast on Google's network; it also has caching issues.
Trap 2: Set up Cloud NAT with multiple static IP addresses for each region.
Cloud NAT is for outbound traffic only, not for inbound user traffic.
Trap 3: Assign a global anycast IP address to all instances and use BGP to…
Global anycast IP addresses are not supported in Google Cloud for direct instance assignment; BGP advertising is not possible.
- A
Deploy a global HTTP(S) Load Balancer with backend services in each region.
Global HTTP(S) LB uses anycast IP and proxies traffic to the closest region, reducing latency.
- B
Use Cloud DNS with geo-routing to direct users to regional load balancers.
Why wrong: DNS-based routing does not provide the performance of proximity-based anycast on Google's network; it also has caching issues.
- C
Set up Cloud NAT with multiple static IP addresses for each region.
Why wrong: Cloud NAT is for outbound traffic only, not for inbound user traffic.
- D
Assign a global anycast IP address to all instances and use BGP to advertise it.
Why wrong: Global anycast IP addresses are not supported in Google Cloud for direct instance assignment; BGP advertising is not possible.
A company is designing a VPC for a production environment that must meet the following requirements: support multiple projects, centralized network administration, and allow each project to have its own firewall rules. Which THREE components should be used?
Trap 1: Cloud VPN
Cloud VPN is for connecting on-premises, not for multi-project VPC.
Trap 2: VPC peering
VPC peering is not needed when using Shared VPC.
- A
Service projects
Service projects consume Shared VPC networks.
- B
Host project
The host project contains the Shared VPC network.
- C
Cloud VPN
Why wrong: Cloud VPN is for connecting on-premises, not for multi-project VPC.
- D
VPC peering
Why wrong: VPC peering is not needed when using Shared VPC.
- E
Shared VPC
Shared VPC enables centralized network management across projects.
A company is designing a network for a critical application that requires sub-millisecond latency between two Compute Engine instances. The instances are located in different zones within the same region. Which VPC configuration will provide the lowest latency?
Trap 1: Use VPC Network Peering between two different VPCs.
Peering adds a slight overhead; same VPC is better.
Trap 2: Place instances in different VPCs and use a VPN between them.
VPN adds encryption overhead and extra latency.
Trap 3: Assign external IP addresses to both instances and communicate over…
External IPs traverse the internet gateway, increasing latency.
- A
Use VPC Network Peering between two different VPCs.
Why wrong: Peering adds a slight overhead; same VPC is better.
- B
Place instances in different VPCs and use a VPN between them.
Why wrong: VPN adds encryption overhead and extra latency.
- C
Place both instances in the same VPC, using internal IP addresses.
Internal IPs stay within Google's network, providing lowest latency.
- D
Assign external IP addresses to both instances and communicate over the internet.
Why wrong: External IPs traverse the internet gateway, increasing latency.
A company has a VPC with multiple subnets. They want to restrict traffic between two subnets (Subnet-A and Subnet-B) using VPC firewall rules. Which THREE conditions must be met for a firewall rule to block traffic from Subnet-A to Subnet-B?
Trap 1: The rule must be applied using network tags on instances in…
Tags are optional; the rule can also apply to all instances in the subnet via target tags or service accounts.
Trap 2: The rule must also allow return traffic from Subnet-B to Subnet-A.
Firewall rules are stateless; return traffic is not automatically allowed; separate rules are needed.
- A
The rule must be applied using network tags on instances in Subnet-A.
Why wrong: Tags are optional; the rule can also apply to all instances in the subnet via target tags or service accounts.
- B
The rule must be an ingress rule with source set to Subnet-A IP range and destination set to Subnet-B IP range.
To block traffic from A to B, the ingress rule on Subnet-B must block source A.
- C
The rule must have action set to 'deny' and apply to all instances in Subnet-B.
The rule must deny traffic and target the destination subnet instances.
- D
The rule must also allow return traffic from Subnet-B to Subnet-A.
Why wrong: Firewall rules are stateless; return traffic is not automatically allowed; separate rules are needed.
- E
The rule must have a lower priority number (higher priority) than any allow rules between the subnets.
Priority numbers: lower number = higher priority. Deny rules must outrank allow rules.
Your company has deployed a hybrid cloud environment with a Cloud VPN tunnel between Google Cloud VPC and an on-premises data center. The VPC has a custom mode with subnet 10.0.1.0/24 in us-east1. On-premises uses subnet 192.168.1.0/24. The VPN tunnel is established using dynamic routing (BGP). Both sides advertise the correct prefixes. A Compute Engine VM in the VPC (10.0.1.10) can ping the on-premises gateway (192.168.1.1), but cannot ping a server on-premises (192.168.1.100). The on-premises network team confirms that 192.168.1.100 is reachable from the on-premises gateway. Firewall rules in GCP allow ingress from 192.168.1.0/24 to all VMs. What is the most likely cause?
Trap 1: The on-premises server is not configured with a default gateway…
If the server had no default gateway, it wouldn't be able to reach the on-premises gateway either.
Trap 2: The Cloud VPN tunnel is not configured with an IKE version…
The tunnel is established (VM can ping on-premises gateway), so IKE configuration is fine.
Trap 3: A firewall rule on the GCP VPC is blocking ICMP traffic from…
The firewall rule allows ingress from the entire on-premises subnet, so this is not the cause.
- A
The on-premises router does not have a route for the GCP subnet (10.0.1.0/24) pointing to the VPN tunnel.
Without a return route, the on-premises server sends replies through the default route (likely internet), causing asymmetric routing and packet drop.
- B
The on-premises server is not configured with a default gateway pointing to the on-premises gateway.
Why wrong: If the server had no default gateway, it wouldn't be able to reach the on-premises gateway either.
- C
The Cloud VPN tunnel is not configured with an IKE version supported by the on-premises device.
Why wrong: The tunnel is established (VM can ping on-premises gateway), so IKE configuration is fine.
- D
A firewall rule on the GCP VPC is blocking ICMP traffic from 192.168.1.100.
Why wrong: The firewall rule allows ingress from the entire on-premises subnet, so this is not the cause.
A company is designing a hybrid network using Dedicated Interconnect. They want to configure BGP for load balancing across multiple VLAN attachments. Which TWO statements are correct?
Trap 1: You must create a separate Cloud Router for each VLAN attachment.
A single Cloud Router can manage multiple VLAN attachments.
Trap 2: You should use BGP MED to load balance outbound traffic from Google…
MED influences inbound traffic; for outbound, you use AS path prepending or weight.
Trap 3: Load balancing across VLAN attachments requires a single BGP…
Load balancing requires multiple BGP sessions, one per VLAN attachment.
- A
You must create a separate Cloud Router for each VLAN attachment.
Why wrong: A single Cloud Router can manage multiple VLAN attachments.
- B
You can configure the Cloud Router to advertise the same IP prefixes over both VLAN attachments.
Advertising the same prefixes over multiple VLANs enables load balancing.
- C
You should use BGP MED to load balance outbound traffic from Google Cloud.
Why wrong: MED influences inbound traffic; for outbound, you use AS path prepending or weight.
- D
You can use the same BGP ASN for both VLAN attachments.
It is common to use the same ASN for multiple BGP sessions on the same Cloud Router.
- E
Load balancing across VLAN attachments requires a single BGP session.
Why wrong: Load balancing requires multiple BGP sessions, one per VLAN attachment.
A network engineer configured a Cloud Router with the BGP configuration shown. The on-premises router (AS 64512) is peering with the Cloud Router (AS 65001) over a Dedicated Interconnect VLAN attachment. The engineer notices that traffic from on-premises to Google Cloud is not being routed via this interconnect as expected. What is the most likely cause?
Exhibit
Refer to the exhibit. ``` # Cloud Router BGP configuration router bgp 65001 neighbor 169.254.0.1 remote-as 64512 neighbor 169.254.0.1 ebgp-multihop 2 neighbor 169.254.0.1 update-source loopback0 address-family ipv4 unicast neighbor 169.254.0.1 route-map SET-MED in neighbor 169.254.0.1 route-map SET-LOCAL-PREF out ! route-map SET-MED permit 10 set metric 100 ! route-map SET-LOCAL-PREF permit 10 set local-preference 200 ```
Trap 1: The route-map SET-MED sets the MED attribute incorrectly
MED is valid for eBGP, but the issue is the peering not working.
Trap 2: The ebgp-multihop 2 command is not supported on Cloud Router
Cloud Router supports ebgp-multihop, but it is unnecessary for directly connected peers.
Trap 3: The local-preference is set in the outbound direction, which is not…
Local preference can be set outbound to influence routes sent to on-premises, but not the root cause.
- A
The route-map SET-MED sets the MED attribute incorrectly
Why wrong: MED is valid for eBGP, but the issue is the peering not working.
- B
The ebgp-multihop 2 command is not supported on Cloud Router
Why wrong: Cloud Router supports ebgp-multihop, but it is unnecessary for directly connected peers.
- C
The update-source loopback0 command is invalid for Cloud Router BGP sessions
Cloud Router requires the BGP session to use the link-local IP address, not a loopback.
- D
The local-preference is set in the outbound direction, which is not allowed
Why wrong: Local preference can be set outbound to influence routes sent to on-premises, but not the root cause.
An organization is using Cloud VPN with dynamic routing and wants to improve failover time between two VPN tunnels. Which THREE configuration changes can help reduce failover time?
Trap 1: Increase the BGP keepalive interval to reduce overhead
Increasing keepalive interval would increase failover detection time.
Trap 2: Add static routes with a higher priority than BGP routes
Static routes would not dynamically failover with BGP.
- A
Set a lower BGP MED value on the primary tunnel
Lower MED makes the primary path preferred, allowing faster fallback.
- B
Increase the BGP keepalive interval to reduce overhead
Why wrong: Increasing keepalive interval would increase failover detection time.
- C
Configure BGP timers with lower values for faster detection
Lower BGP timers reduce the time to detect a failure.
- D
Add static routes with a higher priority than BGP routes
Why wrong: Static routes would not dynamically failover with BGP.
- E
Use multiple VPN tunnels with equal BGP metrics
Multiple tunnels provide redundancy and load balancing.
A company has a VPC with multiple subnets. They want to restrict traffic between two specific subnets (10.0.1.0/24 and 10.0.2.0/24) while allowing all other traffic. They create a firewall rule with priority 1000 denying ingress from 10.0.1.0/24 to 10.0.2.0/24. However, traffic is still allowed. What is the most likely reason?
Trap 1: The rule is incorrectly applied to the wrong network tag
Rule applies to subnet ranges, not tags.
Trap 2: The traffic is going through the metadata server
Metadata server is a different IP.
Trap 3: Firewall rules are stateless, so return traffic is blocked
Firewall rules are stateful; return traffic is allowed.
- A
The rule is incorrectly applied to the wrong network tag
Why wrong: Rule applies to subnet ranges, not tags.
- B
The traffic is going through the metadata server
Why wrong: Metadata server is a different IP.
- C
There is a higher priority allow rule that matches the traffic
Higher priority allow rule can override deny.
- D
Firewall rules are stateless, so return traffic is blocked
Why wrong: Firewall rules are stateful; return traffic is allowed.
Which TWO considerations are important when designing a VPC peering strategy between multiple projects in Google Cloud?
Trap 1: Peering is transitive by default
Peering is not transitive unless route exchange is enabled.
Trap 2: Firewall rules in one VPC automatically apply to peered VPCs
Firewall rules are not shared via peering.
Trap 3: VPC peering can only be used within the same project
Cross-project peering is supported.
- A
Peering is transitive by default
Why wrong: Peering is not transitive unless route exchange is enabled.
- B
Subnet IP ranges in peered VPCs must not overlap
Overlapping ranges cause routing issues.
- C
Firewall rules in one VPC automatically apply to peered VPCs
Why wrong: Firewall rules are not shared via peering.
- D
VPC peering can only be used within the same project
Why wrong: Cross-project peering is supported.
- E
Custom routes can be exchanged between peered VPCs if configured
You can export custom routes.
You have a Cloud Router with the configuration shown. The on-premises network (ASN 65002) is not receiving any routes from Google Cloud. What is the most likely cause?
Exhibit
Refer to the exhibit.
```
$ gcloud compute routers describe my-router --region us-central1
creationTimestamp: '2023-01-15T10:00:00.000-08:00'
description: Router for on-prem connectivity
id: '1234567890123456789'
kind: compute#router
name: my-router
network: https://www.googleapis.com/compute/v1/projects/my-project/global/networks/default
region: https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1
bgp:
asn: 65001
advertiseMode: CUSTOM
advertisedGroups:
- ALL_SUBNETS
advertisedIpRanges:
- range: 10.0.1.0/24
description: On-prem subnet
keepaliveInterval: 20
```Trap 1: The BGP keepalive interval is set too low
20 seconds is standard.
Trap 2: The BGP session is not established
Session might be up but no routes because of custom mode.
Trap 3: The on-premises subnet 10.0.1.0/24 is not advertised
It is advertised in custom mode.
- A
The BGP keepalive interval is set too low
Why wrong: 20 seconds is standard.
- B
The BGP session is not established
Why wrong: Session might be up but no routes because of custom mode.
- C
The router is in custom advertise mode but does not advertise the VPC subnets
Custom mode overrides default; must explicitly advertise VPC subnets.
- D
The on-premises subnet 10.0.1.0/24 is not advertised
Why wrong: It is advertised in custom mode.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.