A GKE service exposes a TCP endpoint. A Compute Engine instance in another VPC (non-overlapping IPs) needs to connect to it. Minimize effort. What should you do?

The correct answer leverages an internal LoadBalancer and VPC peering to connect resources across different VPCs with minimal effort. An internal LoadBalancer (created by the cloud.google.com/load-balancer-type: Internal annotation on a Service of type LoadBalancer) provides a private IP address for the GKE service, accessible only within the VPC network. VPC peering then allows the Compute Engine instance in the other VPC to reach this private IP address as if it were in the same network. Option 1 is incorrect because a standard external LoadBalancer would expose the service publicly, which is not ideal for internal communication and doesn't directly address the cross-VPC connectivity requirement. Option 2 is incorrect because using a NodePort and a proxy instance with multiple network interfaces is a manual, complex, and high-effort solution compared to VPC peering and internal load balancing. Option 4 is incorrect because Cloud Armor is a security policy tool for external load balancers and does not facilitate cross-VPC communication or provide an internal endpoint for the GKE service.