An enterprise data engineering team is establishing a secure hybrid data ingestion pipeline. On-premises server fleets need to stream large volumes of telemetry data directly into regional Google Cloud data service APIs across a Dedicated Interconnect connection. The network architecture must meet the following constraints: Traffic must not traverse the public internet at any point. Ingestion requests must be routed and load-balanced internally through an internal Application Load Balancer using Private Service Connect (PSC). On-premises applications must resolve the ingestion endpoint via standard corporate DNS lookups using a custom internal domain name. The on-premises routers must properly learn the route to the load balancer endpoint. Which combination of network configurations should the team deploy?

Create a Private Service Connect NEG pointing to the regional Google API service attachment, attach it to the internal Application Load Balancer backend service, advertise the forwarding rule subnet via Cloud Router BGP, configure a Cloud DNS private zone pointing to the load balancer IP, and create a Cloud DNS inbound server policy to forward on-premises DNS queries to the inbound forwarder entry point.: What the Private Service Connect and Cloud DNS Solution Is Private Service Connect (PSC) Network Endpoint Groups (NEGs) combined with an internal Application Load Balancer (ILB) and Cloud DNS inbound server policies allow private, governed hybrid access from on-premises networks directly to regional Google APIs and managed services over private interconnects. How It Meets the Requirements No public internet traversal: Traffic flows across the Dedicated Interconnect to the regional internal Application Load Balancer (ILB) and routes internally through the PSC NEG into Google's services. Load balanced via Private Service Connect: The regional internal Application Load Balancer uses a backend service connected to a PSC NEG configured for the target regional service attachment (e.g., pubsub.REGION.rep.googleapis.com). Corporate DNS resolution: Setting up a Cloud DNS managed private zone maps the custom domain to the load balancer's internal forwarding rule IP address. Creating a Cloud DNS inbound server policy provides an inbound forwarder entry point IP within the VPC, allowing on-premises DNS resolvers to conditionally forward domain queries into Google Cloud. Route propagation: Cloud Router dynamically advertises the load balancer forwarding rule subnet CIDR across the BGP session to the on-premises routers. Key Advantages End-to-end private connectivity: Guarantees zero internet exposure for sensitive enterprise ingestion streams. Granular traffic management: Supports URL maps, regional routing, and custom SSL policies on the internal load balancer. Seamless on-premises integration: Inbound DNS forwarders bridge enterprise corporate DNS name servers with Cloud DNS private zones. Multi-region resilience: Enables consistent private API patterns across multiple hybrid cloud landing zones. Why This Is Optimal This pattern strictly satisfies all private connectivity, dynamic BGP advertisement, Layer 7 routing, and hybrid DNS resolution requirements using standard, fully managed Google Cloud networking primitives.

StudyCerts

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Hybrid Psc Internal Load Balancer Cloud Dns

Section: Networking fundamentals

An enterprise data engineering team is establishing a secure hybrid data ingestion pipeline. On-premises server fleets need to stream large volumes of telemetry data directly into regional Google Cloud data service APIs across a Dedicated Interconnect connection.

The network architecture must meet the following constraints:

Traffic must not traverse the public internet at any point.
Ingestion requests must be routed and load-balanced internally through an internal Application Load Balancer using Private Service Connect (PSC).
On-premises applications must resolve the ingestion endpoint via standard corporate DNS lookups using a custom internal domain name.
The on-premises routers must properly learn the route to the load balancer endpoint.

Which combination of network configurations should the team deploy?

Configure an external Application Load Balancer with an internet NEG pointing to the public Google API endpoints, deploy a Cloud NAT gateway with static IP addresses, and publish external public DNS A records pointing to the Cloud NAT public IP.

Create a Private Service Connect NEG pointing to the regional Google API service attachment, attach it to the internal Application Load Balancer backend service, advertise the forwarding rule subnet via Cloud Router BGP, configure a Cloud DNS private zone pointing to the load balancer IP, and create a Cloud DNS inbound server policy to forward on-premises DNS queries to the inbound forwarder entry point.

Set up a global external Application Load Balancer with a serverless NEG targeting Cloud Run, configure Private Google Access on the subnet, and create an on-premises static route pointing to the default internet gateway.

Deploy a regional external proxy Network Load Balancer with zonal hybrid NEGs, configure a Cloud DNS outbound server policy pointing to on-premises name servers, and disable BGP route advertisements on Cloud Router.

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Hybrid Psc Internal Load Balancer Cloud Dns

Section: Networking fundamentals

The network architecture must meet the following constraints:

Traffic must not traverse the public internet at any point.
Ingestion requests must be routed and load-balanced internally through an internal Application Load Balancer using Private Service Connect (PSC).
On-premises applications must resolve the ingestion endpoint via standard corporate DNS lookups using a custom internal domain name.
The on-premises routers must properly learn the route to the load balancer endpoint.

Which combination of network configurations should the team deploy?

Explanations

What the Private Service Connect and Cloud DNS Solution Is

Private Service Connect (PSC) Network Endpoint Groups (NEGs) combined with an internal Application Load Balancer (ILB) and Cloud DNS inbound server policies allow private, governed hybrid access from on-premises networks directly to regional Google APIs and managed services over private interconnects.

How It Meets the Requirements

No public internet traversal: Traffic flows across the Dedicated Interconnect to the regional internal Application Load Balancer (ILB) and routes internally through the PSC NEG into Google's services.
Load balanced via Private Service Connect: The regional internal Application Load Balancer uses a backend service connected to a PSC NEG configured for the target regional service attachment (e.g., pubsub.REGION.rep.googleapis.com).
Corporate DNS resolution: Setting up a Cloud DNS managed private zone maps the custom domain to the load balancer's internal forwarding rule IP address. Creating a Cloud DNS inbound server policy provides an inbound forwarder entry point IP within the VPC, allowing on-premises DNS resolvers to conditionally forward domain queries into Google Cloud.
Route propagation: Cloud Router dynamically advertises the load balancer forwarding rule subnet CIDR across the BGP session to the on-premises routers.

Key Advantages

End-to-end private connectivity: Guarantees zero internet exposure for sensitive enterprise ingestion streams.
Granular traffic management: Supports URL maps, regional routing, and custom SSL policies on the internal load balancer.
Seamless on-premises integration: Inbound DNS forwarders bridge enterprise corporate DNS name servers with Cloud DNS private zones.
Multi-region resilience: Enables consistent private API patterns across multiple hybrid cloud landing zones.

Why This Is Optimal

This pattern strictly satisfies all private connectivity, dynamic BGP advertisement, Layer 7 routing, and hybrid DNS resolution requirements using standard, fully managed Google Cloud networking primitives.

View source documentation

Professional Cloud Data Engineer

Hybrid Psc Internal Load Balancer Cloud Dns

Professional Cloud Data Engineer

Hybrid Psc Internal Load Balancer Cloud Dns

What the Private Service Connect and Cloud DNS Solution Is

How It Meets the Requirements

Key Advantages

Why This Is Optimal

Related questions