Google Cloud VPC Firewall Rules & NGFW Policies

May 9, 2021 ~ Last updated on : June 29, 2026 ~ jayendrapatil

Google Cloud VPC Firewall Rules

📋 Migration Recommended: Move to Network Firewall Policies

Google Cloud recommends migrating from VPC firewall rules to Network Firewall Policies (part of Cloud NGFW). Network firewall policies offer enhanced features including IAM-governed Tags, FQDN objects, geolocation filtering, threat intelligence, and batch updates.

A migration tool (gcloud compute firewall-rules migrate) is available to convert existing VPC firewall rules to a global network firewall policy automatically.

Learn more about migration →

VPC firewall rules are part of Cloud NGFW (Cloud Next Generation Firewall) Essentials tier, Google Cloud’s distributed, cloud-native stateful inspection firewall service.
Firewall rules help define allow or deny connections and apply to both outgoing (egress) and incoming (ingress) traffic in the network.
Firewall rules control traffic even if it is entirely within the VPC network, including communication among VM instances.
Firewall rules apply to a given project and network, and connections are allowed or denied on a per-instance basis.
Every VPC network has two implied firewall rules
- Implied allow egress rule – allow all egress traffic,
- Implied deny ingress rule – denies all ingress traffic.
Implied rules cannot be deleted but have the lowest possible priorities and can be overridden
Firewall rules support IPv4 and IPv6 connections. When specifying a source or destination by address, IPv4 or IPv6 addresses can be specified in CIDR notation. Each firewall rule can contain either IPv4 or IPv6 ranges, but not both.
Firewall rules always allow the following traffic (via the metadata server at 169.254.169.254 for IPv4 and fd20:ce::254 for IPv6)
- DHCP
- DNS resolution
- Instance metadata
- NTP
Google Cloud blocks or limits the following traffic
- Egress traffic on TCP port 25 (SMTP) to external IP addresses (to prevent spam)
- DHCP offers/acknowledgments from sources other than the metadata server
- External IP addresses only accept TCP, UDP, ICMP, IPIP, AH, ESP, SCTP, and GRE packets
VPC firewall rules are stateful
- Google Cloud associates incoming packets with corresponding outbound packets by using a connection tracking table.
- When a connection is allowed through the firewall in either direction, return traffic matching this connection is also allowed.
- Firewall rule cannot be configured to deny associated response traffic.
- Stateful response to the request is not logged as well
- Return traffic must match the 5-tuple (source IP, destination IP, source port, destination port, protocol) of the accepted request traffic, but the source and destination addresses and ports are reversed.
- IPv4 connections support TCP, UDP, SCTP, and ICMP protocols for connection tracking. IPv6 connections support TCP, UDP, SCTP, and ICMPv6 protocols.
- Google Cloud implements connection tracking regardless of whether the protocol supports connections.
- A firewall rule’s tracking state is considered active if at least one packet is sent every 10 minutes.
- The maximum number of tracked connections depends on the machine type:
  - Shared-core machine types: 130,000 connections
  - Instances with 1–8 vCPUs: 130,000 connections per vCPU
  - Instances with more than 8 vCPUs: 1,040,000 (130,000×8) connections total

VPC Firewall Rules Components

Cloud NGFW Tiers

VPC firewall rules are part of the broader Cloud NGFW (Cloud Next Generation Firewall) product, which is offered in three tiers:
- Cloud NGFW Essentials – Foundational tier including VPC firewall rules, global and regional network firewall policies, hierarchical firewall policies, IAM-governed Tags, and Address groups.
- Cloud NGFW Standard – Extends Essentials with Fully Qualified Domain Name (FQDN) objects, geolocation objects, and threat intelligence for firewall policy rules.
- Cloud NGFW Enterprise – Provides advanced Layer 7 security capabilities including Intrusion Detection and Prevention Service (IDPS), TLS inspection, and URL filtering, powered by Palo Alto Networks.
Cloud NGFW Enterprise uses firewall endpoints (Google-managed zonal resources) that use packet intercept technology to inspect workload traffic for threat signatures.

Firewall Policies (Recommended)

Google Cloud now provides Firewall Policies as the recommended approach for managing firewall rules, offering several advantages over VPC firewall rules:
- Batch updates to multiple rules simultaneously
- IAM-governed Tags (Secure Tags) instead of network tags
- FQDN objects, geolocation filtering, and threat intelligence (Standard/Enterprise)
- Consistent experience across the resource hierarchy
Types of Firewall Policies:
- Hierarchical Firewall Policies – Applied at organization and folder levels. Support goto_next action to delegate evaluation to lower-level policies.
- Global Network Firewall Policies – Applied to all subnetworks in all regions of a VPC network.
- Regional Network Firewall Policies – Applied only to subnetworks of the VPC network in the target region.
Firewall policy rules have a priority range of 0 to 2,147,483,547 (vs. 0 to 65,535 for VPC firewall rules).
Firewall policy rules support additional actions: allow, deny, goto_next, and apply_security_profile_group.

Firewall Rule Evaluation Order

Google Cloud supports two network firewall policy enforcement orders:
- AFTER_CLASSIC_FIREWALL (default):
  1. Hierarchical firewall policies
  2. Regional system firewall policies
  3. VPC firewall rules
  4. Global network firewall policies
  5. Regional network firewall policies
  6. Implied actions
- BEFORE_CLASSIC_FIREWALL:
  1. Hierarchical firewall policies
  2. Regional system firewall policies
  3. Global network firewall policies
  4. Regional network firewall policies
  5. VPC firewall rules
  6. Implied actions
The enforcement order can be changed using gcloud compute networks update with the --network-firewall-policy-enforcement-order flag.

Firewall Rule Components

Each firewall rule requires the direction of connection and applies to incoming (ingress) or outgoing (egress) connection, not both
Each firewall rule’s action is either allow or deny.
Each firewall rule has a priority defined from 0 to 65535 inclusive, defaults to 1000. Lower integers indicate higher priorities.
A target, which defines the instances to which the rule applies.
- Ingress (inbound) rule, the target parameter designates the destination VM instances
- Egress (outbound) rule, the target designates the source instances.
- supports the following options
  - All instances in the network.
  - Instances by target tags.
  - Instances by target service accounts
A source for ingress rules or a destination for egress rules.
- Ingress (inbound) rules
  - target parameter specifies the destination instances for traffic;
  - destination parameter cannot be used
  - source is specified by using the source parameter.
- Egress (outbound) rules
  - target parameter specifies the source instances for traffic;
  - source parameter cannot be used
  - destination is specified by using the destination parameter.
- supports the following options
  - Source IP ranges (IPv4 or IPv6 in CIDR format)
  - Source tags
  - Source service accounts
Protocols and Ports
- Supported protocol names: tcp, udp, icmp (IPv4 ICMP), esp, ah, sctp, and ipip. For other protocols, use IANA protocol numbers.
- IPv6 Hop-by-Hop protocol is not supported in firewall rules.
- Port-based protocols (tcp, udp, sctp) support destination port or port range specification.
Firewall rules have enforcement status and are enabled by default. They can be disabled for troubleshooting or for maintenance, instead of having to delete and add them again.

Service Account vs Network Tag Filtering

Firewall rules support source and target filtering by Service Account and Network Tags
Service Accounts and Network Tags cannot be mixed and matched in any firewall rule.
Use service accounts instead of network tags for strict control over how firewall rules are applied to VMs, as network tags can be inferred while using a service account would require access to it as well.
A network tag is an arbitrary attribute. One or more network tags can be associated with an instance by any IAM member who has permission to edit it. IAM members with the Compute Engine Instance Admin role to a project have this permission. IAM members who can edit an instance can change its network tags, which could change the set of applicable firewall rules for that instance.
A service account represents an identity associated with an instance. Only one service account can be associated with an instance. Access to the service account can be controlled by controlling the grant of the Service Account User role for other IAM members. For an IAM member to start an instance by using a service account, that member must have the Service Account User role to at least use that service account and appropriate permissions to create instances.

