Domain 2 of 6 · Chapter 1 of 5

Network Topologies

Reaching on-premises: VPN or Interconnect

A scenario says "connect our data center to Google Cloud at 50 Gbps, and the traffic must never cross the public internet." That single sentence picks the product: Cloud Interconnect[1], not Cloud VPN[2]. The whole hybrid-to-on-premises decision turns on two questions, throughput and whether the path may be the public internet, and the products line up cleanly against them.

Cloud VPN: IPsec over the public internet

Cloud VPN builds encrypted IPsec tunnels between your on-premises gateway and Google Cloud over the public internet. It is fast to stand up and needs no physical provisioning, which makes it the right first answer for modest bandwidth, for a migration experiment, or for an encrypted link you need this week. The recommended product is HA VPN: when you configure it with two interfaces connected to two peer devices, it carries a 99.99% availability SLA[2] for most topologies; other configurations drop to 99.9%. Classic VPN is the legacy option and only reaches 99.9%, so HA VPN is the right answer for any new high-availability design. The limitation that sends architects to Interconnect is bandwidth: HA VPN throughput is per-tunnel, roughly 1 to 3 Gbps (up to 250,000 packets per second), so you add tunnels to scale, and every byte still rides the shared internet.

Cloud Interconnect: a private physical circuit

Cloud Interconnect gives you a private link whose traffic flows directly between networks, not through the public internet[1]. It comes in two forms that differ only in who owns the last mile:

  • Dedicated Interconnect runs your own 10-Gbps, 100-Gbps, or 400-Gbps circuits[3] into a Google colocation facility, and you can bundle up to 8 circuits per Interconnect for higher aggregate capacity. You carve it into VLAN attachments sized from 50 Mbps to 50 Gbps. Choose it when you can reach a colocation facility and want the highest, most cost-effective private bandwidth.
  • Partner Interconnect uses a supported service provider[4] to bridge the last mile when you cannot reach a Google facility directly, with VLAN attachments from 50 Mbps to 50 Gbps.

Both keep traffic off the internet and earn an availability SLA only when the topology meets the redundancy requirements: 99.9% needs two connections in the same metro but different edge availability domains, and 99.99% needs four connections, two in each of two different metros. The trade against VPN is setup time and physical dependency: Interconnect must be provisioned, VPN can be live in an afternoon.

May traffic crossthe public internet?YesNo, must be privateHA VPNIPsec, 99.99% SLA (2 interfaces)Can you reach a Google colocation facility?YesNoDedicated Interconnectprivate, 10/100/400 Gbps circuitsPartner Interconnectvia provider, 50 Mbps to 50 Gbps
On-premises connectivity choice, modeled on the Google Cloud hybrid-connectivity product-selection guide.

Cross-cloud and Google-to-Google connectivity

When the far side is not your data center, the product changes. Reaching another public cloud is Cross-Cloud Interconnect[5]; connecting Google networks to each other is VPC Network Peering, Network Connectivity Center, or Shared VPC. Each solves a distinct problem, so name the problem first and the product follows.

Cross-Cloud Interconnect: Google Cloud to another cloud

Cross-Cloud Interconnect establishes a dedicated physical connection between Google Cloud and another cloud provider[5], with Google provisioning and managing the link up to the remote provider's network. Port sizes are 10 Gbps and 100 Gbps (and up to 400 Gbps for AWS and OCI), and the supported providers are AWS, Microsoft Azure, OCI, and Alibaba Cloud. This is the product for a multicloud architecture; do not substitute Dedicated Interconnect, which terminates at your own colocation equipment, or Cloud VPN, which is internet-bound and bandwidth-limited.

Connecting Google networks: three models, three jobs

The three GCP-to-GCP designs are easy to confuse because they all "connect networks," so anchor each to the job only it does.

VPC Network Peering links exactly two VPC networks and makes them exchange subnet routes[6] so resources reach each other over internal IPs with same-network latency and throughput. Three constraints decide exam questions:

  • It is non-transitive. If net-a peers with net-b and net-a peers with net-c, that does not connect net-b and net-c. Each pair needs its own peering, which is why a full mesh of many networks becomes unmanageable.
  • It exchanges routes only. Peered networks stay administratively separate[6], and peering does not exchange firewall rules or policies; each network keeps its own IAM and firewalls.
  • Ranges cannot overlap. No subnet range may match, contain, or fit within a subnet range in the peered network.

