Exam Professional Cloud Network Engineer topic 1 question 94 discussion

Correct answer - D https://cloud.google.com/architecture/creating-kubernetes-engine-private-clusters-with-net-proxies#:~:text=To%20enable%20access%20to%20the%20controller%20from%20another%20VPC%20network%20or%20from%20on%2Dpremises%20connected%20through%20another%20VPC%20network%20peering%20(such%20as%20in%20hub%2Dand%2Dspoke%20designs)%2C%20create%20a%20proxy%20hosted%20in%20authorized%20IP%20address%20space%2C%20because%20VPC%20network%20peering%20is%20non%2Dtransitive.

Agree D is right To enable access such as in hub-and-spoke designs, create a proxy hosted in authorized IP address space, because VPC network peering is non-transitive.

D is the correct answer

Option C is the best solution. To allow access to the GKE control plane from other spoke projects, you need to configure the authorized networks to include the subnet ranges of those other spoke projects. Deploying a proxy adds unnecessary complexity to the solution and would not address the core issue of controlling access to the GKE control plane via authorized networks.

D) option is incorrect because it miss to add authorized networks for the new subnet. C) is correct because in a hub-and-spoke architecture, the connection between VPCs occurs through a hub VPC.

D is the ans . https://cloud.google.com/kubernetes-engine/docs/archive/creating-kubernetes-engine-private-clusters-with-net-proxies

Access to the control plane for private GKE clusters is through VPC Network Peering. VPC Network Peering is non-transitive, therefore you cannot access the cluster's control plane from another peered network. If you want direct access from another peered network or from on-premises when using a hub-and-spoke architecture, deploy proxies for control plane traffic.

D is right. VPC Peering is not transitive.

The correct answer is C. Configure the authorized networks to be the subnet ranges of the other spoke projects. Since the GKE cluster has a private endpoint for the control plane, only the authorized networks can access it. The current configuration only allows access from the subnet range where the GKE nodes are deployed, but in order to allow access from the other spoke projects, the authorized networks need to be updated to include the subnet ranges of those projects. Option D, deploying a proxy in the spoke project where the GKE nodes are deployed and connecting to the control plane through the proxy, would add unnecessary complexity and introduce additional points of failure. Updating the authorized networks is a simpler and more direct solution to allow access to the GKE control plane from the other spoke projects.

In this case: Spoke 1 <--peering--> Hub <--peering--> Spoke 2 The peering does not allow transitivity: https://cloud.google.com/vpc/docs/vpc-peering#specifications "Only directly peered networks can communicate. Transitive peering is not supported. In other words, if VPC network N1 is peered with N2 and N3, but N2 and N3 are not directly connected, VPC network N2 cannot communicate with VPC network N3 over VPC Network Peering." Answer D it is the only way to achieve the communication.

• D. Deploy a proxy in the spoke project where the GKE nodes are deployed and connect to the control plane through the ***** proxy. To enable access to the controller from another VPC network or from on-premises connected through another VPC network peering (such as in hub-and-spoke ***** designs), create a proxy hosted in authorized IP address space, because VPC network peering is non-transitive.

C is right https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/overview https://cloud.google.com/kubernetes-engine/docs/how-to/authorized-networks

c is right.

If you want to access the control plane from outside VPC, you must authorize at least one address range to have access to the private endpoint. https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters