Google Cloud Professional Cloud Network Engineer Practice Exam

What the Google Cloud Professional Cloud Network Engineer exam covers

• Designing and planning a Google Cloud VPC network154 questions
• Implementing a VPC network168 questions
• Configuring managed network services174 questions
• Configuring and implementing hybrid and multicloud network interconnectivity138 questions
• Managing, monitoring, and troubleshooting network operations156 questions
• Configuring, implementing and managing a cloud network security solution113 questions

Free Google Cloud Professional Cloud Network Engineer practice test questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 903.

1. Question 1Designing and planning a Google Cloud VPC network

   What is the scope of a Google Cloud VPC network and its subnets?

   • AThe VPC is regional; subnets are zonal
   • BThe VPC is global; subnets are regionalCorrect
   • CBoth are zonal
   • DBoth are global
   ✓ Correct answer: B

   In Google Cloud, a VPC network is a global resource - it spans all regions and zones automatically. Subnets, however, are regional resources and each subnet's IP range is tied to a specific region. VMs in any zone within a region can use subnets from that region, which allows cross-zone communication within a single subnet without any extra configuration.

   Why the other options are wrong

   • AA regional VPC with zonal subnets describes an AWS-style model, not Google Cloud - GCP VPCs are global resources and subnets are regional, not zonal.
   • CZonal scope applies to individual resources like VM instances and persistent disks, not to VPC networks or their subnets.
   • DSubnets are regional, not global - each subnet is scoped to a single region and carries a CIDR range bound to that region.
2. Question 2Managing, monitoring, and troubleshooting network operations

   After enabling Cloud CDN, you want to confirm it is actually reducing origin load and improving performance. Which signal best demonstrates this?

   • ACloud Monitoring/Cloud CDN cache hit ratio and origin request count metricsCorrect
   • BThe total ingress bytes counter on the VPC's Cloud Router interfaces
   • CThe number of managed zones and record sets configured in Cloud DNS
   • DThe count of firewall rules and their hit counts in the VPC network
   ✓ Correct answer: A

   Cloud CDN publishes cache_hit_count, cache_miss_count, and origin request metrics to Cloud Monitoring. A rising cache hit ratio alongside a falling origin request count confirms the CDN is absorbing requests and reducing origin load - the direct operational signals of CDN effectiveness.

   Why the other options are wrong

   • BCloud Router interface byte counters measure BGP/route traffic, not edge cache behavior, so they cannot show CDN origin offload.
   • CCloud DNS zone and record counts are name-resolution configuration and reveal nothing about cache hit ratio or origin load.
   • DFirewall rule counts and hit counts reflect security policy activity, not CDN caching or the requests saved at the origin.
3. Question 3Managing, monitoring, and troubleshooting network operations

   In Network Intelligence Center, you want continuous monitoring of packet loss and latency between Google Cloud zones and to the internet. Which module do you use?

   • ACloud Armor security policies, which continuously chart the packet loss and latency between Google Cloud zones and out to the public internet
   • BCloud CDN cache analytics, which report ongoing packet-loss and latency measurements across zones and to internet destinations for the project
   • CPerformance Dashboard, which surfaces Google-wide and project-level latency/packet-loss metricsCorrect
   • DConnectivity Tests, which run only on-demand configuration analysis and do not continuously monitor latency or packet loss between zones
   ✓ Correct answer: C

   Network Intelligence Center's Performance Dashboard provides continuous, always-on visibility into packet loss and round-trip latency across Google's network, covering inter-zone, inter-region, and internet paths. It surfaces both Google-wide baselines and project-level telemetry so you can distinguish whether a latency spike is a global Google issue or specific to your project's resources. Connectivity Tests, by contrast, are on-demand configuration analyses rather than continuous time-series monitors.

   Why the other options are wrong

   • ACloud Armor is a WAF and DDoS edge security service; it does not measure inter-zone or internet latency and packet loss.
   • BCloud CDN analytics report cache hit ratios and egress, not network latency or packet loss between zones and the internet.
   • DConnectivity Tests do on-demand config analysis and optional probes, but they are not the continuous latency and packet-loss monitor; that is the Performance Dashboard.
4. Question 4Configuring managed network services

   An internal passthrough Network Load Balancer in us-east1 is unreachable from clients in europe-west1 within the same VPC. The backends are healthy. Why?

   • AThe VPC must be in auto-mode for cross-region internal load balancer access, and custom-mode blocks the europe-west1 clients
   • BThe europe-west1 clients need external IP addresses assigned before they can connect to the internal load balancer VIP
   • CCloud CDN must be enabled on the internal passthrough Network Load Balancer before other-region clients can reach the VIP
   • DInternal passthrough Network Load Balancers are regional, so cross-region access requires global access to be enabled or a regional clientCorrect
   ✓ Correct answer: D

   An internal passthrough Network Load Balancer (formerly Internal TCP/UDP LB) is a regional resource - its forwarding rule and backend instances exist in a single region, and by default only clients in the same region can access it. Clients in other regions within the same VPC will fail to reach it unless the 'global access' option is explicitly enabled on the forwarding rule, which allows clients from all regions in the same VPC to send traffic to the regional ILB.

   Why the other options are wrong

   • AAuto-mode versus custom-mode does not control cross-region ILB access; global access on the ILB does, so VPC mode is irrelevant here.
   • BInternal load balancers are reached over internal addresses, so external IPs on clients are neither required nor a fix for cross-region access.
   • CCloud CDN applies to external HTTP load balancers and cannot be enabled on an internal passthrough NLB or extend its regional reach.