Network Connectivity Center (NCC) is the answer when more than two networks must all reach each other. NCC is an orchestration framework with a hub-and-spoke model[7]: spokes attached to a central hub communicate transitively through it, which is exactly the connectivity VPC Peering cannot provide. A spoke can be a VPC network or a hybrid link (an HA VPN tunnel, a Cloud Interconnect VLAN attachment, or a router appliance), so one hub becomes the backbone for VPC-to-VPC, on-premises, and multicloud traffic at once.

Shared VPC is a different kind of thing: it does not connect separate networks, it puts many projects onto one network. A host project owns the Shared VPC network[8] and its subnets, routes, and firewalls; service projects attach to it and deploy resources that use internal IPs from that one network. A service project attaches to exactly one host project, and both must sit in the same organization. The point is administrative: a central network team controls the network while application teams stay out of it, the least-privilege split the exam rewards.

The one-line test: two networks and a simple link, use Peering; many networks needing any-to-any reachability, use NCC; many projects sharing one centrally-run network, use Shared VPC.

VPC Peering: non-transitivenet-anet-bnet-cnet-b to net-c: no pathNCC hub-and-spoke: transitiveHubVPC spokeVPC spokeVPC spokeall spokes reach each other via the hub
VPC Peering connects two networks and is non-transitive; Network Connectivity Center's hub-and-spoke model gives transitive any-to-any reachability.

Load balancing for cloud, internet, and cloud-adjacent access

Pick a load balancer by answering three questions in order: which OSI layer, what geographic reach, and who the clients are. Google Cloud's whole load-balancing taxonomy[9] follows that order, so once you can place a workload on those three axes the product is decided.

Axis 1: layer

The first split is the protocol layer. Application Load Balancers operate at Layer 7: they understand HTTP and HTTPS and can route by host, URL path, and headers, terminate TLS, and apply content-based rules. Network Load Balancers operate at Layer 4: they handle TCP, UDP, and other IP protocols without reading the application payload. So an HTTP API behind path-based routing wants an Application Load Balancer; a database protocol or a UDP game server wants a Network Load Balancer.

Network Load Balancers split once more on how they handle the connection. A proxy Network Load Balancer terminates the client connection and opens a new one to the backend (useful for TLS offload on non-HTTP traffic). A passthrough Network Load Balancer forwards packets without terminating, so the backend sees the original client source IP, which matters when the application needs the real client address.

Axis 2: reach (global or regional)

Each type is offered as global or regional. A global load balancer spreads backends across regions; the global external Application Load Balancer fronts worldwide backends behind a single anycast IP address[9] on the Premium network tier, so one address serves users on the closest healthy backend. A regional load balancer keeps backends in one region, the right choice when data residency or a single-region service constrains the design.

Axis 3: exposure (external or internal)

The last axis is who reaches it. An external load balancer takes traffic from the public internet. An internal load balancer serves clients inside the VPC, and also cloud-adjacent on-premises clients reaching it over Cloud Interconnect or HA VPN, exactly the access pattern this domain's blueprint calls out for cloud-adjacent services. So an internal Application Load Balancer is how an on-premises client, arriving over Interconnect, reaches an HTTP service in your VPC by an internal address.

Axis 1: layerApplication LBLayer 7: HTTP / HTTPSNetwork LBLayer 4: TCP / UDPProxy NLBterminates connectionPassthrough NLBpreserves client source IPAxis 2: reachGlobalmulti-region backendsRegionalAxis 3: exposureExternalinternet-facingInternalVPC + cloud-adjacent clients
Cloud Load Balancing decomposes into three ordered axes: layer, then reach, then exposure.

Security protection and private service access

Network security in a VPC is layered, and the exam tests where each control lives. The base layer is the VPC firewall[10]; above it sit organization-wide policies; alongside it, Private Service Connect removes the need to open the internet at all.

Stateful firewall rules and the implied baseline

VPC firewall rules are stateful: when a connection is allowed in one direction, the return traffic for that connection is automatically allowed[10], so you do not write a separate rule for replies. Every network starts from two implied rules you cannot delete: an implied allow-egress that lets instances send outbound to any destination, and an implied deny-ingress that blocks all inbound until a rule permits it. Rules carry a priority in the range 0 to 65535 where a lower number wins, defaulting to 1000 when you do not set one. Firewall rules are scoped to a single VPC network and are not shared across networks, even peered ones, which is why VPC Peering exchanges routes but never firewalls.

Org-wide control: hierarchical firewall policies