IAM-Governed Tags (Secure Tags)

IAM-governed Tags (also called Secure Tags) are available in Firewall Policies as a replacement for network tags.
Unlike network tags, IAM-governed Tags are controlled by IAM permissions, providing better security and governance.
Tags deliver intra-subnet micro-segmentation with pervasive policy coverage that automatically applies to workloads wherever they are deployed, independently of the network architecture.
IAM-governed Tags are only available in firewall policies (not VPC firewall rules).
For new deployments, use IAM-governed Tags with Network Firewall Policies instead of network tags with VPC firewall rules.

Firewall Rules Logging

Firewall Rules Logging enables auditing, verifying, and analyzing the effects of the firewall rules.
Firewall Rules Logging can be enabled individually for each firewall rule whose connections need to log
Google Cloud creates an entry called a connection record each time the firewall rule allows or denies traffic.
Each connection record contains the source and destination IP addresses, the protocol and ports, date and time, and a reference to the firewall rule that applied to the traffic.
Firewall Rules Logging only records TCP and UDP connections.
Firewall Rules Logging cannot be enabled for the implied deny ingress and implied allow egress rules. Instead, create explicit Allow or Deny rules.

Firewall Insights

Firewall Insights (part of Network Intelligence Center) analyzes firewall rules and provides recommendations to optimize security posture.
Key capabilities:
- Shadowed Rules – Detects rules that share attributes with other higher-priority rules, making them ineffective.
- Overly Permissive Rules – Identifies allow rules with no hits, unused attributes, or overly permissive IP addresses/port ranges.
- Deny Rules with No Hits – Identifies deny rules that haven’t blocked any traffic during the observation period.
Requires Firewall Rules Logging to be enabled for log-based insights.
Provides recommendations through the Recommender Hub to help tighten firewall rules.

VPC Firewall Rules Migration

Google Cloud provides a migration tool to help transition from VPC firewall rules to network firewall policies.
The migration tool creates a global network firewall policy and converts existing VPC firewall rules into firewall policy rules.
Two migration paths:
- Without dependencies – For rules that don’t use network tags or service accounts.
- With dependencies – For rules that use network tags or service accounts (tags are converted to IAM-governed Tags).
Command: gcloud beta compute firewall-rules migrate
Benefits of migrating:
- Access to Cloud NGFW Standard and Enterprise features
- Better policy organization and batch updates
- IAM-governed Tags for improved security
- Consistent policy management across the resource hierarchy

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your developers are trying to connect to an Ubuntu server over SSH to diagnose some errors. However, the connection times out.
Which command should help solve the problem?
1. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --allow tcp:22
2. gcloud compute firewall-rules create "open-ssh"
3. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --deny tcp:22
4. gcloud compute firewall-rules create "open-ssh" --network $NETWORK --allow tcp:3389
You’ve created a new firewall rule to allow incoming traffic on port 22, using a target tag of “dev-ssh”. You tried to connect to one of your instances, and you’re still unable to connect. What steps do you need to take to resolve the problem?
1. Run the gcloud firewall-rules refresh command, as they need to be reloaded
2. Use source tags in place of the target tags.
3. Reboot the instances for the firewall rule to take effect.
4. Apply a network tag of “dev-ssh” to the instance you’re trying to connect into and test again.
You have created a firewall with rules that only allow traffic over HTTP, HTTPS, and SSH ports. While testing, you specifically try to reach the server over multiple ports and protocols; however, you do not see any denied connections in the firewall logs. You want to resolve the issue. What should you do?
1. Enable logging on the default Deny Any Firewall Rule.
2. Enable logging on the VM Instances that receive traffic.
3. Create a logging sink forwarding all firewall logs with no filters.
4. Create an explicit Deny Any rule and enable logging on the new rule.
Your organization wants to enforce a consistent firewall policy across all projects and VPC networks. Which approach provides centralized management at the organization level?
1. Create VPC firewall rules in each project individually.
2. Use Hierarchical Firewall Policies at the organization or folder level.
3. Use network tags across all projects.
4. Create shared VPC firewall rules in the host project only.
You want to migrate your existing VPC firewall rules to network firewall policies for better management. Your rules use network tags for targeting. What should you use in the new firewall policies?
1. Continue using network tags in firewall policies.
2. Use source IP ranges only.
3. Use IAM-governed Tags (Secure Tags) to replace network tags.
4. Use service accounts exclusively.
Your security team needs to filter outbound traffic based on domain names and block connections to specific countries. Which Cloud NGFW tier should you use?
1. Cloud NGFW Essentials
2. Cloud NGFW Standard
3. Cloud NGFW Enterprise
4. VPC firewall rules
You need to inspect network traffic for malware and command-and-control attacks with TLS decryption. Which Cloud NGFW feature provides this capability?
1. Firewall Rules Logging
2. Firewall Insights
3. Cloud NGFW Standard threat intelligence
4. Cloud NGFW Enterprise with Intrusion Detection and Prevention Service (IDPS) and TLS inspection
In the default (AFTER_CLASSIC_FIREWALL) enforcement order, which firewall rules are evaluated first?
1. VPC firewall rules
2. Global network firewall policies
3. Hierarchical firewall policies
4. Regional network firewall policies

References

Google Cloud Networking Services Cheat Sheet

March 23, 2021 ~ Last updated on : June 29, 2026 ~ jayendrapatil

Virtual Private Cloud

Virtual Private Cloud (VPC) provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
Subnets are regional resources and each subnet defines a range of IP addresses
IPv6 Support
- VPC networks support dual-stack (IPv4 and IPv6) subnets in custom-mode VPC networks.
- IPv6 functionality is available only in Premium Tier.
- Supports both external (GUA – Globally Unique Addresses) and internal (ULA – Unique Local Addresses) IPv6 ranges.
- VMs can have IPv4-only, dual-stack, or IPv6-only interfaces.
Cloud NGFW (Next Generation Firewall)
- replaces legacy VPC firewall rules with network firewall policies.
- protects workloads by applying controls at Layer 3, Layer 4, and Layer 7 of the network stack.
- available in three tiers:
  - Essentials – rules based on IP ranges, ports, and protocols
  - Standard – adds FQDN objects, geo-location objects, and threat intelligence
  - Enterprise – adds Intrusion Detection and Prevention Service (IPS) powered by Palo Alto Networks, TLS inspection
- Google recommends migrating from legacy VPC firewall rules to Cloud NGFW network firewall policies.
- Network firewall policies can be attached to a single VPC or group of VPCs (unlike legacy VPC firewall rules which apply to a single VPC only).
Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
Private access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
Private Service Connect (PSC)
- allows consumers to access managed services privately from inside their VPC network.
- allows managed service producers to host services in their own separate VPC networks and offer a private connection to consumers.
- creates service endpoints in consumer VPCs that provide private connectivity and policy enforcement.
Shared VPC to keep a VPC network in a common host project shared with service projects. Authorized IAM members from other projects in the same organization can create resources that use subnets of the Shared VPC network
VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
Primary and Secondary IP address cannot overlap with the on-premises CIDR
VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.

Cloud Load Balancing

