An IoT enterprise is designing a Google Cloud network architecture for a global fleet of connected sensors. The architecture has two primary requirements:
1. Ingest high-volume, non-HTTP raw TCP telemetry traffic from public internet clients globally, terminating TLS encryption at the Google network edge before forwarding traffic to Compute Engine backends.
2. Provide private domain name resolution for administrative microservices communicating between two peered Virtual Private Cloud (VPC) networks without exposing record sets to the public internet.
Which TWO configurations should the cloud architecture team implement to meet these requirements? (Select TWO.)
- Deploy a Global External Proxy Network Load Balancer to terminate incoming TLS sessions at the edge and proxy the raw TCP connection to backend Compute Engine instances.Answer
- BDeploy an External HTTP(S) Load Balancer with SSL offloading to process incoming raw TCP telemetry streams from global vehicle sensors.
- Create a Cloud DNS Private Zone associated with the primary VPC network and add the peered VPC network to the zone's authorized networks list.Answer
- DConfigure a Cloud DNS Public Zone with split-horizon routing policies to prevent internal administrative records from resolving on public networks.
Answer
The team must deploy a Global External Proxy Network Load Balancer for terminating edge TLS on raw non-HTTP TCP telemetry, and create a Cloud DNS Private Zone authorized for both peered VPC networks.
Deploying a Global External Proxy Network Load Balancer fulfills the necessity for edge-terminated TLS on non-HTTP raw TCP streams. Simultaneously, creating a Cloud DNS Private Zone and authorizing both peered VPC networks grants microservices secure, internal-only name resolution without exposing infrastructure details publicly.
Step-by-Step Solution
Key Concept
Matching Google Cloud load balancer types to application layer protocols (L4 proxy vs L7 HTTP) and implementing Cloud DNS Private Zones for cross-VPC internal resolution.