A financial enterprise is securing communications between its Google Cloud VPC network and Google APIs to prevent data exfiltration. The security architect has established the following requirements: Global VPC workloads must be restricted so that they can only access Google APIs and services that are supported by VPC Service Controls (VPC-SC), automatically blocking calls to unsupported Google services. A dedicated analytics tier must consume Google APIs using an internal IP address allocated directly from the VPC subnet's private RFC 1918 range, allowing fine-grained VPC firewall rule enforcement and monitoring without routing to shared public VIP ranges. Which combination of private connectivity architectures should the architect implement?

Configure Cloud DNS response policies to map `*.googleapis.com` to `restricted.googleapis.com` (`199.36.153.4/30`) for VPC-wide egress, and deploy a Private Service Connect (PSC) endpoint for Google APIs with an allocated internal IP in the analytics subnet.: ### What this solution is This architecture combines **Restricted Google Access** via the `restricted.googleapis.com` domain with a **Private Service Connect (PSC) endpoint** for Google APIs. `restricted.googleapis.com` maps API domain names to a specific virtual IP range (`199.36.153.4/30`) that strictly permits communication only with Google services supported by **VPC Service Controls (VPC-SC)**, while Private Service Connect projects Google API services directly into a consumer VPC network using a private RFC 1918 internal IP address. ### How it meets the requirements - **Restricting VPC-wide egress to VPC-SC supported services**: Configuring internal DNS zones or **Cloud DNS Response Policies** to resolve `*.googleapis.com` and related domains to `restricted.googleapis.com` (`199.36.153.4/30`) ensures that compute workloads can only communicate with services verified to support VPC-SC perimeters. Any API call to a non-supported service (such as consumer web apps or unsupported APIs) is blocked at the network layer. - **Direct private IP allocation in the analytics tier**: Deploying a **Private Service Connect endpoint** creates a forwarding rule using an internal IP address directly drawn from the analytics subnet. Workloads can route API traffic to this local IP, allowing network administrators to attach granular **VPC firewall rules** to monitor and restrict traffic to that specific internal IP without relying on external or shared VIP ranges. ### Key advantages and capabilities - **Preventative exfiltration controls**: Enforces boundary protection by preventing data movement to unauthorized or non-perimeter-protected Google Cloud services. - **Subnet-native integration**: PSC endpoints treat Google services as internal network endpoints inside the consumer VPC, enabling native VPC routing, VPC Flow Logs analysis, and microsegmentation. - **No transitive routing issues**: Unlike VPC peering or complex proxy configurations, PSC utilizes Layer 4 endpoint forwarding. - **Hybrid extensibility**: Both the `restricted.googleapis.com` VIP and PSC internal IP endpoints can be advertised across **Cloud Interconnect** or **Cloud VPN** to extend security postures to on-premises hosts. ### Why this is optimal This dual approach applies the exact native mechanism intended for broad VPC-SC enforcement across the VPC (`restricted.googleapis.com`) while providing the dedicated analytics tier with private, subnet-bound addressing and firewall control via **Private Service Connect**.

Restricted Google Access And Private Service Connect | Professional Cloud Security Engineer

Restricted Google Access And Private Service Connect

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A financial enterprise is securing communications between its Google Cloud VPC network and Google APIs to prevent data exfiltration. The security architect has established the following requirements:

Global VPC workloads must be restricted so that they can only access Google APIs and services that are supported by VPC Service Controls (VPC-SC), automatically blocking calls to unsupported Google services.
A dedicated analytics tier must consume Google APIs using an internal IP address allocated directly from the VPC subnet's private RFC 1918 range, allowing fine-grained VPC firewall rule enforcement and monitoring without routing to shared public VIP ranges.

Which combination of private connectivity architectures should the architect implement?

Configure Cloud DNS to resolve *.googleapis.com to restricted.googleapis.com (199.36.153.4/30) across the VPC, and configure Serverless VPC Access connectors for the analytics tier.

Configure Cloud DNS response policies to map *.googleapis.com to restricted.googleapis.com (199.36.153.4/30) for VPC-wide egress, and deploy a Private Service Connect (PSC) endpoint for Google APIs with an allocated internal IP in the analytics subnet.

Configure Cloud DNS to resolve *.googleapis.com to private.googleapis.com (199.36.153.8/30) for the entire VPC, and create a Private Services Access (PSA) connection for the analytics subnet.

Enable standard Private Google Access on all subnets, and deploy an internal Application Load Balancer with a Private Service Connect backend pointing to all-apis for the analytics tier.

Professional Cloud Security Engineer

Restricted Google Access And Private Service Connect

Related questions