Exam Associate Cloud Engineer topic 1 question 198 discussion

Those saying B are incorrect: - External TCP Network Load Balancers DO preserve the client's IP address. This is a core feature of this type of load balancer in Google Cloud. - While TCP Proxy Load Balancers also support client IP preservation, their primary strength lies in additional Layer 7 capabilities. - In the absence of requirements for advanced traffic manipulation at the application layer, the External TCP Network Load Balancer remains the best choice.

TCP Network Load Balancer: This type of load balancer operates at the network layer (Layer 4 of the OSI model). It is designed for routing TCP traffic and is well-suited for scenarios where you need to maintain the original source IP address of the client. This is crucial in your case since the application requires the preservation of the client's IP address.

The external TCP Network Load Balancer is the best option when you need to preserve the client’s original IP address, as it operates at Layer 4 (TCP/UDP) and does not proxy traffic. Since the application is running on port 389 (LDAP over TCP) and requires direct client IP visibility, a Layer 4 load balancer is required.

How to preserve client IP in a Network Load Balancer TCP : https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#proxy-protocol

A. External TCP Network Load Balancer: While it handles TCP traffic, it doesn't inherently preserve client IP addresses. C. SSL Proxy Load Balancer: This is primarily intended for encrypted SSL traffic, not general TCP traffic. D. Internal TCP Network Load Balancer: This is for internal traffic within a VPC, not for exposing applications to the internet.

It is A, Note: Proxy-based load balancers send connections to the backends from different GFE or Envoy IP addresses. If you're using a form of authentication that relies on keeping track of the IP address that opened the first connection, and expects that same IP address to open the second connection, you might not want to use a proxy load balancer. Proxy load balancers don't preserve client IP addresses by default. This type of authentication is more compatible with the passthrough load balancers. For proxy load balancers such as the internal and external Application Load Balancers, we recommend that you use Identity-Aware Proxy (IAP) as your authentication method instead. https://cloud.google.com/load-balancing/docs/choosing-load-balancer#:~:text=Proxy%20load%20balancers%20do%20not%20preserve%20client%20IP

Answer is: A External proxy Network Load Balancers let you use a single IP address for all users worldwide. https://cloud.google.com/load-balancing/docs/tcp

Its A, for sure

https://cloud.google.com/load-balancing/docs/choosing-load-balancer#:~:text=Proxy%20load%20balancers%20do%20not%20preserve%20client%20IP

I am going with A as the client IP needs to be preserved. Not sure with on2it votes once for A and once for B with the same comment especially because you need a *pass-through* load balancer to preserve the client IP as stated here: https://cloud.google.com/load-balancing/docs/choosing-load-balancer#proxy-pass-through "You'd choose a passthrough Network Load Balancer to preserve client source IP addresses"

The correct answer in this scenario would be option B: Expose the application by using a TCP Proxy Load Balancer. A TCP Proxy Load Balancer is suitable for preserving the client's IP address when accepting TCP traffic on a specific port, such as port 389 in this case. When a client makes a request to the load balancer, the load balancer maintains the client's source IP address and forwards the traffic to the appropriate backend instances in the managed instance group. This allows the application to see the original client IP address and respond accordingly. Option A, using an external TCP Network Load Balancer, does not preserve the client's IP address. The load balancer's IP address is seen as the source IP by the application, which may not meet the requirement.

The correct answer in this scenario would be option B: Expose the application by using a TCP Proxy Load Balancer. A TCP Proxy Load Balancer is suitable for preserving the client's IP address when accepting TCP traffic on a specific port, such as port 389 in this case. When a client makes a request to the load balancer, the load balancer maintains the client's source IP address and forwards the traffic to the appropriate backend instances in the managed instance group. This allows the application to see the original client IP address and respond accordingly. Option A, using an external TCP Network Load Balancer, does not preserve the client's IP address. The load balancer's IP address is seen as the source IP by the application, which may not meet the requirement.

Anser is A! If you are using a TCP/UDP network load balancer that preserves the client IP address (AWS Network Load Balancer, GCP External Network Load Balancer, Azure Load Balancer) or you are using Round-Robin DNS, then you can use the externalTrafficPolicy: Local setting to also preserve the client IP inside Kubernetes by bypassing kube-proxy and preventing it from sending traffic to other nodes.

The answer has to be A: external TCP Network Load Balancer. From the Google doc "Choose a load balancer" (https://cloud.google.com/load-balancing/docs/choosing-load-balancer) it clearly states: "You'd choose a passthrough (passthrough = non-proxy) Network Load Balancer to preserve client source IP addresses (...)". I also found a source that shows how to preserves a client’s IP address in the TCP payload in a Proxy TCP load balancer (https://medium.com/google-cloud/preserving-client-ips-through-google-clouds-global-tcp-and-ssl-proxy-load-balancers-3697d76feeb1)... with A LOT of effort... but with such a clear statement from the google doc, I would stick to A. By the way, I think that Google made a real mess with the load balancer types. This is the only thing more simple in AWS than in GCP.

In this scenario, using a TCP Proxy Load Balancer would be the most appropriate choice. A TCP Proxy Load Balancer operates at the transport layer (Layer 4) of the OSI model and can preserve the client's IP address while load balancing the TCP traffic to the backend instances. External TCP Network Load Balancer (option A) is designed for network-level load balancing, but it does not have built-in support for preserving the client's IP address. Therefore, it may not be suitable for this specific requirement.

A we need to perserve the client ip addresses: https://cloud.in28minutes.com/gcp-certification-google-cloud-load-balancers