When a control must apply across many networks (a company-wide block, a baseline allow for health checks), per-VPC rules do not scale. Hierarchical firewall policies[11] attach at the organization or folder level and apply to every VPC beneath that node, giving central security teams enforcement that a project owner cannot override. Use them for governance baselines; keep per-VPC rules for network-specific needs.

Private access to services with Private Service Connect

Intrusion and access control are not only about firewalls; the strongest control is to never expose a service publicly. Private Service Connect (PSC)[12] lets a consumer reach managed services and Google APIs (such as Cloud Storage and BigQuery) over internal IP addresses inside their own VPC, with traffic staying entirely within Google Cloud, no public internet path and no VPC peering required. It is how you give an application private access to a published service or a Google API without widening the attack surface, which is the access-control answer the blueprint pairs with firewalls.

Exam-pattern recognition

PCA network questions are usually scenario stems where the right product hides behind one decisive phrase. Map the phrase to the product and most distractors fall away.

Stem signals to the right answer

The stem emphasizes... Right answer Why the obvious distractor is wrong
High bandwidth to on-prem, must not cross the internet Dedicated Interconnect VPN rides the public internet and is bandwidth-limited
Encrypted link to on-prem, needed fast, modest bandwidth HA VPN Interconnect needs physical provisioning, slower to deliver
Connect Google Cloud to AWS or Azure Cross-Cloud Interconnect Dedicated Interconnect terminates at your own colo, not another cloud
Many VPCs must all reach each other Network Connectivity Center VPC Peering is non-transitive, so a mesh does not scale
Central team runs one network, many app teams deploy into it Shared VPC Peering keeps networks administratively separate, not centrally run
Reach a managed service or Google API privately, no peering Private Service Connect A public endpoint or peering widens exposure unnecessarily
Route HTTP by URL path / host across regions Global external Application Load Balancer A Network Load Balancer is Layer 4 and cannot route by path
Preserve the client source IP for a TCP service Passthrough Network Load Balancer A proxy LB terminates the connection and hides the source IP
On-prem client over Interconnect reaches an HTTP app in the VPC Internal Application Load Balancer An external LB faces the internet, not cloud-adjacent clients

Three traps to internalize

  1. VPC Peering is non-transitive. Peering A-B and A-C never connects B and C, and peering never exchanges firewall rules. When the scenario needs any-to-any across more than two networks, the answer is Network Connectivity Center, not more peerings.
  2. Match the far side to the product. On-premises means Cloud Interconnect or HA VPN; another public cloud means Cross-Cloud Interconnect. Choosing Dedicated Interconnect to reach AWS is the classic miss.
  3. Application LB is Layer 7 only. If the traffic is not HTTP or HTTPS, or the app must see the real client IP, it is a Network Load Balancer (passthrough for source-IP preservation), not an Application Load Balancer.

Hybrid and cross-cloud connectivity: which product when

DimensionCloud VPN (HA VPN)Dedicated InterconnectPartner InterconnectCross-Cloud Interconnect
Far sideOn-premisesOn-premisesOn-premisesAnother cloud (AWS/Azure/OCI/Alibaba)
PathIPsec over public internetPrivate physical circuitPrivate, via service providerPrivate physical link to other cloud
BandwidthModest, per-tunnel10 or 100 Gbps circuits50 Mbps to 50 Gbps per VLAN10/100 Gbps (up to 400 on AWS/OCI)
Availability SLA99.99% (two interfaces)End-to-end, up to 99.99% with redundancyUp to 99.99% with redundancy; partial provider-dependentUp to 99.99% with redundant pairs
Best forQuick, encrypted, low bandwidthHighest private bandwidth, colo accessNo colo facility accessConnecting to another cloud provider

Decision tree

Is the far sideanother cloud provider?YesNo (on-premises)Cross-Cloud InterconnectAWS / Azure / OCI / AlibabaMust traffic stay off the internet?NoYes, must be privateHA VPNIPsec, 99.99% SLA (2 interfaces)Can you reach a Google colocation facility?YesNoDedicated Interconnectprivate, 10/100/400 Gbps circuitsPartner Interconnectvia provider, 50 Mbps to 50 Gbps
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Cloud VPN runs over the public internet; Cloud Interconnect is a private link

