Implementing a VPC network — PCNE Practice Quiz

Question 1

A development team deploys a Cloud Run service that must call a backend running on a Compute Engine VM addressed only by its internal RFC 1918 IP inside a custom-mode VPC. The team wants the lowest-latency egress path with the least infrastructure to manage and the ability to scale out without provisioning a fixed pool of connector instances. Which configuration should they choose?

Accepted Answer

Enable Direct VPC egress on the Cloud Run service, attaching it to the target subnet in the VPC

Answer

Create a Serverless VPC Access connector sized with a fixed min/max instance range and route egress through it

Answer

Configure a Private Service Connect endpoint pointing at the VM's internal IP and route Cloud Run traffic to it

Answer

Deploy Cloud NAT and set the Cloud Run service egress to route all traffic through the NAT gateway

Question 2

A data engineering team runs a Cloud Run service that must reach a Cloud SQL instance and several Compute Engine VMs over private IPs in a custom-mode VPC. The service experiences bursty traffic that occasionally spikes to very high sustained egress throughput, and the team wants to minimize the operational overhead of managing throughput-limited infrastructure while keeping traffic on internal IP addresses. Which egress configuration should they choose?

Accepted Answer

Use Direct VPC egress, assigning the Cloud Run service to a subnet in the VPC

Answer

Use a Serverless VPC Access connector sized with the largest available machine type and manual scaling

Answer

Route egress through a Cloud NAT gateway attached to the VPC so Cloud Run reaches the private resources

Answer

Enable Private Google Access on the target subnet and let Cloud Run connect automatically

Question 3

Your company uses Network Connectivity Center with a single hub to interconnect four VPCs as VPC spokes for full-mesh transitive connectivity. You attempt to attach a fifth VPC as a spoke, but the operation fails. Investigation shows this new VPC contains a subnet with the CIDR range 10.20.0.0/24, which is identical to a subnet already present in one of the existing spoke VPCs. What is the most appropriate action to successfully attach the fifth VPC as a spoke?

Accepted Answer

Re-IP the overlapping subnet in the fifth VPC to a non-overlapping range before attaching it as a spoke, because NCC VPC spokes require unique subnet ranges across all spokes on the hub.

Answer

Enable the 'export custom routes' setting on the hub so that overlapping ranges are automatically deduplicated during spoke attachment.

Answer

Attach the fifth VPC using a group with the 'auto_accept' policy, which allows overlapping subnets by installing longest-prefix-match routes.

Answer

Create a Cloud Router in the fifth VPC and use custom route priorities (MED) so the overlapping subnet is preferred only within its own VPC.

Question 4

Your security team requires that a set of Compute Engine instances in the 'restricted-vpc' custom-mode VPC have absolutely no direct path to the public internet, while still allowing them to reach Google APIs privately. Currently the VPC has the default 0.0.0.0/0 route pointing to the default internet gateway. The instances have no external IP addresses. What is the most effective way to guarantee these instances cannot egress to the internet through the default gateway while preserving private access to Google APIs?

Accepted Answer

Delete the default 0.0.0.0/0 route to the default internet gateway, enable Private Google Access on the relevant subnets, and add a route for restricted.googleapis.com via the default internet gateway.

Answer

Keep the default route but attach a network tag to the instances and create a deny-all egress firewall rule that blocks 0.0.0.0/0 for that tag.

Answer

Remove the external IP addresses from the instances and rely on the absence of Cloud NAT to prevent internet egress.

Answer

Lower the priority of the default internet gateway route to 65535 so that Private Google Access routes are always preferred.

Question 5

Your company runs a custom-mode VPC with many Compute Engine instances in the subnet 10.20.0.0/16. Most instances must send all internet-bound traffic through a self-managed NAT/firewall appliance (a VM with IP 10.20.1.10) for inspection. However, a small group of instances tagged 'direct-egress' must instead use the default internet gateway route for maximum throughput and bypass inspection. Both route types point to 0.0.0.0/0. How should you configure routing so that only the tagged instances bypass the appliance?

Accepted Answer

Create a custom static route for 0.0.0.0/0 with next hop the appliance VM and no tags, and create a second custom static route for 0.0.0.0/0 with the network tag 'direct-egress', next hop default internet gateway, and a lower (better) priority value.

Answer

Delete the default internet gateway route, then create a single tagged static route for 'direct-egress' instances pointing to the internet gateway; untagged instances will automatically fall back to the appliance.

Answer

Apply a hierarchical firewall policy that forces untagged instances through the appliance and allows tagged instances direct egress.

Answer

