Google PCNE: Private Connectivity to Google and Managed Services — Study Guide

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Part of the Google Professional Cloud Network Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Private connectivity to Google and managed services encompasses patterns that let workloads communicate with Google APIs, Google-managed producer networks, and third‑party services without using public IPs. The goals are to reduce data‑exfiltration risk, simplify compliance, and improve predictability by keeping traffic on private paths. Core building blocks include Private Google Access (and restricted endpoints), Private Services Access (for private IPs to Google‑managed services), Private Service Connect (for producer‑consumer private service publishing and consumption, including Google APIs), VPC Service Controls (data perimetering), Cloud NAT (private outbound to the public internet), and DNS mapping for deterministic endpoint selection.

Design success hinges on three decisions:

Which private access mechanism matches the service and security model (PGA vs PSC for Google APIs, PSA vs PSC for managed or partner services).
How DNS should resolve service names to private targets without breaking unsupported services.
How routing and perimeter policy interact so traffic remains private end‑to‑end under failure or change.

Failure modes commonly stem from route selection, DNS order, regional scope of endpoints, or perimeter rules silently denying calls. Validate each layer: name resolution, route, firewall, endpoint health, and service policy.

Private Google Access, restricted endpoints, and endpoint selection

Private Google Access (PGA) enables VMs and GKE nodes without external IPs to reach Google APIs and services using the Google anycast VIPs over the VPC’s default internet gateway, not over Cloud NAT. It is enabled per subnet.

Endpoints:
- private.googleapis.com (199.36.153.8/30): full Google APIs surface.
- restricted.googleapis.com (199.36.153.4/30): subset of APIs compatible with VPC Service Controls. Use this when you enforce service perimeters.
DNS mapping approaches:
- Keep default public names and let clients access public DNS. This works if you permit egress via Cloud NAT, but it weakens data‑exfiltration controls.
- Override specific API hostnames in a Cloud DNS private zone for googleapis.com with CNAMEs to restricted.googleapis.com (or private.googleapis.com) to force private resolution per service. Example: create a private zone googleapis.com and add storage.googleapis.com CNAME restricted.googleapis.com.
Routing considerations:
- PGA requires a route to the default internet gateway. If you send 0.0.0.0/0 to a third‑party NGFW, add explicit host routes so Google API VIPs use the default internet gateway: gcloud compute routes create restricted-apis
  –network=VPC –destination-range=199.36.153.4/30
  –next-hop-gateway=default-internet-gateway
- Failure mode: If these host routes are missing, instances without external IPs can’t reach APIs when a 0.0.0.0/0 next‑hop is a firewall instance.
Subnet configuration: gcloud compute networks subnets update SUBNET
–region=REGION –enable-private-ip-google-access

Trade‑offs:

restricted.googleapis.com reduces exfiltration risk but some APIs are unavailable.
PGA traffic bypasses Cloud NAT, so NAT logging won’t show it. Use VPC Flow Logs on the subnet.

For on‑prem clients, you can provide private access to Google APIs either by advertising 199.36.153.4/30 and/or 199.36.153.8/30 to on‑prem over Cloud VPN/Interconnect with next hop default internet gateway in the VPC, or by exposing PSC endpoints (see below) and mapping on‑prem DNS to those endpoints.

Private Services Access and Private Service Connect

Private Services Access (PSA) provides private IP connectivity to Google‑managed producer networks that host services such as Cloud SQL (private IP) and Memorystore. You allocate an RFC1918 range in your VPC for Google to use and establish a peering connection to the service producer network.

Setup pattern:
- Reserve an address range for VPC peering: gcloud compute addresses create google-managed-services-range
  –global –purpose=VPC_PEERING –prefix-length=24 –network=VPC
- Establish the private connection: gcloud services vpc-peerings connect
  –service=servicenetworking.googleapis.com –network=VPC
  –ranges=google-managed-services-range
- Provision the managed service with private IP.
Operational notes:
- The range must be large enough for all instances and must not overlap existing ranges.
- The peering is not transitive; traffic must originate from the peered VPC (on‑prem can reach through the VPC if routing allows).
- Changing or shrinking the range later is disruptive; plan capacity.

Private Service Connect (PSC) extends private connectivity to:

Google APIs (consumer creates endpoints with private IPs in a subnet, and DNS maps API names to those IPs).
Partner and SaaS services published via service attachments.
Your own services published privately to other projects or organizations via service attachments.

Producer‑consumer model:

Producer publishes a service attachment in a region, backed by an internal load balancer. The producer can require consumer project/org allowlists and specify connection quotas.
Consumer creates a PSC endpoint (forwarding rule) in the same region, targeting the producer’s service attachment. The endpoint gets an IP from the chosen subnet.

Design constraints and trade‑offs:

PSC is regional; deploy per region close to consumers. Use DNS policies or weighted records to steer nearby clients and provide failover.
There’s no transitivity through PSC; consumers can’t chain services through an endpoint.
Source IP is not preserved end‑to‑end across PSC; design producer‑side controls with this in mind (for example, rely on identity or application‑level authorization).

Common failure modes:

Producer ILB health checks failing cause PSC connections to be refused.
Consumer endpoint created in a different region than the service attachment.
Producer deny policy or missing project allowlist blocks connections.
DNS not pointing at the endpoint IP, or overlapping private zones resolving to the wrong destination.

VPC Service Controls, perimeters, ingress/egress, and DNS mapping

VPC Service Controls (VPC‑SC) define service perimeters around Google‑managed resources to mitigate data exfiltration. Inside a perimeter, requests to protected services must originate from in‑scope projects and satisfy any configured access levels.

Perimeters:
- Standard perimeters protect projects hosting data (for example, BigQuery, Cloud Storage).
- Perimeter bridges allow limited interaction between otherwise isolated perimeters.
- Ingress rules grant specific access from outside the perimeter (for example, from CI/CD or monitoring projects).
- Egress rules restrict which external services or projects inside Google Cloud can be called.
Endpoint selection:
- Use restricted.googleapis.com to limit API calls to VPC‑SC‑compatible services and avoid accidental calls to public endpoints that are not perimeter‑aware.
- PSC for Google APIs offers stronger control by keeping traffic on private IPs and enabling regional affinity, but still requires perimeter configuration for authorization.
DNS and naming:
- Implement split‑horizon DNS with Cloud DNS private zones so internal clients resolve API names to private targets.
- Prefer per‑service records or CNAMEs to restricted.googleapis.com rather than wildcarding all of googleapis.com, which can break services that must remain public.
- For PSC, publish A records pointing to each endpoint’s IP. Use separate zones per environment to prevent accidental cross‑env consumption.

Pitfalls:

Using Cloud NAT to reach public googleapis.com can bypass VPC‑SC intent unless perimeter rules explicitly constrain egress; pair NAT with restricted DNS or PSC.
Some APIs have multiple hostnames (for example, JSON vs XML endpoints); ensure your DNS mapping covers all names your clients use.
Perimeter misconfiguration fails closed; monitor Access Transparency and VPC‑SC logs to detect denials.

Outbound patterns, hybrid access, and troubleshooting

Outbound patterns for private workloads:

Google APIs only: Enable PGA and map DNS to restricted.googleapis.com, or deploy PSC for Google APIs and map DNS to the endpoint IPs.
Internet and SaaS: Use Cloud NAT for instances without external IPs. Size NAT for peak concurrent connections and ports; monitor for port exhaustion.
Mix with a third‑party NGFW: Keep NGFW as default, but add specific host routes to the Google API anycast VIPs to ensure PGA bypasses the firewall. For non‑Google destinations, send to NGFW or Cloud NAT per policy.

Hybrid clients (on‑prem or other clouds):

To consume Google APIs privately:
- Option A: Private Google Access for on‑premises by advertising 199.36.153.4/30 and/or 199.36.153.8/30 from Cloud Router to on‑prem with next hop default internet gateway in the VPC; map on‑prem DNS to restricted/private.googleapis.com as needed.
- Option B: PSC endpoints for Google APIs in your VPC; expose them over Cloud VPN/Interconnect by routing to the endpoint IPs and mapping on‑prem DNS accordingly.
To reach Google‑managed services with private IPs (via PSA), establish connectivity to the VPC (Cloud VPN/Interconnect), ensure RFC1918 ranges don’t overlap, propagate routes, and permit firewall rules.

Troubleshooting and verification:

DNS: dig or nslookup the API hostname from a client and verify it resolves to the intended private address (PSC endpoint IP) or to restricted/private anycast VIPs. Check Cloud DNS policy order and private zones on the VPC.
Routing: gcloud compute routes list and confirm that the most specific route matches the intended next hop (default internet gateway for PGA VIPs, internal for PSC).
Firewall: Verify egress rules permit TCP 443 to the target IPs. For load‑balanced producers behind PSC, verify health check source ranges are allowed.
PGA: Confirm subnet setting is enabled and that host routes for 199.36.153.4/30 and/or 199.36.153.8/30 exist if a custom default route is in place.
PSA: gcloud services vpc-peerings list to confirm the servicenetworking peering is ACTIVE and the allocated range is correct and unused elsewhere.
PSC: On the consumer, describe the endpoint to see connection status; on the producer, check pending or rejected connections and ILB health. Verify the service attachment’s consumer allowlist.
Cloud NAT: Use NAT logging and metrics to confirm translations, and check for port allocation or exhaustion. If an instance has an external IP, it bypasses NAT by design.

Practical Problem Scenario

Contoso Research runs analytics in two regions (us‑east1, europe‑west1). Security mandates that no VM has a public IP, Google APIs must be reachable privately and under VPC Service Controls, on‑prem users need private access to a Cloud SQL instance (private IP), and a partner’s SaaS must be consumed privately. A third‑party NGFW is the default egress next hop.

Enable Private Google Access and restricted endpoints

Action: Enable Private Google Access on all analytics subnets. Create Cloud DNS private zones for googleapis.com and add CNAMEs for the required APIs (BigQuery, Pub/Sub, Cloud Storage) to restricted.googleapis.com. Add host routes for 199.36.153.4/30 to the default internet gateway in both regions.
Rationale: Ensures VM‑to‑API traffic stays private, is compatible with VPC‑SC, and bypasses the NGFW without creating broad internet egress.

Create VPC Service Controls perimeter

Action: Place analytics projects and data projects inside a service perimeter. Add access levels for Contoso corporate networks as needed and explicitly allow required inter‑project flows via ingress rules. Avoid perimeter bridges except where tightly justified.
Rationale: Reduces data‑exfiltration risk from Google‑managed services and aligns with restricted endpoint usage.

Provision Cloud SQL with Private Services Access

Action: Allocate a /24 for PSA, connect servicenetworking, and create a Cloud SQL instance with private IP in us‑east1. Propagate VPC routes to on‑prem over Interconnect and permit firewall rules.
Rationale: Provides private RFC1918 reachability from both VPC workloads and on‑prem clients without public exposure.

Provide on‑prem private access to Google APIs

Action: Advertise 199.36.153.4/30 from Cloud Router to on‑prem, with next hop default internet gateway in the VPC. On the on‑prem DNS, map the same API hostnames to restricted.googleapis.com.
Rationale: Lets on‑prem clients use the same restricted private path, ensuring consistent policy enforcement and minimizing operational variance.

Consume the partner SaaS via Private Service Connect

Action: The partner shares a regional service attachment. Create PSC endpoints in us‑east1 and europe‑west1 subnets targeting the attachment. Publish private A records (saas.partner.contoso) pointing to each regional endpoint; use weighted DNS to prefer regional access.
Rationale: Keeps SaaS traffic on private IPs with producer‑enforced project allowlists, improves latency via regional affinity, and avoids public egress.

Retain Cloud NAT for non‑Google internet egress

Action: Deploy per‑region Cloud NAT gateways sized for peak flows. Ensure default route still points to the NGFW, except the specific restricted VIP host routes.
Rationale: Allows controlled outbound to non‑Google destinations while ensuring Google API traffic remains private and NGFW retains central visibility.

Validate and monitor

Action: For each client type, verify DNS resolution, route selection, and TLS connectivity. Check VPC‑SC logs for denials, NAT logs for non‑Google egress, and PSC connection states. Add health and availability alerts for ILBs behind the partner’s service attachment and for Cloud SQL.
Rationale: Confirms the data path matches design intent and surfaces regressions early, especially when DNS, routes, or perimeters change.

← Cloud DNS · All domains · Routing →

Practice these questions → · Timed practice on ExamRoll.io →