5. Question 5Designing and planning a Google Cloud VPC network

   An enterprise already runs a Dedicated Interconnect carrying unencrypted traffic. A new regulation requires that all traffic over that physical link be encrypted at Layer 2 without changing the IP addressing or routing design. Which design satisfies the requirement?

   • AEnable MACsec on the Dedicated Interconnect connectionCorrect
   • BWrap all traffic in a Classic VPN tunnel inside the VPC
   • CSwitch to Partner Interconnect, which is encrypted by default
   • DEnable Private Google Access on the on-prem subnets
   ✓ Correct answer: A

   MACsec (IEEE 802.1AE) is a Layer 2 encryption standard supported natively on Dedicated Interconnect. Enabling it encrypts all traffic on the physical link transparently, with no changes to IP addressing, routing, or BGP sessions. That directly meets a Layer 2 encryption mandate over the existing Interconnect.

   Why the other options are wrong

   • BA Classic VPN tunnel operates at Layer 3 (IPsec), changing encapsulation and MTU, so it does not satisfy a Layer 2 mandate cleanly.
   • CPartner Interconnect is not encrypted by default; encryption must still be configured, and switching products means re-provisioning connectivity.
   • DPrivate Google Access lets VMs without external IPs reach Google APIs; it provides no encryption on the Interconnect physical link.
6. Question 6Implementing a VPC network

   A growing GKE cluster is approaching exhaustion of its Pod IP range, blocking new nodes from being added. You must increase Pod capacity without recreating the cluster. Which action is supported?

   • AAdd an additional Pod IP range to the cluster as a discontiguous multi-Pod-CIDR secondary rangeCorrect
   • BResize the existing Pod secondary range by editing the subnet's primary CIDR
   • CDelete the Service range and reassign its addresses to Pods
   • DSwitch the cluster from VPC-native to routes-based mode to free Pod IPs
   ✓ Correct answer: A

   GKE supports adding additional Pod IP ranges (multi-Pod-CIDR) to an existing VPC-native cluster without recreating it. These additional ranges can be discontiguous secondary ranges added to the subnet, and the cluster is updated to use them for new node pools or when existing node pools need more Pod IPs. This allows gradual capacity expansion without the disruption of cluster recreation. Existing nodes continue using their current ranges while new nodes can draw IPs from the newly added range.

   Why the other options are wrong

   • BYou cannot resize an existing secondary range for Pods by editing the subnet's primary CIDR; primary CIDR changes follow different expansion rules, and the Pod range is a secondary range - secondary ranges can be expanded within limits but the primary CIDR is unrelated.
   • CDeleting the Service range and reassigning its addresses to Pods would break all Kubernetes Services (ClusterIPs), causing widespread cluster failure; Service and Pod ranges serve distinct purposes and cannot be merged.
   • DSwitching from VPC-native to routes-based mode is not a supported in-place migration; VPC-native is the default and preferred mode, and routes-based mode has its own Pod IP limitations through per-node static routes.
7. Question 7Configuring managed network services

   A security team wants to copy ingress and egress traffic from selected VMs to an out-of-band intrusion detection and forensic tool without inserting any device into the data path. Which Google Cloud feature should they use?

   • APacket Mirroring, which clones full packet copies from selected instances to a collector destination behind an internal load balancerCorrect
   • BVPC Flow Logs, which continuously capture the full packet payloads of selected instances at the configured flow sampling rate
   • CCloud NGFW Enterprise inline IPS running in blocking mode so that suspicious flows are inspected and dropped in the data path
   • DFirewall Rules Logging configured with metadata set to INCLUDE_ALL so that full copies of matched packets are exported for analysis
   ✓ Correct answer: A

   Packet Mirroring is a Google Cloud feature that creates full copies of ingress and egress packets from selected VM instances or subnets and forwards those copies to a collector - typically an IDS tool or forensic appliance sitting behind an internal passthrough Network Load Balancer. Because the mirroring is performed at the hypervisor level, no device is inserted into the live data path, and the monitored workloads see no latency impact or traffic disruption.

   Why the other options are wrong

   • BVPC Flow Logs capture sampled flow metadata, not full packet payloads, so they cannot feed a forensic tool with complete traffic copies.
   • CInline IPS in blocking mode inserts a device into the data path, which the requirement explicitly forbids.
   • DFirewall Rules Logging records connection metadata about rule matches, not full packet copies for an IDS collector.
