Why not using Ingress? (A)

Name is service resource, it's B: https://cloud.google.com/kubernetes-engine/docs/concepts/service?hl=es-419

service loadBalancer: https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer This page provides a general overview of how Google Kubernetes Engine (GKE) creates and manages Google Cloud load balancers when you apply a Kubernetes LoadBalancer Services manifest. It describes the different types of load balancers and how settings like the externalTrafficPolicy and GKE subsetting for L4 internal load balancers determine how the load balancers are configured. -> l4 tcp/udp not https Ingress: https://cloud.google.com/kubernetes-engine/docs/concepts/ingress This page provides a general overview of what Ingress for external Application Load Balancers is and how it works. Google Kubernetes Engine (GKE) provides a built-in and managed Ingress controller called GKE Ingress. This controller implements Ingress resources as Google Cloud load balancers for HTTP(S) workloads in GKE. -S http(s)

B is correct

I'm assuming B is the suggested answer because a the question doesn't state that the application should be available externally. Services allow exposing resources internally and to load balancers. However, it should be A, as the assumption would be a an external web application. https://cloud.google.com/kubernetes-engine/docs/concepts/service

Most if the labs in Google boost skills discuss how to expose the deployment using a load balancer.

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress "This page provides a general overview of what Ingress for external Application Load Balancers is and how it works. Google Kubernetes Engine (GKE) provides a built-in and managed Ingress controller called GKE Ingress. This controller implements Ingress resources as Google Cloud load balancers for HTTP(S) workloads in GKE."

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress As there is no mention about the type of the traffic, Internal or external - Going with A - Ingress.

Option-C and D are straightforwardly wrong Between A and B : B is the correct answer, because it makes use of loadbalancing the ingress in K8S native style. That is the reason why cluster scaling is also done. This is how it should External Load Balancing Ingress --> K8S Service of type LoadBalancer --> pods that can autoscale Directly allowing external loadbalcing ingress to autoscaled Pod, doesn't makes sense to use GKE

Ingress is Https while Service is TCP/UDP. https://cloud.google.com/load-balancing/docs/choosing-load-balancer https://cloud.google.com/kubernetes-engine/docs/concepts/service-networking

B is correct

A Is the best choice

Bowth options A and B can satisfy the requirements, they are both based on a load balancer. Option A is more adapted and more flexible as later on, you can set up routing rules to expose more then just one service using the same loadbalancer which can help reduce cost, you don't really need that flexibity for this case, but since it's gonna cost the same thing for now (const of a loadbalancer). Its better to go with the ingress option.

I'm going to go with B just because horizontal scaling has a ceiling and you do need to enable cluster scaling if you actually need a new node. However, I have no idea if this is the right answer. I also favor on using a load balancer vs an ingress resource as the GKE quickstart talks about it and does not mention ingress resource at all.

Option A is incorrect because although it mentions using the Horizontal Pod Autoscaler and enabling cluster autoscaling, it doesn't specify how to expose the application to the internet using a LoadBalancer. Correct Answer is B

Men, this question, many people saying A. Ingress is not a load balancer, ingress in kubernetes only route the data to a service https://kubernetes.io/docs/concepts/services-networking/ingress/ . A is incorrect because says, use ingress to loadbalance, that is not correct. B is correct.

HTTPS -> ingress resource. The answer is A. https://cloud.google.com/kubernetes-engine/docs/concepts/service-networking