Cloud Load Balancing is a fully distributed, software-defined managed load balancing service
distributes user traffic across multiple instances of the applications and reduces the risk of performance issues by spreading the load
provides health checking mechanisms that determine if backends, such as instance groups and zonal network endpoint groups (NEGs), are healthy and properly respond to traffic.
supports IPv6 clients with Application Load Balancers and proxy Network Load Balancers.
Note: Google Cloud has renamed load balancer types. HTTP(S) Load Balancing is now Application Load Balancer, TCP/UDP Load Balancing is now passthrough Network Load Balancer, and SSL Proxy/TCP Proxy are now proxy Network Load Balancer.
supports multiple Cloud Load Balancing types
- Internal Application Load Balancer (formerly Internal HTTP(S) Load Balancing)
  - is a proxy-based, regional Layer 7 load balancer that enables running and scaling services behind an internal IP address.
  - also available as a cross-region internal Application Load Balancer for multi-region backends with automatic failover.
  - supports a regional backend service, which distributes HTTP and HTTPS requests to healthy backends (either instance groups containing CE VMs or NEGs containing GKE containers).
  - supports path based routing
  - preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
  - supports a regional health check that periodically monitors the readiness of the backends.
  - has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
- External Application Load Balancer (formerly External HTTP(S) Load Balancing)
  - is a global, proxy-based Layer 7 load balancer that enables running and scaling the services worldwide behind a single external IP address
  - distributes HTTP and HTTPS traffic to backends hosted on Compute Engine and GKE
  - offers global (cross-regional) and regional load balancing
  - supports content-based load balancing using URL maps
  - preserves the Host header of the original client request and also appends two IP addresses (Client and LB) to the X-Forwarded-For header
  - supports connection draining on backend services
  - has native support for the WebSocket protocol when using HTTP or HTTPS as the protocol to the backend
  - supports mutual TLS (mTLS) authentication for client certificate-based authentication.
- Internal passthrough Network Load Balancer (formerly Internal TCP/UDP Load Balancing)
  - is a managed, internal, pass-through, regional Layer 4 load balancer that enables running and scaling services behind an internal IP address
  - distributes traffic among VM instances in the same region in a Virtual Private Cloud (VPC) network by using an internal IP address.
  - provides high-performance, pass-through Layer 4 load balancer for TCP or UDP traffic.
  - routes original connections directly from clients to the healthy backends, without any interruption.
  - does not terminate SSL traffic and SSL traffic can be terminated by the backends instead of by the load balancer
  - provides access through VPC Network Peering, Cloud VPN or Cloud Interconnect
  - supports health check that periodically monitors the readiness of the backends.
- External passthrough Network Load Balancer (formerly External TCP/UDP Network Load Balancing)
  - is a managed, external, pass-through, regional Layer 4 load balancer that distributes TCP or UDP traffic originating from the internet to among VM instances in the same region
  - Load-balanced packets are received by backend VMs with their source IP unchanged.
  - Load-balanced connections are terminated by the backend VMs. Responses from the backend VMs go directly to the clients, not back through the load balancer (direct server return).
  - scope of a network load balancer is regional, not global. A network load balancer cannot span multiple regions. Within a single region, the load balancer services all zones.
  - supports connection tracking table and a configurable consistent hashing algorithm to determine how traffic is distributed to backend VMs.
  - supports additional protocols like UDP, ESP, GRE, ICMP, and ICMPv6.
- External proxy Network Load Balancer (formerly External SSL Proxy and TCP Proxy Load Balancing)
  - is a reverse proxy load balancer that distributes SSL or TCP traffic coming from the internet to VM instances in the VPC network.
  - with SSL traffic, user SSL (TLS) connections are terminated at the load balancing layer, and then proxied to the closest available backend instances by using either SSL (recommended) or TCP.
  - supports global load balancing service with the Premium Tier and regional load balancing service with the Standard Tier
  - is intended for non-HTTP(S) traffic. For HTTP(S) traffic, use Application Load Balancers.
  - supports proxy protocol header to preserve the original source IP addresses of incoming connections to the load balancer

Cloud CDN

Cloud CDN is Google Cloud’s web acceleration solution that caches website and application content closer to the user.
uses Google’s global edge network to serve content closer to users, which accelerates the websites and applications.
works with the global external Application Load Balancer or the classic Application Load Balancer to deliver content to users
Cloud CDN content can be sourced from various types of backends
- Instance groups
- Zonal network endpoint groups (NEGs)
- Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
- Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
- Buckets in Cloud Storage
supports content targeting (GA) — enables device characterization and geo-targeting for responsive websites, language customization, and currency settings.
Cloud CDN with Google Cloud Armor enforces security policies only for requests for dynamic content, cache misses, or other requests that are destined for the origin server. Cache hits are served even if the downstream Google Cloud Armor security policy would prevent that request from reaching the origin server.
recommends
- using versioning instead of cache invalidation
- using custom keys to improve cache hit ratio
- cache static content
Media CDN
- is Google Cloud’s media delivery solution, complementing Cloud CDN.
- optimized for high-throughput egress workloads, such as streaming video and large file downloads.
- uses YouTube’s infrastructure to bring video streams (VoD and live) and large file downloads closer to users.
- supports Cloud Armor edge security policies for DDoS protection.

Cloud VPN

securely connects the peer network to the VPC network or two VPCs through an IPsec VPN connection.
encrypts the data as it travels over the internet.
only supports site-to-site IPsec VPN connectivity and not client-to-gateway scenarios. Cannot be used to route traffic to the public internet.
allows users to access private RFC1918 addresses on resources in the VPC from on-prem computers also using private RFC1918 addresses.
can be used with Private Google Access for on-premises hosts
HA VPN
- provides a high-available and secure connection between the on-premises and the VPC network through an IPsec VPN connection in a single region
- provides an SLA of 99.99% service availability, when configured with two interfaces and two external IP addresses.
- supports IPv6 (dual-stack) tunnels for both inner and outer IP addresses.
- supports customizable cipher options for VPN tunnels.
Classic VPN
- provides a 99.9% SLA.
- Classic VPN dynamic routing (BGP) was deprecated on August 1, 2025. HA VPN is now the only option for BGP connectivity in Cloud VPN. Existing tunnels continue to function but without an availability SLA. If deleted, they cannot be recreated.
- Does not support IPv6 traffic.
HA VPN over Cloud Interconnect
- allows encrypting traffic traversing Dedicated or Partner Interconnect connections.
- deploys HA VPN tunnels over VLAN attachments for additional security and compliance.
- Each HA VPN tunnel has a bandwidth of 3 Gbps.
supports up to 3Gbps per tunnel with a maximum of 8 tunnels
supports static as well as dynamic routing using Cloud Router
supports IKEv1 or IKEv2 using a shared secret

Cloud Interconnect

Cloud Interconnect provides options for extending the on-premises network to the VPC networks in Google Cloud.
Dedicated Interconnect (Dedicated connection)
- provides a direct physical connection between the on-premises network and Google’s network
- requires your network to physically meet Google’s network in a colocation facility with your own routing equipment
- supports only dynamic routing
- supports 10 Gbps, 100 Gbps, and 400 Gbps circuits.
Partner Interconnect (Use a service provider)
- provides connectivity between the on-premises and VPC networks through a supported service provider.
- supports bandwidth from 50 Mbps minimum to 50 Gbps maximum.
- provides Layer 2 and Layer 3 connectivity
  - For Layer 2 connections, you must configure and establish a BGP session between the Cloud Routers and on-premises routers for each created VLAN attachment
  - For Layer 3 connections, the service provider establishes a BGP session between the Cloud Routers and their edge routers for each VLAN attachment.