Configure Cloud NAT for the subnet and attach the 'direct-egress' tag to the NAT gateway so only tagged instances use it.

Question 6

Your company deployed a firewall virtual appliance in a VPC to inspect all egress traffic to the internet. You created a custom static route with destination 0.0.0.0/0 and next hop set to the appliance instance, with priority 1000. However, traffic from workload VMs is still bypassing the appliance and going directly to the internet via the default route. You need all workload VM egress to flow through the appliance while leaving other VMs unaffected. What should you do?

Accepted Answer

Create a new custom static route to 0.0.0.0/0 with next hop the appliance, set a priority value lower than 1000 (e.g., 100), and apply an instance tag that matches only the workload VMs.

Answer

Delete the default 0.0.0.0/0 internet gateway route so that the appliance route becomes the only default route in the VPC.

Answer

Increase the priority value of the existing appliance route to 2000 so it takes precedence over the default internet gateway route.

Answer

Add a network tag to the appliance instance and reference that tag in the existing route so only tagged traffic is forwarded.

Question 7

A network engineer manages a custom-mode VPC with a subnet named 'app-subnet' in us-central1 using primary range 10.20.0.0/24. The application team is deploying additional Compute Engine instances and has exhausted the available IP addresses. Existing VMs must keep their current IP addresses and stay online during the change. What should the engineer do to provide more usable IP addresses in this subnet?

Accepted Answer

Expand the subnet's primary IP range to a larger prefix, such as 10.20.0.0/22, using gcloud compute networks subnets expand-ip-range.

Answer

Delete and recreate 'app-subnet' with a larger CIDR block, then re-deploy the existing instances.

Answer

Add a secondary IP range to 'app-subnet' and configure the new VMs to draw primary interface IPs from the secondary range.

Answer

Create a new subnet in a different region with a larger range and migrate the workloads there.

Question 8

Your team runs a private GKE cluster where nodes have only internal IP addresses. Developers connect from the corporate office (public egress IP 203.0.113.10/32) using kubectl, and a CI/CD pipeline runs on a Compute Engine VM in the same VPC (internal IP 10.20.0.5). Security requires that the Kubernetes API server (control plane) reject connections from any source except these two. Which configuration meets the requirement with the least operational overhead?

Accepted Answer

