Google ACE: VPC Networking, Connectivity and Traffic Management — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Virtual Private Cloud (VPC) networking on Google Cloud provides software-defined, global networking primitives with granular control of addressing, routing, security, and traffic management. This section focuses on practical design and operations topics you will use to build resilient, secure, and observable networks that interconnect Google Cloud services, on-premises environments, and the public internet.

Core VPC Architecture and IP Planning

• VPC networks and subnets

  • A VPC is a global resource; its subnets are regional and can span zones. Instances in any zone of the region can use a subnet.
  • Use custom mode VPCs for production. Auto mode precreates one subnet per region using a predefined set of CIDR ranges and can lead to overlapping IP constraints, wasted address space, and refactoring pain when you expand.
  • Secondary IP ranges on subnets enable GKE Pod/Service IPs and alias IPs for VMs. Plan primary and secondary CIDRs up front to avoid renumbering.

• IP address planning

  • Choose non-overlapping RFC1918 space for all present and future VPCs and on-prem networks you might connect. Reserve growth blocks for future regions and services.
  • Right-size subnets (e.g., /24 to /20) for growth and avoid overly large ranges that complicate ACLs and diagnostics.
  • Document IP use: primary ranges for workloads, secondary ranges for GKE, and reserved blocks for NAT pools or service endpoints.

• Example

  • gcloud compute networks create prod-net –subnet-mode=custom
  • gcloud compute networks subnets create app-us-central1 –network=prod-net –region=us-central1 –range=10.10.0.0/20 –secondary-range=gke-pods=10.20.0.0/16,gke-svcs=10.21.0.0/20

Routing, Firewalls, and Policy Hierarchy

• Routes and dynamic routing modes

  • Each VPC has a routing table made of system-generated subnet routes, default routes, and custom static or dynamic routes.
  • Dynamic routing mode:
    • Regional: dynamic (BGP) routes learned via Cloud Router are usable only by resources in the same region.
    • Global: dynamic routes are usable by resources in all regions of the VPC. Prefer global for hybrid networks that must reach on-prem from multiple regions.
  • Next hops: default internet gateway (0.0.0.0/0), VPN tunnel, Cloud Router (BGP), instance (routing appliance), or internal load balancer next hop for virtual appliances.
  • Route priority: lower numbers are preferred. Misconfigured priorities can blackhole traffic or leak it to an unintended next hop. Use clear conventions (e.g., 1000 for default egress, 900 for more specific routes).

• Firewall hierarchy

  • VPC firewall rules are stateful and evaluated before packet forwarding. They exist at the VPC level and apply to all subnets.
  • Hierarchical firewall policies (organization, folder, or project attachments) enforce allow/deny before VPC rules. Use them to implement central guardrails (e.g., deny internet-exposed admin ports).
  • Implied rules: an implied allow egress and implied deny ingress exist at lowest priority; they cannot be removed. All connectivity requires explicit ingress allows.

• Firewall rules, tags, service accounts, secure tags

  • Targeting: use network tags or service accounts to apply rules to specific VMs; service account targeting offers tighter identity-based control.
  • Secure tags provide centrally managed, IAM-protected labels for policy targeting; they prevent self-attachment by workloads and support zero-trust segmentation.
  • Logging: enable firewall logging selectively for high-value rules to balance visibility with cost; sample packets, not full payloads.
  • Common failure modes: missing health check source ranges, asymmetric routing causing reply drops, overly broad source ranges creating unintended exposure.

• Example

  • gcloud compute firewall-rules create allow-ilb-hc –network=prod-net –direction=INGRESS –action=ALLOW –priority=1000 –rules=tcp:80 –source-ranges=load-balancer-health-checks –target-service-accounts=web-sa@proj.iam.gserviceaccount.com

Load Balancing, IPs, DNS, and Traffic Management

• Cloud Load Balancing types and behavior

  • Global proxy-based: External HTTP(S), External TCP Proxy, External SSL Proxy. Terminate client connections at Google’s edge, support anycast global VIPs, and insert headers (e.g., X-Forwarded-For). Original client IP is available via headers or PROXY protocol (for TCP) rather than preserved as L3 source.
  • Regional passthrough: External Network Load Balancer and Internal TCP/UDP Load Balancer route traffic at L4 and preserve client IP. Use when you require source IP visibility at backends without PROXY protocol.
  • Internal HTTP(S) Load Balancer: regional L7 proxy for internal services with advanced routing and mTLS options.

