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.

Hybrid Psc Internal Load Balancer Cloud Dns | professional-cloud-data-engineer

Hybrid Psc Internal Load Balancer Cloud Dns

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.

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?

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.

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.

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.

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.

Professional Cloud Data Engineer

Hybrid Psc Internal Load Balancer Cloud Dns

Related questions