The on-premises connectivity choice splits first on the path. Cloud VPN builds encrypted IPsec tunnels across the public internet, so it is quick to deploy and needs no physical gear, but bandwidth is per-tunnel and limited. Cloud Interconnect carries traffic over a private physical circuit that never touches the internet, giving far higher throughput at the cost of physical provisioning. When a scenario forbids internet transit or demands tens of gigabits, the answer is Interconnect; when speed-to-deploy and encryption matter more than raw bandwidth, it is VPN.

Trap Reaching for Cloud VPN when the requirement says traffic must not cross the public internet; VPN tunnels are internet-bound, only Interconnect keeps the path private.

Use HA VPN and build two interfaces for the 99.99% SLA

HA VPN is the recommended Cloud VPN product for new designs; Classic VPN is the legacy option and only reaches a 99.9% SLA. HA VPN earns a 99.99% availability SLA for most topologies when configured with two interfaces connected to two peer devices; other configurations drop to 99.9%. Throughput is per-tunnel, roughly 1 to 3 Gbps (up to 250,000 packets per second), so you add tunnels to scale, which is why VPN suits modest bandwidth and Interconnect wins for tens of gigabits.

Trap Choosing Classic VPN for a new high-availability connection; it tops out at a 99.9% SLA, while a two-interface HA VPN reaches 99.99%.

1 question tests this
Dedicated Interconnect needs a colocation facility; Partner Interconnect uses a service provider

Both forms of Cloud Interconnect give a private path, and they differ only in who owns the last mile. Dedicated Interconnect runs your own 10-Gbps or 100-Gbps circuits into a Google colocation facility and is the most cost-effective choice for high bandwidth when you can reach one. Partner Interconnect uses a supported service provider to bridge the gap when you cannot reach a Google facility, with VLAN attachments from 50 Mbps to 50 Gbps. The deciding question is physical reach to a colocation facility.

Trap Recommending Dedicated Interconnect for an organization with no access to a Google colocation facility; that gap is exactly what Partner Interconnect exists to cover.

Dedicated Interconnect circuits are 10, 100, or 400 Gbps; VLAN attachments scale 50 Mbps to 50 Gbps

Dedicated Interconnect provisions physical circuits at 10 Gbps, 100 Gbps, or 400 Gbps, and you can bundle up to 8 circuits per Interconnect for higher aggregate capacity. You then carve each circuit into VLAN attachments sized anywhere from 50 Mbps to 50 Gbps, which is how you map the physical capacity to individual VPC networks. Knowing the circuit sizes separates Interconnect (tens to hundreds of gigabits) from VPN (a few gigabits per tunnel) in a bandwidth question.

Cross-Cloud Interconnect connects Google Cloud to another cloud, not to on-premises

When the far side is AWS, Microsoft Azure, OCI, or Alibaba Cloud rather than your data center, the product is Cross-Cloud Interconnect: a dedicated physical link that Google provisions to the other provider's network, at 10 Gbps or 100 Gbps (up to 400 Gbps on AWS and OCI). It is the multicloud answer. Dedicated Interconnect terminates at your own colocation equipment for on-premises reach, and VPN is internet-bound and bandwidth-limited, so neither fits a cloud-to-cloud requirement.

Trap Choosing Dedicated Interconnect to link Google Cloud to AWS; Dedicated Interconnect reaches your own colo, while Cross-Cloud Interconnect is the product built to land in another cloud provider.

Direct and Carrier Peering reach Google APIs and Workspace, not VPC internal IPs

Direct Peering and Carrier Peering connect your network to Google's edge to reach Google APIs and Google Workspace, but they give no access to VPC resources over internal IPs and carry no SLA. So if a scenario only needs Workspace or public Google API access, peering can suffice without standing up Interconnect or VPN. If it needs to reach resources inside a VPC, peering is the wrong tool; use Cloud Interconnect or HA VPN instead.

Trap Using Direct or Carrier Peering to reach VM instances inside a VPC by internal IP; peering only reaches Google APIs and Workspace, with no VPC access and no SLA.

VPC Network Peering is non-transitive

VPC Network Peering links exactly two VPC networks and exchanges their subnet routes so resources communicate over internal IPs at same-network latency. The defining limitation is that peering is not transitive: if net-a peers with net-b and net-a peers with net-c, net-b and net-c still cannot reach each other. Every pair needs its own peering, so a many-network mesh becomes unmanageable, which is precisely when you move to Network Connectivity Center.

Trap Assuming that peering net-a to net-b and net-a to net-c connects net-b and net-c; peering is non-transitive, so that path does not exist.

