A company has deployed a new application on a GKE cluster. The cluster needs to access an internal service hosted in another project's VPC network…

The fundamental purpose of Shared VPC is to allow resources from multiple service projects to communicate securely and efficiently within a single, shared VPC network using internal IP addresses. When a GKE cluster is configured to use a subnet from a Shared VPC, its pods become native participants in that network. Consequently, they can directly resolve and route traffic to any other internal service within the same Shared VPC network (regardless of the project it resides in) using the service's internal IP address or its internal DNS name. This is the simplest and most direct method that fulfills the private traffic requirement.

A. Cloud VPN is unnecessary as it connects distinct VPC networks. Shared VPC places both resources in the same logical network, making a VPN redundant and overly complex.

C. VPC Peering connects two separate VPC networks. The scenario uses Shared VPC, which means the resources are already in the same network, so peering is not applicable.

D. Using a public IP address violates the explicit requirement for private traffic and exposes an internal service to the internet, which is against security best practices.

1. Google Cloud Documentation, "Shared VPC overview": "Instances in service projects can communicate with each other using internal IP addresses across project boundaries... You can also use internal DNS to address instances in service projects by their DNS names." This confirms direct internal communication is the intended design.

Source: https://cloud.google.com/vpc/docs/shared-vpc, Section: "Concepts", Paragraph on "Communication between projects".

2. Google Cloud Documentation, "Setting up clusters with Shared VPC": "When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it... Pods, Services, and control plane components in the cluster can communicate with each other and with other resources in the Shared VPC network."

Source: https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-shared-vpc, Section: "About Shared VPC".

3. Google Cloud Documentation, "Internal DNS": "When you use Shared VPC, internal DNS names are resolvable from attached service projects. You can use the internal DNS name of a VM in a service project to reach the VM from another service project attached to the same Shared VPC host project."

Source: https://cloud.google.com/vpc/docs/internal-dns, Section: "Internal DNS names and Shared VPC".