Cross-Cloud Interconnect
- provides dedicated, private connectivity between Google Cloud and another cloud provider (AWS, Azure, OCI, Alibaba Cloud).
- offers 10 Gbps or 100 Gbps managed, encrypted links.
- supports security options such as IPsec VPN or MACsec.
- Partner Cross-Cloud Interconnect (for AWS) provides an on-demand method for establishing cross-cloud transport without manually setting up networking components.
Cross-Site Interconnect
- is a transparent, on-demand, Layer 2 connectivity solution between on-premises network sites.
- leverages Google’s global infrastructure for high-performance and high-bandwidth connectivity.
Single Interconnect connection does not offer redundancy or high availability and its recommended to
- use 2 in the same metropolitan area (city) as the existing one, but in a different edge availability domain (metro availability zone).
- use 4 with 2 connections in two different metropolitan areas (city), and each connection in a different edge availability domain (metro availability zone)
- Cloud Routers are required one in each Google Cloud region
Cloud Interconnect does not encrypt the connection between your network and Google’s network. For additional security, use HA VPN over Cloud Interconnect or application-level encryption.

Cloud Router

is a fully distributed, managed service that provides dynamic routing and scales with the network traffic.
works with both legacy networks and VPC networks.
isn’t supported for Direct Peering or Carrier Peering connections.
helps dynamically exchange routes between the Google Cloud networks and the on-premises network.
peers with the on-premises VPN gateway or router to provide dynamic routing and exchanges topology information through BGP.
Google Cloud recommends creating two Cloud Routers in each region for a Cloud Interconnect for 99.99% availability.
supports following dynamic routing mode
- Regional routing mode – provides visibility to resources only in the defined region.
- Global routing mode – provides visibility to resources in all regions
is part of the Network Connectivity Center, which provides a hub-and-spoke model for managing connectivity across VPC networks, on-premises, and other clouds.

Network Connectivity Center

provides a hub-and-spoke model for managing network connectivity at scale.
enables site-to-site data transfer between on-premises locations through Google’s network.
supports VPC spokes, hybrid spokes (VPN/Interconnect), and router appliance spokes.
solves transitivity challenges through features like producer VPC spoke integration supporting Private Service Access (PSA) and Private Service Connect (PSC) propagation.
uses ECMP routing and BGP for route distribution between networks.

Cloud DNS

is a high-performance, resilient, reliable, low-latency, global DNS service that publishes the domain names to the global DNS in a cost-effective way.
With Shared VPC, Cloud DNS managed private zone, Cloud DNS peering zone, or Cloud DNS forwarding zone must be created in the host project
provides Private Zone which supports DNS services for a GCP project. VPCs in the same project can use the same name servers
supports DNS Forwarding for Private Zones, which overrides normal DNS resolution for the specified zones. Queries for the specified zones are forwarded to the listed forwarding targets.
supports DNS Peering, which allows sending requests for records that come from one zone’s namespace to another VPC network within GCP
supports DNS Outbound Policy, which forwards all DNS requests for a VPC network to the specified server targets. It disables internal DNS for the selected networks.
DNS Routing Policies
- supports weighted round robin, geolocation, and failover routing policies.
- can be configured with health checks for automatic failover.
- supports internal passthrough Network Load Balancers and internal proxy Network Load Balancers as health checked targets.
Cloud DNS VPC Name Resolution Order
- DNS Outbound Server Policy
- DNS Forwarding Zone
- DNS Peering
- Compute Engine internal DNS
- Public Zones
supports DNSSEC, a feature of DNS, that authenticates responses to domain name lookups and protects the domains from spoofing and cache poisoning attacks

Google Cloud VPC – Subnets, Routes & Firewalls

February 2, 2021 ~ Last updated on : June 29, 2026 ~ jayendrapatil

Google Cloud Virtual Private Cloud – VPC

Virtual Private Cloud (VPC) provides networking functionality to Compute Engine virtual machine (VM) instances, Google Kubernetes Engine (GKE) clusters, and serverless workloads. VPC provides networking for the cloud-based resources and services that is global, scalable, and flexible.

VPC Networks

VPC network is a virtual version of a physical network, implemented inside of Google’s production network by using Andromeda (Google’s distributed network virtualization platform).
A VPC network is a global resource that consists of a list of regional virtual subnets in data centers, all connected by a global wide area network.
VPC networks are logically isolated from each other in Google Cloud.
VPC networks
- provides connectivity for the Compute Engine VMs, including GKE clusters, serverless workloads, and other Google Cloud products built on Compute Engine VMs
- offers built-in internal passthrough Network Load Balancers and proxy systems for internal Application Load Balancers.
- connects to on-premises networks using Cloud VPN tunnels and VLAN attachments for Cloud Interconnect.
- distributes traffic from Google Cloud external load balancers to backends

Specifications

VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
Subnets are regional resources and each subnet defines a range of IP addresses.
Firewall rules control the traffic to and from instances. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
Resources within a VPC network can communicate with one another by using internal IPv4 addresses (and IPv6 addresses in dual-stack or IPv6-only subnets), subject to applicable network firewall rules.
Private access options for services allow instances with internal IP addresses to communicate with Google APIs and services.
Network administration can be secured by using IAM roles.
An organization can use Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use Shared VPC network subnets.
VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
VPC networks support IPv4 unicast traffic, and now also support IPv6 traffic through dual-stack and IPv6-only subnets (available in custom-mode VPC networks only). Broadcast and multicast traffic are not supported within the network.
Network Connectivity Center (NCC) can be used to connect VPC networks via a hub-and-spoke model using VPC spokes, supporting up to 250 VPC spokes per hub.

VPC Subnets

VPC networks do not have any IP address ranges associated with them.
Each VPC network consists of one or more useful IP range partitions called subnets and IP ranges are defined for the subnets.
Subnets are regional resources and each subnet is associated with a region.
A network must have at least one subnet before it can be used.
More than one subnet per region can be created.
VPC Network supports the following subnet creation mode
- Auto mode VPC networks
  - create subnets in each region automatically
  - adds new subnets automatically, if a new region becomes available
  - can be switched to custom mode VPC networks
  - support only IPv4 subnet ranges
- Custom mode VPC networks
  - start with no subnets, giving full control over subnet creation.
  - are more flexible and are better suited for production
  - cannot be switched to auto mode VPC networks
  - support IPv4, dual-stack (IPv4 + IPv6), and IPv6-only subnet configurations
Subnet must have a defined primary IP address range, and any resources created within are assigned an IP address from the defined range.
Subnets can be assigned a secondary IP address range, which is only used by alias IP ranges. This is useful if you have multiple services running on a VM and want to assign each service a different IP address.
Primary IP range of an existing subnet can be expanded by modifying its subnet mask, setting the prefix length to a smaller number.

Subnet Stack Types

IPv4-only subnets — default, supports IPv4 addressing only.
Dual-stack (IPv4 and IPv6) subnets — have both IPv4 and IPv6 address ranges. The IPv6 subnet range is /64 (e.g., fd20:a:b:c::/64).
- IPv6 can be either internal ULA (Unique Local Address) or external GUA (Globally Unique Address)
- Internal ULA requires the VPC network internal IPv6 range to be enabled
IPv6-only subnets — support only IPv6 addressing. Can use DNS64 and NAT64 to access IPv4-only destinations.
IPv6 functionality is available only in Premium Tier networking.
IPv6 addressing is not available in auto mode VPC networks — only custom mode networks support IPv6.

VPC Routes

Routes define paths for packets leaving instances (egress traffic), either inside the network or outside of Google Cloud.
A route consists of
- a single destination prefix in CIDR format (0.0.0.0/0) and
- a single next hop (for e.g. Internet Gateway)
When an instance in a VPC network sends a packet, Google Cloud delivers the packet to the route’s next hop if the packet’s destination address is within the route’s destination range.
Routes are defined at the VPC network level but implemented at each VM instance level.
Each VM instance has a controller that is kept informed of all applicable routes from the network’s routing table. Each packet leaving a VM is delivered to the appropriate next hop of an applicable route based on a routing order. When a route is added or deleted, the set of changes is propagated to the VM controllers by using an eventually consistent design.
Routes are divided into two categories: system-generated and custom.
- system-generated routes
  - default — send traffic from eligible instances to the internet and can be removed or replaced
  - subnet routes — route traffic among its subnets and updated automatically by Google Cloud
  - are applied at the VPC level to all the instances