• Backend services, health checks, and traffic policies

  • Backend services define backends (instance groups, NEG/VM/Endpoint, GKE services), balancing mode (UTILIZATION or RATE), capacity limits, session affinity, and connection draining.
  • Health checks must be allowed through firewalls from Google health-checkers. Unhealthy backends are automatically removed; misconfigured health checks can cause total outage.
  • Traffic policies include locality (region/zone), overflow and failover backends, and weighted traffic splitting for gradual rollouts on some LB types.

• External and internal IPs, forwarding rules

  • External and internal addresses can be ephemeral or reserved static. Global static external addresses are used by global LBs; most others are regional.
  • Forwarding rules map an IP:port to a target (e.g., targetHttpProxy or backend service). Pick global vs regional rules to match LB type; a mismatch prevents creation.

• Cloud DNS

  • Zones: public zones resolve on the public internet; private zones are resolvable only from authorized VPCs. Use managed records (A/AAAA, CNAME, TXT, MX, SRV, etc.).
  • Split-horizon: create both public and private zones for the same domain so internal resolvers receive private answers (e.g., ILB IP) while public users get internet-facing IPs.
  • Private DNS forwarding: use Cloud DNS policies for inbound and outbound forwarding to integrate with on-prem resolvers; use DNS peering between VPCs to share private zones without full peering connectivity.

• Example

  • gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

Hybrid and Private Connectivity

• Cloud Router, Cloud NAT, and Private Google Access

  • Cloud Router exchanges routes with on-prem via BGP, advertises VPC subnets, and imports on-prem prefixes. Use global dynamic routing when multiple regions need on-prem reachability.
  • Cloud NAT provides internet egress for private VMs and GKE nodes without external IPs. Size NAT IP pools to avoid port exhaustion; monitor logs for dropped connections and scale addresses accordingly.
  • Private Google Access (PGA) lets private VMs reach Google APIs without external IPs over the default routing path. Private Service Connect (PSC) for Google APIs gives private IP endpoints in your VPC with policy control and avoids public egress entirely; prefer PSC endpoints for stricter egress control and consistent DNS.

• Private Service Connect (producer and consumer services)

  • Expose internal services behind a service attachment in a producer project and consume via private endpoints in consumer projects. DNS mapping and explicit allow policies control access. This improves isolation versus VPC Peering and centralizes service publishing.

• VPC Network Peering, Shared VPC, and segmentation

  • VPC Peering offers private connectivity between VPCs with low latency. It is non-transitive and disallows overlapping IPs. Optional import/export of custom routes extends reachability but still does not create transitive routing; plan hub-and-spoke deliberately.
  • Shared VPC centralizes subnets in a host project for use by service projects. This enables centralized routing, firewalls, NAT, and LBs while delegating per-application IAM. Combine with hierarchical firewalls and secure tags for segmentation.
  • Network Connectivity Center (NCC) provides a hub to orchestrate spokes (VPN, Interconnect, router appliance, VPC spokes) and manage enterprise WAN topologies consistently.

• Cloud VPN, Cloud Interconnect, and BGP

  • Cloud VPN: use HA VPN with dynamic routing (BGP) for availability and automatic route failover. Build two tunnels per peer across independent Cloud VPN interfaces and distinct on-prem devices/links when possible.
  • Cloud Interconnect: Dedicated Interconnect provides private 10–100 Gbps links; Partner Interconnect uses a service provider. For resilience, deploy redundant interconnects in diverse edge availability domains and use BFD with BGP where supported.
  • Failure domains: isolate by region, zone, device, and provider. Test failover regularly; asymmetric paths can break stateful firewalls on-prem.

• Examples

  • gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
  • gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
  • gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

Observability and Troubleshooting

• Connectivity Tests

  • Simulate and verify reachability between sources and destinations across VPCs, on-prem (via hybrid links), and load balancers. The tool evaluates routes, firewall rules, and configuration to locate drops or misrouted traffic before production changes.
  • Example: gcloud beta network-management connectivity-tests create test-ilb –source-ip=10.10.1.5 –destination-ip=10.30.4.10 –protocol=TCP –destination-port=80 –project=my-proj

• VPC Flow Logs

  • Enable at subnet level for real-time insights into 5-tuple flows, bytes, drops, and latency. Export to Cloud Logging, Pub/Sub, or BigQuery for analytics. Adjust sampling and metadata levels to control cost.
  • Use cases: validate firewall effectiveness, detect exfiltration, capacity planning, and SLO monitoring.