4 questions test this
VPC Peering exchanges routes only, never firewall rules, and forbids overlapping ranges

Peered VPC networks stay administratively separate: peering exchanges subnet routes but does not share firewall rules, policies, or IAM, so each network keeps its own controls. Subnet ranges also cannot overlap, no range may match, contain, or fit within a range in the peered network. These constraints explain why peering is a routing link, not a merged network, and why security must be configured per network on both sides.

Trap Expecting firewall rules to carry across a peering so a rule on one side protects the other; peering exchanges routes only, each network enforces its own firewalls.

3 questions test this
Network Connectivity Center gives transitive any-to-any connectivity via hub-and-spoke

When more than two networks must all reach each other, Network Connectivity Center (NCC) is the answer. NCC is a hub-and-spoke orchestration framework: spokes attach to a central hub and communicate transitively through it, supplying the any-to-any reachability that VPC Peering cannot. A spoke can be a VPC network or a hybrid link such as an HA VPN tunnel, a Cloud Interconnect VLAN attachment, or a router appliance, so one hub becomes the backbone for VPC-to-VPC, on-premises, and multicloud traffic together.

Trap Adding more VPC peerings to give many networks full any-to-any reachability; peering is non-transitive, so the mesh grows quadratically. NCC's hub provides transitivity instead.

Shared VPC puts many projects on one network run by a host project

Shared VPC does not connect separate networks; it places resources from many projects onto one VPC owned by a host project. The host project owns the subnets, routes, and firewalls, and service projects attach to it and deploy resources that use internal IPs from that shared network. The purpose is administrative separation of duties: a central network team controls the network while application teams deploy into it without managing it, the least-privilege split for enterprise networking.

Trap Reaching for VPC Peering when the requirement is one centrally-administered network for many project teams; peering keeps networks separately administered, while Shared VPC centralizes control under a host project.

1 question tests this
A service project attaches to exactly one host project, within the same organization

Shared VPC has firm structural limits worth memorizing. A service project can attach to only one host project at a time, a project cannot be both a host and a service project, and all projects must belong to the same organization. Establishing the configuration requires the Shared VPC Admin role at the organization level. These constraints often decide whether a proposed Shared VPC layout is even valid.

Application Load Balancers are Layer 7; Network Load Balancers are Layer 4

Cloud Load Balancing splits first on protocol layer. Application Load Balancers operate at Layer 7 and route HTTP and HTTPS by host, path, and headers, and can terminate TLS. Network Load Balancers operate at Layer 4 for TCP, UDP, and other IP protocols without reading the payload. So path-based or host-based HTTP routing requires an Application Load Balancer, while a raw TCP or UDP service requires a Network Load Balancer.

Trap Putting an Application Load Balancer in front of non-HTTP TCP or UDP traffic; Application LBs only handle HTTP and HTTPS, so Layer 4 traffic needs a Network Load Balancer.

Use a passthrough Network Load Balancer to preserve the client source IP

Network Load Balancers come in two flavors. A passthrough Network Load Balancer forwards packets without terminating the connection, so the backend sees the original client source IP, which matters when the application logs or authorizes by client address. A proxy Network Load Balancer terminates the client connection and opens a new one to the backend, which is what you want for TLS offload on non-HTTP traffic but which hides the real source IP behind the load balancer.

Trap Choosing a proxy Network Load Balancer when the backend must see the real client IP; the proxy terminates the connection, so only a passthrough load balancer preserves the source IP.

The global external Application Load Balancer fronts worldwide backends behind one anycast IP

Load balancers are offered as global or regional. The global external Application Load Balancer serves backends in regions around the world behind a single anycast IP address on the Premium network tier, so one address routes each user to the nearest healthy backend. A regional load balancer keeps backends in one region, which is the right call when data residency or a single-region service constrains the design. Choose global for worldwide reach, regional when geography is pinned.

Use an internal load balancer for VPC and cloud-adjacent on-premises clients

The last load-balancer axis is exposure. An external load balancer accepts traffic from the public internet; an internal load balancer serves clients inside the VPC and cloud-adjacent on-premises clients reaching it over Cloud Interconnect or HA VPN. So an on-premises client arriving over Interconnect that needs to reach an HTTP service in your VPC by an internal address wants an internal Application Load Balancer, not an external one.

Trap Exposing a service that only serves VPC and on-premises clients through an external load balancer; an internal load balancer keeps it off the internet and still serves cloud-adjacent clients over Interconnect or VPN.