- custom routes
  - are either static routes created manually or dynamic routes maintained automatically by one or more of the Cloud Routers
  - can be applied to all the instances or specific instance using network tag
Policy-based routes let you direct traffic based on more than just the destination IP address — they can match on source IP, protocol, and port to steer traffic to specific next hops (e.g., for third-party network appliances).

VPC Firewall Rules & Cloud NGFW

Refer blog post @ Google Cloud VPC Firewall Rules

📢 Update (2024-2025): Google Cloud now recommends migrating from legacy VPC firewall rules to Cloud NGFW (Next Generation Firewall) network firewall policies. Cloud NGFW provides:

Hierarchical firewall policies — apply to an entire organization or folders
Global network firewall policies — apply across all regions of a VPC network
Regional network firewall policies — apply to a specific region
Cloud NGFW Standard — FQDN objects, geolocation objects, threat intelligence
Cloud NGFW Enterprise — intrusion prevention (IPS), TLS inspection

A migration tool is available to convert existing VPC firewall rules to global network firewall policies.

VPC Private Access Options

Google Cloud provides several private access options which allow VM instances with internal IP addresses to reach certain APIs and services.
Private Google Access
- allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.
- allows access to the external IP addresses used by App Engine, including third-party App Engine-based services.
- configured on a subnet by subnet basis
- provides following routing options
  - use default route with its next-hop being the default internet gateway, and it provides a path to the default domains, private.googleapis.com, and restricted.googleapis.com.
  - use custom static routes, each having a more specific destination, and each using the default internet gateway next hop.
- Use this option to connect to Google APIs and services without giving the Google Cloud resources external IP addresses.
Private Service Connect (PSC)
- is a capability of Google Cloud networking that allows consumers to access managed services privately from inside their VPC network.
- allows managed service producers to host services in their own separate VPC networks and offer a private connection to their consumers.
- creates a private endpoint with an internal IP address in the consumer’s VPC to access producer services.
- supports access to Google APIs (global and regional), published third-party services, and your own services.
- PSC Endpoints — consumer-side resources for accessing published services or Google APIs via an internal IP.
- PSC Interfaces — allow producer VPCs to initiate connections to consumer VPCs via network attachments.
- Service Connectivity Automation — lets service consumers automate the deployment of connectivity to managed services using service connection policies.
- PSC is the recommended approach for private connectivity to Google Cloud managed services.
Private services access
- is a private connection between the VPC network and a network owned by Google or a third party i.e. service producers
- enables VM instances in the VPC network and the accessed services to communicate exclusively by using internal IP addresses.
- VM instances don’t need Internet access or external IP addresses to reach services that are available through private services access.
- Use this option to connect to specific Google and third-party services without assigning external IP addresses to the Google Cloud and Google or third-party resources.

Refer blog post GCP Shared VPC

VPC Peering

Refer blog post GCP VPC Peering

Network Connectivity Center

Network Connectivity Center (NCC) provides a hub-and-spoke connectivity model for connecting VPC networks.
VPC spokes let you connect two or more VPC networks to an NCC hub so that the networks can exchange subnet routes.
Supports up to 250 VPC spokes per hub and millions of VMs.
Provides smooth workload mobility between VPCs and simplified management of cross-VPC connectivity.
Also supports hybrid spokes (Cloud VPN, Cloud Interconnect, Router Appliance) for connecting on-premises/multi-cloud networks.
NCC is an alternative to VPC Peering for large-scale network topologies, providing centralized management and transitive connectivity.

VPC Flow Logs

VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.
Flow Logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization.
Flow logs can be configured at multiple levels:
- Organization level — enables flow logs for all subnets, VLAN attachments, and Cloud VPN tunnels across the entire organization
- VPC network level — enables for all subnets in a VPC
- Subnet level — enables for a specific subnet
- VLAN attachment level — for Cloud Interconnect traffic
- Cloud VPN tunnel level — for VPN traffic
Flow logs record TCP, UDP, ICMP, ESP, and GRE connections.
With GCP Shared VPC, all Flow logs are in the host project.
Cloud Logging can be used to view the flow logs and it can be exported to any destination that Cloud Logging export supports.
Flow logs are aggregated by the connection from Compute Engine VMs and exported in real-time.
Flow logs can be analyzed using real-time streaming APIs by subscribing to Pub/Sub.
Flow logs are collected for each VM connection at specific intervals (sampling period). All packets collected for a given interval for a given connection are aggregated for a period of time (aggregation interval) into a single flow log entry.
VPC Flow Logs for Cross-Cloud Network — expanded support for logging traffic across multi-cloud and hybrid topologies.
Organization policy constraints can be configured to enforce VPC Flow Logs enablement.

Hybrid Subnets (Preview)

Hybrid Subnets helps migrate workloads to Google Cloud without needing to change any IP addresses.
A hybrid subnet is a single logical subnet that combines a segment of an on-premises network with a subnet in a VPC network.
Enables gradual migration where workloads can reside both on-premises and in Google Cloud on the same subnet during transition.
Useful for lift-and-shift migrations where changing IP addresses is impractical.

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your VMs are running in a subnet that has a subnet mask of 255.255.255.240. The current subnet has no more free IP addresses and you require an additional 10 IP addresses for new VMs. The existing and new VMs should all be able to reach each other without additional routes. What should you do?
1. Use gcloud to expand the IP range of the current subnet.
2. Delete the subnet, and recreate it using a wider range of IP addresses.
3. Create a new project. Use Shared VPC to share the current network with the new project.
4. Create a new subnet with the same starting IP but a wider range to overwrite the current subnet
An IT company has a set of compute engine instances hosted in a VPC. They are not exposed to the internet. These instances now need to install an important security patch. How can the security patch be installed on the instances?
1. Upload to Cloud Storage and enable VPC peering
2. Upload to Cloud Storage and whitelist instance IP address
3. Upload to Cloud Storage and enable Private Google Access
4. Upload to Cloud Source Repository and enable VPC peering
Your security team wants to be able to audit network traffic inside of your network. What’s the best way to ensure they have access to the data they need?
1. Disable flow logs.
2. Enable flow logs.
3. Enable VPC Network logs
4. Add a firewall capture filter.
Your organization needs to provide private connectivity from a VPC to a managed Google service without using external IP addresses. The solution should assign an internal IP address for the connection. What should you use?
1. VPC Network Peering
2. Private Google Access
3. Private Service Connect
4. Cloud VPN
You need to connect 50 VPC networks across different projects in your organization with centralized management and transitive routing. Which solution is most appropriate?
1. Create VPC Peering between all networks
2. Use Shared VPC for all projects
3. Use Network Connectivity Center with VPC spokes
4. Create Cloud VPN tunnels between all networks
You are deploying IPv6 workloads in Google Cloud. Which VPC network mode supports dual-stack subnets?
1. Auto mode VPC networks
2. Custom mode VPC networks
3. Both auto mode and custom mode
4. Legacy networks
Your organization wants to enforce consistent firewall rules across multiple VPC networks in different projects and folders. What should you use?
1. VPC firewall rules in each network
2. Cloud NGFW hierarchical firewall policies
3. Network tags
4. Service accounts

References

Google Cloud Shared VPC – Multi-Project Networking

January 29, 2021 ~ Last updated on : June 28, 2026 ~ jayendrapatil ~ 1 Comment