• Packet Mirroring

  • Mirror VM or GKE traffic to collector endpoints for deep packet inspection or IDS. Scope mirrors by subnet, tag, or instance. Understand performance overhead and ensure collectors can handle mirrored volume. Avoid mirroring post-NAT traffic when you need original headers.

• Common diagnostics patterns

  • Blackhole: route exists but reply path is blocked by firewall or asymmetric routing; validate with Connectivity Tests and flow logs on both sides.
  • Health check failures: confirm firewall allows from health-checkers and backends listen on correct ports; test locally from a VM in the same subnet.
  • NAT exhaustion: look for denied flows with reason “no available NAT ports”; add more NAT IPs or reduce per-VM port caps.

Practical Problem Scenario

Acme Retail operates a multiregion e-commerce platform with private backends, public web entry, and on-prem ERP. They must segment workloads, provide private egress to Google APIs, enable hybrid reachability from all regions, and harden security while maintaining observability.

1. Create a custom-mode Shared VPC for central control

• gcloud compute networks create acme-net –subnet-mode=custom
• Rationale: Custom mode avoids auto-assigned CIDRs and enables deliberate IP planning. Shared VPC centralizes routing, firewalls, and NAT in a host project while letting service projects deploy safely.

2. Plan and create subnets with secondary ranges for GKE

• gcloud compute networks subnets create web-us –region=us-central1 –network=acme-net –range=10.10.0.0/20 –secondary-range=pods=10.20.0.0/16,svcs=10.21.0.0/20
• Rationale: Non-overlapping primary and secondary ranges prevent future peering conflicts and allow alias IPs for GKE without IP exhaustion.

3. Set VPC dynamic routing to global and deploy Cloud Router

• gcloud compute networks update acme-net –bgp-routing-mode=global
• gcloud compute routers create hub-uc1 –region=us-central1 –network=acme-net –asn=64514
• Rationale: Global mode makes BGP-learned on-prem routes usable from all regions, simplifying hybrid reachability and failover.

4. Establish HA VPN to on-prem and advertise subnets

• Create two HA VPN tunnels across diverse on-prem devices. Use BGP to exchange prefixes and enable graceful failover.
• Rationale: Dual tunnels remove single points of failure; BGP converges routes quickly during maintenance or outages.

5. Deploy Cloud NAT for private egress and PSC for Google APIs

• gcloud compute routers nats create nat-uc1 –router=hub-uc1 –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
• Create Private Service Connect endpoints for Google APIs and update private DNS to map api endpoints to PSC.
• Rationale: NAT allows internet egress without external VM IPs; PSC keeps API traffic on private IPs and under explicit policy control, eliminating public egress paths.

6. Frontend with global External HTTP(S) Load Balancer; internal services via Internal HTTP(S)

• Create a global external HTTP(S) LB with a managed certificate and backend service pointing to NEG backends.
• Create regional Internal HTTP(S) LBs for service-to-service traffic with mTLS between microservices.
• Rationale: The global proxy LB provides anycast, autoscaling, and CDN; internal L7 LB offers rich routing and security for east-west traffic.

7. Implement hierarchical firewall policies and workload identity targeting

• Attach an org-level policy denying admin ports from the internet; allow only LB health-check sources.
• Create VPC rules targeting service accounts for least-privilege access between tiers; use secure tags for dynamic segmentation.
• Rationale: Hierarchy enforces guardrails centrally; identity-based targeting resists tag spoofing and simplifies automation.

8. Configure Cloud DNS with split-horizon and forwarding

• Create public zone acme.com for web VIP, and private zone acme.com for internal service names mapping to ILBs.
• Configure outbound forwarding to on-prem DNS and inbound for on-prem to resolve private zones.
• Rationale: Split-horizon prevents data leakage and ensures correct name resolution based on source network; forwarding integrates legacy namespaces.

9. Use Connectivity Tests, flow logs, and packet mirroring for visibility

• Create tests for critical paths (user to web LB, web to internal services, services to on-prem ERP).
• Enable flow logs on subnets; export to BigQuery for trend analysis. Enable packet mirroring temporarily during incident response.
• Rationale: Proactive validation and telemetry shorten MTTR, reveal misconfigurations, and provide capacity insights.

10. Document and test failure scenarios

• Simulate loss of a VPN tunnel, a region, and a backend MIG. Verify BGP failover, LB health-check removal, and DNS correctness.
• Rationale: Regular game days confirm assumptions about redundancy and expose configuration drift before it causes outages.

← Containers · All domains · Storage →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →