ESEN

← Fine print by exam

Google Cloud · Professional

PCA · Professional Cloud Architect

Google Cloud Certified - Professional Cloud Architect

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.

⚑ 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.

⚑ Report outdated

See it in the pattern →

Private object ingestion with expiration (TTL)

Cost● verified 34 days ago◌ no external reviewer

Soft delete is on by default (7 days) and makes ephemeral data more expensive

Every bucket has soft delete with 7-day retention unless you change it. An object that lives one hour is billed for that hour plus 7 days of soft delete. In a TTL ingestion bucket that can multiply cost. The module sets it to 0 (disabled) by default and exposes it as an explicit variable.

⚑ Report outdated

See it in the pattern →

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.

⚑ Report outdated

See it in the pattern →

Zero Trust private web API with passwordless PostgreSQL

IAM● verified 34 days ago◌ no external reviewer

In Postgres, a Service Account's IAM user drops ".gserviceaccount.com"

The database user name is the SA email without the .gserviceaccount.com suffix (e.g. api@project.iam), due to PostgreSQL's name length limit. If you create it with the full email, login fails with an error that looks like a permissions problem.

⚑ Report outdated

See it in the pattern →

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.

⚑ Report outdated

See it in the pattern →

IAM● verified 34 days ago◌ no external reviewer

"Internal" is a network control; authentication is separate IAM

With internal ingress, Cloud Run only accepts requests from sources such as VPCs in the same project, a VPC SC perimeter or an internal Application Load Balancer, and from products such as Cloud Scheduler, Cloud Tasks, Eventarc, Pub/Sub or Workflows if they're in the same project or perimeter and use the default run.app URL. Other sources, including the internet, can't reach it. But IAM authentication still applies: the client must present an ID token and its service account needs roles/run.invoker.

⚑ Report outdated

See it in the pattern →