Shared VPC allows an organization to connect resources from multiple projects to a common VPC network to communicate with each other securely and efficiently using internal IPs from that network.
requires designating a project as a host project and attach one or more other service projects to it.
allows organization administrators to delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while maintaining centralized control over network resources like subnets, routes, and firewalls.
Shared VPC is also referred to as “XPN” in the API and command-line interface.
allows you to
- implement a security best practice of least privilege for network administration, auditing, and access control.
- apply and enforce consistent access control policies at the network level for multiple service projects in the organization while delegating administrative responsibilities
- use service projects to separate budgeting or internal cost centers.

Shared VPC Concepts

GCP Shared VPC - Multiple host projects

Shared VPC connects projects within the same organization. Participating host and service projects cannot belong to different organizations.
Linked projects can be in the same or different folders, but if they are in different folders the admin must have Shared VPC Admin rights to both folders.
Each project in Shared VPC is either a host project or a service project
- A host project contains one or more Shared VPC networks. A Shared VPC Admin must first enable a project as a host project. After that, a Shared VPC Admin can attach one or more service projects to it.
- A service project is any project that has been attached to a host project by a Shared VPC Admin. This attachment allows it to participate in Shared VPC.
A project cannot be both a host and a service project simultaneously. Thus, a service project cannot be a host project to further service projects.
Multiple host projects can be created; however, each service project can only be attached to a single host project.
A project that does not participate in Shared VPC is called a standalone project.
VPC networks in the host project are called Shared VPC networks. Service projects resources can use subnets in the Shared VPC network.
Shared VPC networks can be either auto or custom mode, but legacy networks are not supported.
Shared VPC supports exporting subnets of any stack type (IPv4, IPv6, and dual-stack).
Host and service projects are connected by attachments at the project level.
Subnets of the Shared VPC networks in the host project are accessible by Service Project Admins.
When sharing networks, you can either share all host project subnets (including future ones) or specify individual subnets to share selectively.
Organization policies and IAM permissions work together to provide different levels of access control.
Organization policies enable setting controls at the organization, folder, or project level.

Organization Policy Constraints

Organization Policy constraints provide additional governance over Shared VPC configurations:
- constraints/compute.restrictSharedVpcHostProjects – Limits the set of host projects to which a non-host project can be attached. Applies when a Shared VPC Admin attaches a service project; doesn’t affect existing attachments.
- constraints/compute.restrictSharedVpcSubnetworks – Specifies which Shared VPC subnets a service project can access at the project, folder, or organization level. Applies to new VMs and load balancers only; existing resources are unaffected.
These constraints help enforce centralized governance while allowing delegated administration.

IAM Roles

Administrator (IAM role)	Purpose
Organization Admin `resourcemanager.organizationAdmin`	Organization Admins nominate Shared VPC Admins by granting them appropriate project creation and deletion roles, and the Shared VPC Admin role for the organization. These admins can define organization-level policies, but specific folder and project actions require additional folder and project roles.
Shared VPC Admin `compute.xpnAdmin` + `resourcemanager.projectIamAdmin`	Shared VPC Admins have the Compute Shared VPC Admin and Project IAM Admin roles for the organization or one or more folders. They perform various tasks necessary to set up Shared VPC, such as enabling host projects, attaching service projects to host projects, and delegating access to some or all of the subnets in Shared VPC networks to Service Project Admins. A Shared VPC Admin for a given host project is typically its project owner as well. A Shared VPC Admin can link projects in two different folders only if the admin has the role for both folders. Note: Managing Shared VPC with the Shared VPC Admin role at the folder level is available in General Availability (GA since March 2023).
Service Project Admin `compute.networkUser`	A Shared VPC Admin defines a Service Project Admin by granting an IAM member the Network User role to either the whole host project or select subnets of its Shared VPC networks. Service Project Admins also maintain ownership and control over resources defined in the service projects, so they should have the Instance Admin role in the corresponding service projects. They may have additional IAM roles to the service projects, such as project owner. Project-level permissions: Access to all subnets in the host project (including future subnets). Subnet-level permissions: Access restricted to specific subnets only.
Network Admin `compute.networkAdmin`	Network Admins have full control over all network resources except for firewall rules and SSL certificates.
Security Admin `compute.securityAdmin`	Security Admins manage firewall rules and SSL certificates.

Eligible Resources

Most Google Cloud products and features can be used in Shared VPC service projects.
Use of a Shared VPC network is not mandatory — service projects can still use their own VPC networks.
Existing resources do not automatically use shared network resources when a project is attached as a service project; new resources must be created to use Shared VPC subnets.
Key eligible resources include:
- Compute Engine – VM instances, instance groups, instance templates
- Google Kubernetes Engine (GKE) – Autopilot and Standard clusters (VPC-native required)
- Cloud Run – Via Direct VPC egress or Serverless VPC Access connectors
- Cloud Functions – Via Serverless VPC Access connectors
- App Engine Flexible – Via Serverless VPC Access connectors
- Cloud SQL – Via Private Services Access
- Dataflow – Jobs can specify Shared VPC networks
- Dataproc – Clusters can use Shared VPC subnets
- Cloud Composer – Environments can use Shared VPC
- Internal Load Balancers – All types supported

Serverless Services with Shared VPC

Serverless VPC Access – Allows Cloud Run, Cloud Functions, and App Engine to connect to Shared VPC networks via connectors. GA for Shared VPC since March 2021.
Direct VPC Egress (Recommended) – Available in GA since April 2024, Cloud Run services and jobs can send traffic directly to a Shared VPC network without needing Serverless VPC Access connectors.
- Easier to set up, faster, handles more traffic, and has lower costs than connectors.
- Supports sending traffic from a service project to the host project’s Shared VPC network.
- Google recommends migrating from Serverless VPC Access connectors to Direct VPC egress for improved performance.

Multiple Network Interfaces with Shared VPC

VM instances can connect interfaces other than nic0 to a Shared VPC network (GA since March 2021, including support for instance templates and managed instance groups).
Dynamic NICs (GA since October 2025) – Allows adding or removing network interfaces without restarting or recreating VM instances. Supports up to 16 total interfaces.
Each network interface must point to a different VPC network.

Shared VPC with Firewall Policies

Hierarchical Firewall Policies (GA since February 2021) – Allow creating firewall rules at the organization or folder level that apply across all projects and VPC networks, including Shared VPC networks.
Global Network Firewall Policies (GA since August 2022) – Can be applied to Shared VPC networks for centralized firewall rule management.
Regional Network Firewall Policies (GA since August 2022) – Provide region-specific firewall rules for Shared VPC networks.
These policy types enable centralized security management across all service projects using the Shared VPC network.

Private Service Connect with Shared VPC

Private Service Connect (PSC) enables private connectivity to services without exposing traffic to the public internet.
PSC endpoints can be created in Shared VPC networks and accessed by service projects.
PSC endpoints in a Shared VPC network no longer need to be in the same project as the VMs sending requests (fixed July 2021).
Propagated Connections (GA since February 2025) – Services accessible through PSC endpoints in one VPC spoke can be accessed by other VPC spokes connected to the same Network Connectivity Center hub.
Service Connectivity Automation (GA since October 2023) – Allows service producers to automate PSC connectivity for managed services on behalf of consumers across different projects.

Cloud Interconnect with Shared VPC

Shared VPC can help share the VLAN attachment in a project with other VPC networks.
Shared VPC is preferable if you need to create many projects and would like to prevent individual project owners from managing their connectivity back to the on-premises network.
Host project contains a common Shared VPC network that VMs in service projects can use. Because VMs in service projects use this network, Service Project Admins don’t need to create other VLAN attachments or Cloud Routers in the service projects.
VLAN attachments and Cloud Routers for an Interconnect connection must be created only in the Shared VPC host project.
The combination of a VLAN attachment and its associated Cloud Router is unique to a given Shared VPC network.
Service Project Admins can create VMs in subnets that exist in a host project’s Shared VPC network based on the permissions that they have to the host project.
VMs that use the Shared VPC network can use the custom dynamic routes for VLAN attachments available to that network.
VPC Flow Logs can sample traffic sent through VLAN attachments (GA since January 2024).

