Study guide
10.2 Firewall Rules, Cloud VPN & VPC Network Peering
Google Cloud Associate Cloud Engineer ACE
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Introduction & Exam Overview
1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan
2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity
2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups
3 Chapter 3: APIs, Quotas & Billing Configuration
3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts
4 Chapter 4: Planning Compute & Storage Resources
4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types
5 Chapter 5: Planning Network Resources
5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard
6 Chapter 6: Deploying Compute Engine Workloads
6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration
7 Chapter 7: Deploying Google Kubernetes Engine Workloads
7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE
8 Chapter 8: Deploying Serverless & Event-Driven Applications
8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc
9 Chapter 9: Deploying Data Solutions
9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud
10 Chapter 10: Deploying Networking Resources & Infrastructure as Code
10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm
11 Chapter 11: Managing Compute Engine & GKE in Production
11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE
12 Chapter 12: Managing Cloud Run, Storage & Database Operations
12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)
13 Chapter 13: Networking Operations, Monitoring & Logging
13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs
14 Chapter 14: IAM Policies & Role Types
14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles
15 Chapter 15: Service Accounts & Security Configuration
15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials
16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy
16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist
10.2 Firewall Rules, Cloud VPN & VPC Network Peering
Key Takeaways Explain This Topic AI
Firewall rules are evaluated by priority (0-65535, default 1000, lower number wins); implied deny-ingress and allow-egress rules sit at priority 65535 on every VPC.
The default network's default-allow-ssh/rdp/icmp rules are sourced from 0.0.0.0/0 and are a common security misconfiguration the exam expects you to spot.
IAP TCP forwarding (source range 35.235.240.0/20 plus roles/iap.tunnelResourceAccessor) is the recommended replacement for open SSH/RDP firewall rules.
Hierarchical firewall policies (Cloud NGFW) apply at the org/folder/project level across many VPCs; classic firewall rules apply to one VPC only.
Cloud VPN/Interconnect connect Google Cloud to an external network; VPC Network Peering connects two already-separate VPCs inside Google Cloud, non-transitively, with a default 25-peering-connection quota.
Last updated: July 2026
Why This Matters on the ACE Exam
The exam guide names this pairing explicitly under Domain 3: "creating ingress and egress firewall rules and policies" and "peering external networks (e.g., Cloud VPN, VPC Network Peering)." In practice these show up as two distinct question flavors — troubleshooting-style questions ("a VM can't be reached over SSH, what's missing?") and connectivity-design questions ("connect this VPC to that other network — which mechanism?"). Both build directly on the VPC and subnet foundation from Section 10.1.
Firewall Rule Anatomy
Every VPC firewall rule is defined by six components, and exam questions frequently hinge on getting just one of them right:
- Component Values Notes
- Direction INGRESS or EGRESS Ingress = traffic coming into an instance; egress = traffic leaving it
- Action allow or deny
Target All instances, specific network tags , or specific service accounts Defines which VMs the rule applies to
Source / Destination IP ranges, tags, or service accounts Source for ingress rules, destination for egress rules
Protocol : Port e.g., tcp:22 , tcp:80,443 , all
Priority 0 – 65535 , default 1000 Lower number wins — a priority-100 rule is evaluated before a priority-1000 rule
Two implied rules exist on every VPC and cannot be deleted, only overridden by a higher-priority (lower-number) explicit rule: an implied allow-egress rule and an implied deny-ingress rule, both at priority 65535 (the lowest possible priority). This is why a brand-new custom-mode VPC blocks all inbound traffic until you add explicit allow rules — but permits all outbound traffic by default.
The default network (an auto-mode VPC) additionally ships four extra explicit rules at priority 65534 : default-allow-internal , default-allow-ssh (tcp:22), default-allow-rdp (tcp:3389), and default-allow-icmp — every one of them sourced from 0.0.0.0/0 . Leaving default-allow-ssh in place on a production network is a textbook security trap the exam expects you to recognize and fix.
Network tags vs. service accounts as targets: tags are simple strings anyone with edit access to a VM can attach, so they carry no access control of their own. Targeting by service account is Google's recommended pattern for anything security-sensitive, because only a user or service account holding roles/iam.serviceAccountUser on that SA can attach it to a VM in the first place — firewall targeting inherits IAM's access control.
Hierarchical firewall policies (Cloud Next Generation Firewall / Cloud NGFW): classic VPC firewall rules attach to exactly one VPC network. Hierarchical firewall policies attach at the organization, folder, or project level and cascade down to every VPC underneath, letting a security team enforce a rule like "deny all egress to a list of known-bad IP ranges" across hundreds of projects from a single policy — without editing every VPC individually.
Secure Remote Access: Identity-Aware Proxy (IAP)
Rather than opening tcp:22 to 0.0.0.0/0 , the exam-recommended pattern is IAP TCP forwarding : create a firewall rule allowing ingress only from IAP's fixed range, 35.235.240.0/20 , on tcp:22 (or tcp:3389 for RDP). IAP then gates the tunnel itself with IAM — a user needs roles/iap.tunnelResourceAccessor before they can even reach that firewall-permitted range, so access is authenticated and audited before a packet ever reaches the VM. This removes the need for a public IP on the instance entirely.
Cloud VPN and VPC Network Peering
Once two networks need to talk to each other — a Google Cloud VPC to an on-premises data center, or one VPC to another — the correct mechanism depends on ownership and connection type:
Mechanism Connects Encryption Key detail
Cloud VPN (Classic) GCP VPC ↔ another network, over the public internet IPsec-encrypted tunnel Single tunnel, no SLA ; static or dynamic (BGP) routing
Cloud VPN (HA VPN) Same, but redundant IPsec-encrypted Two external IPs + two tunnels to redundant peer gateways; 99.99% availability SLA ; requires a Cloud Router for BGP
Cloud Router Not a connection itself — a routing control plane N/A Exchanges routes dynamically over BGP; required for HA VPN and dynamic Interconnect routing
VPC Network Peering Two independently-owned VPCs (same or different project/org) None needed — traffic stays on Google's internal backbone Non-transitive (A↔B and B↔C does not give A↔C); subnet ranges must not overlap; default quota of 25 peering connections per VPC network (expandable by quota request)
The recurring exam distinction: Cloud VPN and Cloud Interconnect connect Google Cloud to something outside Google Cloud (on-premises, another cloud); VPC Network Peering connects two VPCs that are both already inside Google Cloud but under separate ownership. If the scenario says "two already-existing, separately-managed VPCs," think peering, not VPN. If it says "our corporate data center," think VPN or Interconnect (revisit Chapter 5 for the VPN-vs-Interconnect bandwidth trade-off).
Exam Scenario
A security review finds a production VM reachable over SSH from any IP address on the internet, via a rule named default-allow-ssh . The fix: delete or disable default-allow-ssh , then add a narrower rule allowing tcp:22 only from 35.235.240.0/20 (IAP), targeted by service account rather than an open network tag — and grant roles/iap.tunnelResourceAccessor only to the engineers who actually need access.
Key Takeaways
Firewall rules are evaluated by priority (lower number = higher precedence); every VPC has implied deny-ingress/allow-egress rules at priority 65535 that explicit rules override.
Service-account-based firewall targeting is IAM-controlled and more secure than tag-based targeting.
IAP TCP forwarding (source range 35.235.240.0/20 ) replaces open SSH/RDP firewall rules with an IAM-gated tunnel.
Cloud VPN/Interconnect connect Google Cloud to an external network; VPC Network Peering connects two separately-owned VPCs already inside Google Cloud, non-transitively.
HA VPN needs a Cloud Router for BGP and delivers a 99.99% SLA versus Classic VPN's single, non-SLA tunnel.