ESEN

← Fine print by exam

Google Cloud · Professional

PCNE · Professional Cloud Network Engineer

Google Cloud Certified - Professional Cloud Network Engineer

Current↗ Official guide🃏 Practice these gotchas

Hybrid private DNS (on-premises ↔ cloud)

Networking● verified 34 days ago◌ no external reviewer

To Type 1 and 2 targets queries come from 35.199.192.0/19; with Type 2, on-premises needs a route to it

Cloud DNS uses the 35.199.192.0/19 range for all customers, and it is the source of queries to Type 1 and Type 2 targets (VPC internal IPs and on-premises over VPN or Interconnect). Type 3 targets use Google Public DNS source ranges, and for Type 4 the range depends on the IPs the name resolves to. For a Type 2 target, on-premises needs a route to 35.199.192.0/19 whose next hop is in the same VPC, through a Cloud VPN tunnel or a Cloud Interconnect VLAN attachment. With BGP that's a custom route advertisement on the Cloud Router's BGP session.

Helps with:PCNEPCA
⚑ Report outdated

See it in the pattern →

Security● verified 34 days ago◌ no external reviewer

With standard routing, a non-RFC 1918 target is queried over the internet

A forwarding zone's default picks the path by target IP: RFC 1918 goes through the VPC, anything else goes over the internet. If your on-premises DNS uses internally reused public IPs or non-RFC 1918 ranges, queries go out to the internet and never arrive. forwarding_path = "private" always forces the VPC.

Helps with:PCNE
⚑ Report outdated

See it in the pattern →

Networking● verified 34 days ago◌ no external reviewer

The inbound policy takes one IP from every subnet, not one per region or two per endpoint

There are no endpoints to size: the policy reserves one internal IP from the primary range of every subnet in the VPC (except special-purpose ones), so a VPC with many subnets has many entry IPs. What matters for the response is the region of the tunnel or attachment the query arrived on, not the subnet's region. Put the policy on the VPC that has the VPN or Interconnect.

Helps with:PCNEACE
⚑ Report outdated

See it in the pattern →

Networking● verified 34 days ago◌ no external reviewer

VPC Network Peering doesn't share private zones; you need peering zones

VPC Network Peering doesn't automatically share DNS information, so a peered VPC doesn't resolve the hub VPC's zones on its own. In hub-and-spoke, each spoke needs a DNS peering zone to the hub, and transitive DNS peering only goes one hop. That's the difference from Azure, where a ruleset links to VNets that aren't even peered.

Helps with:PCNEPCA
⚑ Report outdated

See it in the pattern →

Private object ingestion with expiration (TTL)

Networking● verified 34 days ago◌ no external reviewer

Private Google Access gives reach to Google APIs; filtering the bucket's origin is another control

VM instances that only have internal IP addresses can use Private Google Access to reach Google APIs and services. That solves reachability, not origin filtering. Bucket IP filtering lets you restrict access to the bucket based on client IP ranges and VPC networks, and works alongside IAM.

Helps with:PCNEPCA
⚑ Report outdated

See it in the pattern →

Zero Trust private web API with passwordless PostgreSQL

Networking● verified 34 days ago◌ no external reviewer

Cloud SQL's private IP goes over a VPC peering that isn't transitive

Private services access is implemented with VPC Network Peering to Google's network. It only allows connections from one VPC, and peering doesn't provide transitive routing: another VPC peered with yours can't reach the database. If your topology is hub-and-spoke, consider Private Service Connect instead of PSA.

Helps with:PCNEPCA
⚑ Report outdated

See it in the pattern →