Hybrid Subnets with Shared VPC

Hybrid Subnets (GA since April 2026) allow a VPC network to share a CIDR block with a connected on-premises network.
Enables migration of workloads to Google Cloud without changing IP addresses.
Workloads that have migrated can communicate with those remaining on-premises using internal IP addresses.
Particularly useful in Shared VPC environments where multiple service projects need seamless hybrid connectivity during migrations.
After migration is complete, hybrid subnet routing can be disabled to restore normal routing behavior.

Billing

Billing for resources in service projects using a Shared VPC network is attributed to the service project where the resource is located.
Outbound traffic from an instance is attributed to the project containing the instance.
Costs associated with a load balancer are charged to the project containing the load balancer components.
Outbound traffic to VPNs is attributed to the project containing the VPN Gateway (typically the host project).
Traffic from a Shared VPC service project through a VLAN attachment is attributed to the project owning the VLAN attachment.

Quotas and Limits

Shared VPC host projects are subject to standard per-project VPC quotas.
Shared VPC networks are subject to per-network and per-instance limits for VPC networks.
Relationships between host and service projects are governed by limits specific to Shared VPC (e.g., maximum number of service projects per host project).

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your company is building a large-scale web application. Each team is responsible for its own service component of the application
and wants to manage its own individual projects. You want each service to communicate with the others over the RFC1918 address
space. What should you do?
1. Deploy each service into a single project within the same VPC.
2. Configure Shared VPC, and add each project as a service of the Shared VPC project.
3. Configure each service to communicate with the others over HTTPS protocol.
4. Configure a global load balancer for each project, and communicate between each service using the global load balancer IP
  addresses.
Where should you create the Cloud Router instance in a Shared VPC to allow connection from service projects across a new Dedicated Interconnect to your data center?
1. VPC network in all projects
2. VPC network in the IT Project
3. VPC network in the Host Project
4. VPC network in the Sales, Marketing, and IT Projects
Your organization wants to allow different teams to manage their own GKE clusters while using a centrally managed network. The network team needs to control IP allocation and firewall rules. Which approach should you use?
1. Create separate VPC networks for each team and use VPC Peering.
2. Use Shared VPC with a host project managed by the network team and service projects for each team’s GKE clusters.
3. Deploy all clusters in a single project with separate namespaces.
4. Use Cloud VPN to connect each team’s project to a central network.
A Shared VPC Admin wants to restrict which subnets a service project can use for deploying VMs. Which organization policy constraint should be applied?
1. constraints/compute.restrictSharedVpcHostProjects
2. constraints/compute.restrictSharedVpcSubnetworks
3. constraints/compute.restrictVpcPeering
4. constraints/compute.restrictXpnProjectLienRemoval
Your Cloud Run services in a service project need to communicate with resources in a Shared VPC network. What is the recommended approach in 2024+?
1. Create a VPN tunnel between the projects.
2. Use Serverless VPC Access connectors in the host project.
3. Configure Direct VPC egress to the Shared VPC network.
4. Deploy Cloud Run in the host project directly.
Which of the following statements about Shared VPC are correct? (Choose 2)
1. A service project can be attached to multiple host projects simultaneously.
2. A project cannot be both a host project and a service project at the same time.
3. Shared VPC can connect projects across different organizations.
4. Shared VPC supports exporting subnets of any stack type including IPv6 and dual-stack.

Reference

Google Cloud VPC Peering – Cross-Project Networking

January 28, 2021 ~ Last updated on : June 28, 2026 ~ jayendrapatil

Google Cloud VPC Peering

Google Cloud VPC Network Peering allows internal IP address or private connectivity across two VPC networks regardless of whether they belong to the same project or the same organization.
VPC Network Peering enables VPC networks connection, so that workloads in different VPC networks can communicate internally.
VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
Traffic stays within Google’s network and doesn’t traverse public internet.
Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
VPC Network Peering provides following advantages over using external IP addresses or VPNs to connect networks, including:
- Network Latency – connectivity uses only internal addresses and provides lower latency than connectivity that uses external addresses
- Network Security – service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
- Network Cost – Google Cloud charges egress bandwidth or outbound traffic for networks using external IPs to communicate even if the traffic is within the same zone. However, for peered networks as they use internal IPs to communicate and save on those egress costs.
VPC Network Peering is useful in these environments:
- SaaS (Software-as-a-Service) ecosystems in Google Cloud, which can be made available privately across different VPC networks within and across organizations.
- Organizations that have several network administrative domains that need to communicate using internal IP addresses.

VPC Peering Properties

VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environment.
VPC Network Peering supports VPC-native GKE clusters by exchanging subnet routes.
VPC Network Peering supports routes-based GKE clusters when configured to exchange static routes.
Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.
Each side of a peering association is set up independently. Peering will be active only when the configuration from both sides matches. Either side can choose to delete the peering association at any time (in independent mode).
VPC peers always exchange subnet routes that don’t use privately used public IP addresses. Networks must explicitly export privately used public IP subnet routes for other networks to use them and must explicitly import privately used public IP subnet routes to receive them from other networks.
Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network’s dynamic routing mode.
A VPC network can peer with multiple VPC networks (default quota of 25 peerings per network).
IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role (roles/compute.networkAdmin).
Peering traffic (traffic flowing between peered networks) has the same latency, throughput, and availability as private traffic in the same network.
Billing policy for peering traffic is the same as the billing policy for private traffic in the same network.
Peering is allowed with Shared VPC.
An organization policy administrator can use an organization policy to constrain which VPC networks can peer with VPC networks in the organization. Peering connections to particular VPC networks or to VPC networks in a particular folder or organization can be denied.

VPC Peering Connection Modes

VPC Network Peering supports two connection modes that determine how a peering connection is administered:
- Independent Mode (default) – Either network can update or delete the peering connection at any time unilaterally.
- Consensus Mode – Requires agreement from both networks to update or delete the peering connection. Prevents accidental, unilateral changes to network behavior.
When creating a peering connection, both peering configurations must specify the same connection mode.
An existing connection can be changed from independent to consensus mode (both sides must update), but changing from consensus to independent is NOT supported.
Consensus mode is recommended for critical services where accidental deletion of the peering connection would cause a service outage.
In consensus mode:
- Update requests require complementary changes from both sides (e.g., if one side exports custom routes, the peer must import them).
- Deletion requires both sides to submit a deletion request.
- Pending update or deletion requests do not cause downtime—the connection remains active.

IPv6 Support in VPC Peering

VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
To exchange IPv6 routes (both internal and external IPv6 subnet ranges), the peering stack type must be set to IPV4_IPV6 using the --stack-type=IPV4_IPV6 flag.
IPv6 static and dynamic routes exchange also requires --stack-type=IPV4_IPV6 in addition to the --export-custom-routes / --import-custom-routes flags.
VPC Network Peering also provides certain external IPv6 connectivity to destination external IPv6 address ranges of dual-stack/IPv6-only VM instances, external protocol forwarding rules, and external passthrough Network Load Balancer forwarding rules.
IPv6 subnet routes are unique by definition — no two VPC networks can use the same internal or external IPv6 subnet ranges.
IPv6 functionality is available only in Premium Tier.

Route Exchange Options

