Private Service Connect Study Notes
Private Service Connect (PSC) lets consumers access Google APIs or services published by producers inside their own VPC using private IP addresses, without traversing the public internet or sharing entire networks. It creates a clean producer-consumer boundary that appears repeatedly in ACE questions about secure service access across projects and organisations.
Key facts
- A PSC endpoint is a forwarding rule with an internal IP address in the consumer VPC that connects to a target Google API bundle or to a published service attachment.
- Service producers publish a service by placing an internal load balancer behind a service attachment, which consumers then connect to without any VPC peering between the parties.
- PSC does not require non-overlapping IP coordination at the network level between producer and consumer in the way peering does, because only the service endpoint is exposed, not whole subnets.
- For Google APIs, PSC endpoints support bundles such as all Google APIs or regionalised sets, giving private, named DNS-based access to services like storage.googleapis.com equivalents.
- Consumers control access through the endpoint IP and DNS names in their own VPC, while producers control acceptance of connections and can set connection limits per consumer.
- PSC works across projects and across organisations, making it suitable for SaaS-style delivery of internal platforms or third-party services over Google's network.
- Backend services using PSC network endpoint groups allow a consumer-side load balancer to treat a producer service in another VPC as a backend securely.
- Traffic over PSC stays on Google's private backbone and does not require external IPs, VPN tunnels, or VPC Network Peering between producer and consumer networks.
- PSC for Google APIs can complement or replace Private Google Access and restricted VIP approaches depending on DNS, regional, and organisational policy requirements at the time of writing.
What the exam expects you to know
- Choose PSC when one team or company must expose only a specific service privately to consumers in other VPCs without sharing or peering whole networks.
- Identify the service attachment as the producer-side resource and the PSC endpoint forwarding rule as the consumer-side resource in architecture descriptions.
- Know PSC endpoints for Google APIs provide private access under your own DNS names, an alternative pattern to Private Google Access at subnet level.
- Recognise that PSC avoids the peering problems of non-transitivity and overlapping ranges because networks are never merged or fully exposed.
- Spot SaaS, multi-tenant, and cross-organisation keywords as strong PSC signals in scenario questions about least-privilege service publishing.
- Understand producers can accept or reject individual consumer connections, giving per-consumer control that simple peering cannot offer.
Private Service Connect vs VPC Network Peering: when to use which
Use Private Service Connect when consumers need access to one defined service and nothing else in the producer network, especially across organisations or where IP ranges overlap. Use VPC Network Peering when two VPCs under cooperative administration need broad network-level reachability to many resources in both directions. Peering merges routing visibility and hits scale and overlap constraints, while PSC exposes a single endpoint with producer-side acceptance control. Exam phrases like publish a service, expose only this API, or avoid sharing the network point decisively to Private Service Connect. See also the VPC Network Peering notes.
Useful gcloud commands
gcloud compute forwarding-rules create my-psc-endpoint --region=us-central1 --network=my-vpc --address=my-psc-ip --target-service-attachment=my-attachment-uri
gcloud compute addresses create my-psc-ip --region=us-central1 --subnet=my-subnet
gcloud compute service-attachments list
gcloud compute forwarding-rules list --regions=us-central1Common exam traps
- Trap: Assuming PSC requires VPC Peering between producer and consumer. It deliberately does not; the endpoint and service attachment replace any need to peer networks.
- Trap: Confusing PSC with Private Google Access. Private Google Access is a subnet setting for Google APIs; PSC is a broader endpoint framework for Google APIs and published services.
- Trap: Expecting a PSC endpoint to grant access to every resource in the producer VPC. It reaches only the published service behind the service attachment.
- Trap: Forgetting DNS configuration on the consumer side. Without records pointing service names to the endpoint IP, applications cannot find the PSC endpoint by name.
Frequently asked questions
How does Private Service Connect differ from VPC Peering?
VPC Peering connects entire networks so many resources can reach each other, subject to overlap and transitivity limits. Private Service Connect exposes only a single published service through an endpoint IP in the consumer VPC, with no network-level sharing. PSC therefore suits cross-organisation and SaaS patterns where least-privilege, service-only access is the actual requirement being tested.
What is a service attachment?
A service attachment is the producer-side resource that publishes a service for Private Service Connect consumers. It sits in front of an internal load balancer that fronts the actual service instances. Consumers create PSC endpoints targeting the attachment, and the producer can review, accept, or reject those connections and set per-consumer connection limits for governance.
Can Private Service Connect be used for Google APIs?
Yes. You can create a Private Service Connect endpoint for Google APIs in your VPC and configure DNS so API names resolve to that private endpoint address. Traffic then reaches supported Google services over Google's private network from your own address space, which helps environments with strict egress policies or custom DNS requirements for API access.
Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.