Google ACE Deploying and Implementing a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Expose the deployment using kubectl expose deployment my-service --type=LoadBalancer

  Why this is correct

  Running `kubectl expose deployment my-service --type=LoadBalancer` creates a Service of type LoadBalancer, which on GKE signals the cloud controller manager to provision a Google Cloud TCP/UDP load balancer. This load balancer receives a stable external IP address that persists for the lifetime of the Service, independent of node lifecycle. It is the standard way to expose a single deployment to the internet, as it also automatically forwards traffic to the backing pods.

• ✗

  Set the service type as ClusterIP

  Why it's wrong here

  Setting the Service type to ClusterIP assigns an internal virtual IP that is only routable within the GKE cluster's private network. While this IP is stable, it is not reachable from outside the cluster, so external clients cannot access the microservice. To provide external access, you would need to configure an Ingress resource or change the Service type to LoadBalancer; by itself, ClusterIP fails the requirement for external exposure.

• ✗

  Create a Cluster Autoscaler on the GKE cluster

  Why it's wrong here

  Cluster Autoscaler operates at the infrastructure layer by automatically adding or removing nodes from a GKE node pool based on pending Pods, not by monitoring CPU utilization of existing Pods. It cannot scale the number of replicas in a Deployment, nor does it react to per-Pod CPU load. For pod-level autoscaling based on CPU, you need a HorizontalPodAutoscaler; Cluster Autoscaler is therefore an incorrect solution for this scenario.

• ✓

  Create a HorizontalPodAutoscaler targeting the deployment with kubectl autoscale deployment my-service --cpu-percent=80 --min=1 --max=10

  Why this is correct

  This command creates a HorizontalPodAutoscaler that automatically adjusts the Deployment's replica count to keep average CPU utilization around 80%, with a minimum of 1 and maximum of 10 replicas. The HPA works by querying the Kubernetes metrics-server for CPU usage metrics and updating the scale subresource of the Deployment. It is the correct mechanism for pod-level autoscaling based on CPU, as it directly targets the Deployment's Pod replicas.

• ✗

  Expose the deployment using kubectl expose deployment my-service --type=NodePort

  Why it's wrong here

  Exposing the Deployment as a NodePort Service publishes it on a static port (e.g., 30000-32767) on every node's IP address. However, the node IPs are ephemeral and can change when nodes are recreated, upgraded, or replaced by the node pool autoscaler, making the endpoint unstable. NodePort is also not a full load balancer and is not recommended for production external access; it lacks the stable external IP that the LoadBalancer type provides.

Go deeper

Related to this question