When a VPC network shares local routes with a peered VPC network, it exports the routes. The peered VPC network can then import the routes.
Subnet routes (using private IPv4 ranges) are always exchanged and cannot be disabled.
Subnet routes using privately used public IPv4 addresses – exported by default, not imported by default. Controlled via --export-subnet-routes-with-public-ip and --import-subnet-routes-with-public-ip flags.
IPv6 subnet routes (internal and external) – not exchanged by default. Enabled by setting --stack-type=IPV4_IPV6.
Static and dynamic IPv4 routes – not exchanged by default. Controlled via --export-custom-routes and --import-custom-routes flags.
IPv6 static/dynamic routes – require both --export-custom-routes / --import-custom-routes AND --stack-type=IPV4_IPV6.
Static routes with network tags or using the default internet gateway as next hop can NEVER be exported or imported.
Policy-based routes are NOT supported for exchange via VPC Network Peering.
Route exchange options can be updated before peering is established or while peering is active.

VPC Peering Restrictions

A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes.

GCP VPC Peering - Overlapping Subnet IP ranges between two peers

A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.
Only VPC networks are supported for VPC Network Peering. Peering is NOT supported for legacy networks.
Two auto mode VPC networks cannot be peered because each auto mode VPC uses subnet IP ranges that fit within 10.128.0.0/9. A custom mode VPC can be peered with an auto mode VPC as long as the custom mode VPC doesn’t have subnets within 10.128.0.0/9.
Subnet route exchange can’t be disabled or subnet routes that can be exchanged cannot be selected. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks.
VPC Network Peering doesn’t provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. It needs to be done using firewall rules.
Transitive peering is NOT supported. For transitive connectivity, use Network Connectivity Center with VPC spokes.
Network tags or service accounts from one peered network in the other peered network CANNOT be used in VPC firewall rules.
However, secure Tags (different from network tags) used in network firewall policies CAN identify sources in peered VPC networks connected to the VPC network to which the Tag is scoped.
Compute Engine internal DNS names created in a network are NOT accessible to peered networks. Use Cloud DNS peering zones or authorize the managed private zone to all peered VPC networks instead.
By default, VPC Network Peering with GKE is supported when used with IP aliases (VPC-native clusters). If you don’t use IP aliases (routes-based clusters), custom routes can be exported so that GKE containers are reachable from peered networks.

Peering Group and Quotas

VPC peering quotas depend on a concept called a peering group.
Each VPC network has its own peering group consisting of itself and all other VPC networks connected to it using VPC Network Peering.
Quotas such as internal forwarding rules, subnet ranges, and instances are evaluated across the entire peering group, not per individual network.
Default quota for VPC peerings within a single VPC is 25 (can be increased via quota request).
Google Cloud allows only one peering operation at a time across peered networks.

Network Connectivity Center (NCC) vs VPC Peering

Network Connectivity Center (NCC) is an alternative to VPC Network Peering for connecting multiple VPC networks, providing a hub-and-spoke model.
Transitivity: NCC provides full bandwidth and transitivity between workload VPCs (VPC spokes). VPC Peering does NOT provide transitivity.
Scale: NCC supports up to 250 VPC spokes per hub. VPC Peering is limited to 25 peerings per VPC by default.
When to use VPC Peering: Simple point-to-point connectivity between two VPCs without transitive requirements.
When to use NCC: Hub-and-spoke topologies, transitive routing across multiple VPCs, enterprise-scale connectivity, or when centralizing network management.
A VPC that is a VPC spoke in NCC can still use VPC Network Peering, provided the peered VPC network isn’t a VPC spoke itself.
NCC VPC spokes support IPv4 and IPv6 subnet route connectivity and IPv4 dynamic route connectivity using hybrid spokes.

Internal Load Balancer Support

Clients in a local VPC network can access internal load balancers in a peer VPC network.
Supported internal load balancers:
- Internal passthrough Network Load Balancers
- Internal proxy Network Load Balancers
- Internal Application Load Balancers
Peered networks can exchange static routes that use internal passthrough Network Load Balancers as next hops.

DNS Support in Peered Networks

Resources in a peered VPC network cannot use Compute Engine internal DNS names created by a local VPC network.
To make DNS names available to resources in a peered VPC network, use one of the following:
- Cloud DNS peering zones – Recommended approach for cross-network DNS resolution.
- Authorize the managed private zone to all peered VPC networks.

GCP Certification Exam Practice Questions

Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).

GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.

GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated

Open to further feedback, discussion and correction.

Your company is working with a partner to provide a solution for a customer. Both your company and the partner organization are using GCP. There are applications in the partner’s network that need access to some resources in your company’s VPC. There is no CIDR overlap between the VPCs. Which two solutions can you implement to achieve the desired results without compromising security?
1. VPC peering
2. Shared VPC
3. Dedicated Interconnect
4. Cloud NAT
Your organization is deploying a single project for 3 separate departments. Two of these departments require network connectivity between each other, but the third department should remain in isolation. Your design should create separate network administrative domains between these departments. You want to minimize operational overhead. How should you design the topology?
1. Create a Shared VPC Host Project and the respective Service Projects for each of the 3 separate departments.
2. Create 3 separate VPCs, and use Cloud VPN to establish connectivity between the two appropriate VPCs.
3. Create 3 separate VPCs, and use VPC peering to establish connectivity between the two appropriate VPCs.
4. Create a single project, and deploy specific firewall rules. Use network tags to isolate access between the departments.
Your organization has 15 VPC networks that all need to communicate with each other. You need full-mesh transitive connectivity with centralized management. What should you use?
1. VPC Network Peering between all 15 networks
2. Network Connectivity Center with VPC spokes
3. Cloud VPN tunnels between all networks
4. Shared VPC with service projects
You have two VPC networks peered together. A critical production service runs across the peering connection. You want to prevent accidental deletion of the peering connection by either network administrator. What should you configure?
1. IAM deny policies on the peering resource
2. Organization policy constraints
3. Consensus mode for the peering connection
4. Read-only access for both network administrators
You have peered two VPC networks and need to enable IPv6 communication between resources in both networks. What must you configure on the peering connection?
1. Enable the --export-custom-routes flag
2. Create IPv6 firewall rules only
3. Set the peering stack type to IPV4_IPV6
4. Enable Private Google Access for IPv6
You want to use network firewall policy rules to identify traffic sources from peered VPC networks. Which identifier can be used to match sources across peered networks?
1. Network tags
2. Service accounts
3. Secure Tags (resource manager tags)
4. IP ranges only

Google Cloud VPC Firewall Rules

📋 Migration Recommended: Move to Network Firewall Policies

Cloud NGFW Tiers

Firewall Policies (Recommended)

Firewall Rule Evaluation Order

Firewall Rule Components

Service Account vs Network Tag Filtering

IAM-Governed Tags (Secure Tags)

Firewall Rules Logging

Firewall Insights

VPC Firewall Rules Migration

GCP Certification Exam Practice Questions

References

Network Connectivity Center

Related Posts

Google Cloud Virtual Private Cloud – VPC

VPC Networks

Specifications

VPC Subnets

Subnet Stack Types

VPC Routes

VPC Firewall Rules & Cloud NGFW

VPC Private Access Options

Shared VPC – VPC Sharing

VPC Peering

Network Connectivity Center

VPC Flow Logs

Hybrid Subnets (Preview)

GCP Certification Exam Practice Questions

References

Google Cloud Shared VPC

Shared VPC Concepts

Organization Policy Constraints

IAM Roles

Eligible Resources

Serverless Services with Shared VPC

Multiple Network Interfaces with Shared VPC

Shared VPC with Firewall Policies

Private Service Connect with Shared VPC

Cloud Interconnect with Shared VPC

Hybrid Subnets with Shared VPC

Billing

Quotas and Limits

GCP Certification Exam Practice Questions

Reference

Google Cloud VPC Peering

VPC Peering Properties

VPC Peering Connection Modes

IPv6 Support in VPC Peering

Route Exchange Options

VPC Peering Restrictions

Peering Group and Quotas

Network Connectivity Center (NCC) vs VPC Peering

Internal Load Balancer Support

DNS Support in Peered Networks

GCP Certification Exam Practice Questions

References