Enable control plane authorized networks and add 203.0.113.10/32; enable the option to allow access from Google Cloud internal IP addresses (or add the VM's range), and keep the private endpoint enabled.

Answer

Create a VPC firewall rule denying ingress on port 443 to the control plane except from 203.0.113.10/32 and 10.20.0.5/32.

Answer

Add both 203.0.113.10/32 and 10.20.0.5/32 to a Cloud Armor security policy attached to the cluster's external load balancer.

Answer

Disable the public endpoint entirely and route all developer kubectl traffic through Cloud NAT to reach the private endpoint.

Question 9

A development team runs a Cloud Run service that must call a REST API hosted on a Compute Engine VM using the VM's internal IP address (10.20.0.15). The Cloud Run service currently cannot reach the VM. The team wants the simplest supported configuration that routes only the RFC 1918 internal traffic through the VPC while keeping public internet egress unchanged. What should you configure?

Accepted Answer

Create a Serverless VPC Access connector in the same region and VPC, then set the Cloud Run egress setting to route only requests to private IP ranges through the connector.

Answer

Set the Cloud Run egress setting to route all traffic through a Serverless VPC Access connector so that both internet and internal traffic use the VPC.

Answer

Assign an external IP to the Compute Engine VM and add a firewall rule allowing ingress from Cloud Run's public IP range.

Answer

Enable Private Google Access on the subnet containing the VM so that Cloud Run can reach the internal IP address.

Question 10

Your team is deploying an internal HTTP(S) load balancer to expose services running in a VPC-native GKE cluster within a custom-mode VPC in region us-central1. When you attempt to create the internal Application Load Balancer's forwarding rule, the operation fails with an error indicating that no proxy-only subnet exists. The cluster subnet has a primary range and two secondary ranges already configured for Pods and Services. What must you do to allow the internal Application Load Balancer to be provisioned?

Accepted Answer

Create a subnet with purpose REGIONAL_MANAGED_PROXY and role ACTIVE in us-central1, reserved exclusively for Envoy-based proxies.

Answer

Add a third secondary IP range to the existing cluster subnet and designate it as the proxy range.

Answer

Convert the VPC from custom mode to auto mode so that a proxy-only subnet is created automatically in each region.

Answer

Enable Private Google Access on the cluster subnet so the load balancer proxies can reach backend Pods.

Question 11

Your team runs a VPC-native GKE cluster with a Pod secondary range of 10.60.0.0/14. Pods must communicate with an on-premises database at 172.16.5.10 reachable over Cloud Interconnect. The on-premises firewall only permits traffic sourced from the cluster's node subnet (10.10.0.0/24). Currently, connections from Pods to the on-premises database are being dropped because the on-premises firewall sees the Pod IP addresses as the source. What is the correct way to resolve this while keeping intra-cluster and Google API traffic unmasqueraded?

Accepted Answer

Deploy the ip-masq-agent DaemonSet and configure a nonMasqueradeCIDRs list that includes the Pod, Service, and Google API ranges, so that only traffic to on-premises destinations is SNATed to the node IP.

Answer

Add a custom static route in the VPC directing 172.16.5.10/32 through the Cloud Router, which will automatically rewrite the Pod source addresses to the node subnet.

Answer

Enable Private Google Access on the node subnet so Pod traffic to on-premises is translated to the subnet's primary range.

Answer

Configure Cloud NAT for the Pod secondary range so that Pod egress to on-premises appears to come from the node subnet.

Question 12

Your company runs a multi-tenant GKE Standard cluster where several teams deploy workloads into the same cluster but in separate namespaces. Security has mandated that pods in the 'payments' namespace must only accept ingress traffic from pods in the 'frontend' namespace, and all other pod-to-pod traffic to 'payments' must be denied by default. The cluster currently has no traffic restrictions between pods. What should you do to enforce this requirement?

Accepted Answer

Enable Dataplane V2 (or Calico) network policy enforcement on the cluster, then create a Kubernetes NetworkPolicy in the 'payments' namespace with a default-deny ingress rule plus an allow rule selecting pods from the 'frontend' namespace.

Answer

Create VPC firewall rules that deny traffic between the pod IP ranges and add an allow rule for the frontend pod range, using network tags on the nodes.

Answer

Configure Google Cloud Armor security policies attached to the payments workload's internal load balancer to filter traffic by source namespace.

Answer

Place the 'payments' and 'frontend' workloads in separate node pools and rely on node-level firewall rules to isolate the payments node pool from all other pods.

Question 13

Your team deploys a private GKE cluster where nodes have only internal IP addresses. The application pods must pull container images from an external public registry (not Artifact Registry) and call a third-party payment API over the public internet. Cluster creation succeeds, but pods fail to pull the external images and cannot reach the payment API. What is the correct way to enable this outbound internet connectivity?

Accepted Answer

Configure Cloud NAT for the region and subnet used by the cluster so private nodes can initiate outbound connections to the internet.

Answer

Assign external IP addresses to the GKE nodes so they can reach the internet directly.

Answer

Enable Private Google Access on the node subnet to route the traffic to external endpoints.

Answer

Create a Private Service Connect endpoint targeting the external registry and payment API.

Question 14

Your team deployed a private GKE cluster with a private control plane endpoint. The control plane runs in a Google-managed VPC that is connected to your cluster's VPC using VPC Network Peering. Developers connecting from an on-premises data center over an HA VPN tunnel to your VPC report they cannot reach the private control plane endpoint, even though nodes in the cluster communicate with it successfully. What is the most likely cause and how should you resolve it?

Accepted Answer

The VPC peering with the control plane's Google-managed VPC does not export custom routes by default; enable custom route export on the peering so the on-premises VPN routes are advertised to the control plane.

Answer

The on-premises CIDR must be added to the cluster's authorized networks list, but private endpoint access from on-premises additionally requires custom route exchange on the peering to be disabled.

Answer

Private control plane endpoints only accept traffic from within the cluster's VPC; on-premises access is impossible and you must enable the public endpoint instead.

Answer

The HA VPN tunnel is advertising the wrong MED value, so Cloud Router is deprioritizing the control plane route; raise the tunnel priority to fix reachability.

Question 15

You are provisioning a new VPC-native GKE cluster in a subnet named 'prod-subnet' that currently has only a primary IP range of 10.0.0.0/24. The platform team requires that Pods and Services each use dedicated, non-overlapping alias IP ranges so that Pod IPs are individually routable within the VPC. What must you configure on the subnet before or during cluster creation to satisfy this requirement?

Accepted Answer

Add two secondary IP ranges to 'prod-subnet' and reference them as the Pod and Service ranges when creating the VPC-native cluster.

Answer

Enlarge the primary range of 'prod-subnet' to a /16 so that Pods and Services can allocate addresses from the same range.

Answer

Enable a routes-based cluster and let GKE create static routes for each node's Pod CIDR block automatically.

Answer

Create a separate subnet in a peered VPC and assign the Pod and Service ranges from that subnet using VPC Network Peering.

Question 16

Your team is deploying a new GKE cluster in a custom-mode VPC. Networking requirements state that Pod IPs must be natively routable within the VPC, that Pods must integrate with container-native load balancing using Network Endpoint Groups, and that the cluster should not consume the VPC's route table quota as it scales to thousands of nodes. Which cluster networking configuration meets all of these requirements?

Accepted Answer

A VPC-native cluster using alias IP ranges backed by a secondary range on the subnet

Answer

A routes-based cluster that creates a static route per node for Pod CIDRs

Answer

A routes-based cluster with IP masquerade enabled so Pod traffic uses node IPs

Answer

A VPC-native cluster with Pod IPs assigned from the subnet's primary range

Question 17

Your company operates four production VPCs (vpc-app, vpc-data, vpc-web, vpc-shared) in different projects that must all communicate with each other with full mesh connectivity. Currently they are connected using VPC Network Peering, but the team is frustrated because peering is non-transitive, requiring many individual peering connections that are hard to manage as VPCs are added. You need a managed solution that provides transitive full-mesh connectivity between all VPCs while minimizing operational overhead. What should you do?

Accepted Answer

Create a Network Connectivity Center hub and attach each of the four VPCs as VPC spokes so they exchange routes transitively.

Answer

Configure a hub-and-spoke topology by designating vpc-shared as a transit VPC and creating custom static routes in each VPC pointing to it.

Answer

Migrate all workloads into a single Shared VPC host project so no inter-VPC connectivity is required.

Answer

Deploy HA VPN tunnels between every pair of VPCs and enable BGP on Cloud Routers to exchange dynamic routes.

Question 18

Your company uses Network Connectivity Center with a single hub to connect four regional VPC spokes. Currently all spokes can communicate with each other in a full mesh. A new security requirement mandates that two of the spokes (spoke-C and spoke-D) must only be able to reach spoke-A (a shared services VPC) and must NOT be able to reach each other or spoke-B. You want to enforce this at the connectivity layer without deploying firewall appliances. What should you do?

Accepted Answer

Create a new Network Connectivity Center hub configured for star topology (topology is set at hub creation and cannot be changed in place), designating spoke-A as the center and spoke-C/spoke-D as edge spokes so they can only communicate with the center spoke.

Answer

Create a second Network Connectivity Center hub and move spoke-C and spoke-D to it, then peer the two hubs together.

Answer

Keep the mesh topology and rely on VPC Network Peering export/import route filtering between spoke-C, spoke-D, and spoke-B.

Answer

Add hierarchical firewall policies at the organization level that block traffic between spoke-C, spoke-D, and spoke-B.

Question 19

Your security team manages VPC firewall rules for a large production environment. Currently, ingress rules use network tags to identify which VMs may receive traffic on port 8080. Developers with the Compute Instance Admin role can freely add and remove network tags on their own VMs, which the security team considers a compliance risk because it lets developers grant themselves access covered by firewall rules. The security team wants firewall targeting that developers cannot self-assign without a privileged IAM permission. What should you do?

Accepted Answer

Recreate the firewall rules to target service accounts instead of network tags, and restrict who can assign service accounts to instances using the iam.serviceAccounts.actAs permission.

Answer

Move the firewall rules into a hierarchical firewall policy at the organization level so developers can no longer modify them.

Answer

Add a deny-all egress rule with higher priority so tagged VMs cannot initiate connections, forcing developers to request changes.

Answer

Enable VPC Flow Logs on the subnet and audit tag changes after the fact using Cloud Logging alerts.

Question 20

A team runs a fleet of Compute Engine VMs in a subnet named 'batch-workers' with no external IP addresses. The VMs must upload processed files to Cloud Storage and read from BigQuery using the standard public API endpoints (storage.googleapis.com and bigquery.googleapis.com). Currently the uploads fail with connection timeouts. There is no Cloud NAT gateway, and the organization forbids assigning external IPs to these VMs. What is the minimal configuration change to allow the API calls to succeed?

Accepted Answer

Enable Private Google Access on the 'batch-workers' subnet.

Answer

Deploy a Cloud NAT gateway in the region so the VMs can reach the public API endpoints.

Answer

Create a Private Service Connect endpoint for each Google API and update DNS to resolve the endpoints internally.

Answer

Configure private services access with an allocated IP range peered to the Google-managed service network.

More PCNE practice