VPC firewall rules are stateful, so return traffic is allowed automatically

VPC firewall rules are stateful: when a connection is allowed in one direction, the return traffic for that connection is permitted automatically, so you never write a separate rule for replies. The network also ships with two implied rules you cannot delete, an implied allow-egress that lets instances reach any destination and an implied deny-ingress that blocks all inbound until a rule allows it. Rules carry a priority from 0 to 65535 where lower wins, defaulting to 1000.

Trap Writing a separate inbound rule to permit the replies to an allowed outbound connection; the firewall is stateful, so return traffic on an established connection is already allowed.

Apply org-wide controls with hierarchical firewall policies, not per-VPC rules

VPC firewall rules are scoped to a single network and are not shared across networks, even peered ones. When a control must apply across many networks at once, such as a company-wide block or a baseline health-check allow, hierarchical firewall policies attach at the organization or folder level and apply to every VPC beneath that node, which a project owner cannot override. Use hierarchical policies for centralized governance; keep per-VPC rules for network-specific needs.

Trap Trying to enforce an organization-wide firewall baseline by editing each VPC's own rules; that does not scale or prevent override. Hierarchical firewall policies at the org or folder level apply to every network below.

1 question tests this
Private Service Connect reaches managed services and Google APIs over internal IPs, no peering

The strongest access control is to never expose a service publicly. Private Service Connect (PSC) lets a consumer reach managed services and Google APIs such as Cloud Storage and BigQuery over internal IP addresses inside their own VPC, with traffic staying entirely within Google Cloud, no public internet path and no VPC peering required. It is how you give an application private access to a published service or a Google API without widening the attack surface.

Trap Setting up VPC Peering or a public endpoint to let a VPC consume a managed service privately; Private Service Connect gives that private internal-IP access without peering and without exposing the service to the internet.

1 question tests this
Set the VPC to Global dynamic routing mode to reach regions other than the Cloud Router's

A Cloud Router in Regional dynamic routing mode (the default) only advertises and learns routes for subnets in its own region. When VLAN attachments or VPN tunnels must carry traffic to or from resources in a different region than the Cloud Router, switch the VPC network to Global dynamic routing mode so routes propagate across all regions.

Trap Regional mode is the default, so cross-region Interconnect/VPN silently fails until you flip the whole VPC to Global — it is a VPC-wide setting, not a per-attachment one.

5 questions test this
Cloud Router load-balances across attachments only with equal MED in the same region; lower MED wins

Advertised route priority is the BGP MED value, and a lower MED is preferred. To spread egress across multiple Interconnect VLAN attachments or VPN tunnels, place them in the same region and advertise the same prefix with identical MED so Cloud Router uses ECMP (a five-tuple hash). For active-passive failover instead, give the primary a lower MED and the standby a higher MED.

Trap ECMP hashes per flow, so a single TCP stream always pins to one tunnel — lopsided traffic is not a misconfiguration; test with multiple concurrent flows.

4 questions test this
Cloud Router needs a private ASN different from the peer; Partner Interconnect forces ASN 16550

For HA VPN and Dedicated Interconnect, the Cloud Router must use a private ASN (16-bit 64512-65534 or 32-bit 4200000000-4294967294) that differs from the peer ASN, since Google Cloud only runs eBGP. Partner Interconnect is the exception: its Cloud Router must use the Google-owned ASN 16550.

Trap Partner Interconnect rejects a private ASN — 16550 is mandatory there, unlike Dedicated Interconnect which takes your private ASN.

4 questions test this
Network tags are VPC-local; use service accounts or secure tags for cross-network and hierarchical targeting

Network tags in a VPC firewall rule resolve only to instances in that same VPC, so they never match VMs reached through VPC Peering, and hierarchical firewall policies reject network tags entirely. To target VMs in those cases, use target service accounts or IAM-governed secure tags instead.

Trap A peered VM carrying the same network-tag string is not matched by the other network's rules, and a 'forgot the target tag' allow rule silently lets a lower-priority deny-all win.

4 questions test this

Also tested in

References

  1. Choosing a Network Connectivity product
  2. Cloud VPN overview
  3. Dedicated Interconnect overview
  4. Partner Interconnect overview
  5. Cross-Cloud Interconnect overview
  6. VPC Network Peering
  7. Network Connectivity Center overview
  8. Shared VPC
  9. Cloud Load Balancing overview
  10. VPC firewall rules
  11. Hierarchical firewall policies overview
  12. Private Service Connect