8. Question 8Managing, monitoring, and troubleshooting network operations

   After a recent change, on-premises systems can no longer reach a VPC subnet over Partner Interconnect even though the VLAN attachment is active and the BGP session is established. You verified firewall rules allow the traffic. Which Cloud Router configuration is the most likely cause that on-premises is not learning the subnet's prefix?

   • AThe Cloud Router's advertised route configuration uses a custom list that omits the affected subnet's rangeCorrect
   • BVPC Flow Logs are disabled on the affected subnet, which prevents its prefix from being advertised to the on-prem peer
   • CCloud NAT is not configured for the affected subnet, so its route is never announced across the Partner Interconnect
   • DThe Cloud DNS private zone for the affected subnet is missing, so on-prem cannot resolve or route to that prefix
   ✓ Correct answer: A

   The most likely cause is that the Cloud Router uses a custom advertised-route list that omits the affected subnet's range. With custom (not default) route advertisement, only the explicitly listed prefixes are advertised over BGP to on-premises, so a subnet missing from the list will never be learned even though the VLAN attachment and BGP session are up and firewall rules permit the traffic.

   Why the other options are wrong

   • BVPC Flow Logs only record traffic metadata and have no role in whether a subnet prefix is advertised over BGP.
   • CCloud NAT provides egress translation and is unrelated to advertising subnet routes to the on-prem peer.
   • DA missing Cloud DNS private zone affects name resolution, not the BGP advertisement of the subnet's route.
9. Question 9Configuring managed network services

   Behind a global external Application Load Balancer, one backend instance in a managed instance group is intermittently returning HTTP 503s under load, degrading overall latency even though health checks still pass. You want the load balancer to temporarily eject that misbehaving endpoint based on observed error rates and gradually return it. Which advanced traffic-management feature should you configure on the backend service?

   • AOutlier detection (consecutive 5xx / error-percentage ejection) on the backend service.Correct
   • BA stricter HTTP health check with a 1-second interval to fail the endpoint faster.
   • CSession affinity set to GENERATED_COOKIE to pin users away from the bad backend.
   • DConnection draining with a 300-second timeout on the backend service.
   ✓ Correct answer: A

   Outlier detection is part of advanced traffic management on global external Application Load Balancers. It tracks per-endpoint behavior such as consecutive gateway errors or 5xx error percentage and ejects offending endpoints for a base ejection time that grows with repeated offenses, then returns them gradually. This handles the case where an endpoint passes health checks but still errors intermittently under real traffic, which a coarse health check may miss. Health-check tuning is reactive and binary, session affinity does the opposite (pins clients), and connection draining only governs graceful shutdown during removal.

   Why the other options are wrong

   • BAggressive health checks can cause flapping and still rely on the probe endpoint passing/failing rather than observed user-facing error rates.
   • CSession affinity pins clients to specific backends and would tend to keep some users stuck on the failing instance, not eject it.
   • DConnection draining only controls how in-flight connections are handled when a backend is removed or scaled down; it does not detect or eject misbehaving endpoints.
10. Question 10Configuring, implementing and managing a cloud network security solution

    You create an ingress allow rule for tcp:443 to a web server. A client establishes a connection, and the server sends response packets back. Do you also need an egress rule to permit those responses?

    • ANo, the firewall is stateful so responses are allowedCorrect
    • BYes, you must add an egress allow rule for the return traffic
    • COnly if an egress allow rule with a matching priority exists
    • DOnly after connection tracking is manually enabled on the rule
    ✓ Correct answer: A

    Because firewall rules are connection-tracking, once an ingress connection is allowed the return traffic for that same connection is permitted regardless of egress rules, and vice versa for allowed egress. You do not create separate rules for reply packets. This applies to VPC firewall rules and network firewall policies alike.

    Why the other options are wrong

    • BNo egress rule is needed, stateful tracking already permits the return traffic of the allowed connection.
    • CReply traffic is allowed without any matching egress rule, priority is irrelevant to it.
    • DConnection tracking is always on, there is no manual toggle to enable statefulness.

Who this Google Cloud Professional Cloud Network Engineer practice exam is for

This practice set is for anyone preparing for the Google Cloud Professional Cloud Network Engineer exam at the advanced level - from first-time candidates building a foundation to experienced Google practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.

How to use this Google Cloud Professional Cloud Network Engineer practice exam

1. Start with the free sample questions above to gauge your current baseline.
2. Read the full explanation on every question, including why each wrong option is wrong.
3. Track your weak domains and focus your study where you are losing the most marks.
4. Once you are scoring consistently well, take a timed, full-length mock exam.
5. Use your readiness score to decide when you are ready to book the real Google Cloud Professional Cloud Network Engineer exam.

Related Google resources

• Google Cloud Professional Cloud Network Engineer study guideKey concepts
• Google practice examsAll Google
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• How these questions are written and reviewedMethodology
• Report a problem with a questionCorrections
• Google Cloud Professional Cloud Security Engineer practice examRelated
• Google Cloud Professional Data Engineer practice examRelated
• Google Cloud Professional Machine Learning Engineer practice examRelated

Google Cloud Professional Cloud Network Engineer practice exam FAQ