Google ACE Deploying and Implementing a Cloud Solution Practice Question
A team is deploying a containerized microservice on GKE. They want to ensure the service is externally accessible via a stable IP address and can automatically scale the number of pods based on CPU utilization. Which TWO actions should they perform?
⚠ Common exam trap
ACE often tests the confusion between Cluster Autoscaler (scales nodes) and HorizontalPodAutoscaler (scales pods), and between Service types (LoadBalancer vs. NodePort vs. ClusterIP) for external exposure with a stable IP.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Expose the deployment using kubectl expose deployment my-service --type=LoadBalancer
Option A is correct because exposing the deployment with `kubectl expose deployment my-service --type=LoadBalancer` creates a Kubernetes Service of type LoadBalancer, which on GKE provisions a Google Cloud external load balancer with a stable external IP address, satisfying the requirement for external accessibility via a stable IP. Option D is correct because `kubectl autoscale deployment my-service --cpu-percent=80 --min=1 --max=10` creates a HorizontalPodAutoscaler that scales the number of pods between 1 and 10 based on a target CPU utilization of 80%, directly fulfilling the automatic scaling requirement. Option B is incorrect because a ClusterIP service only provides an internal cluster-only virtual IP and is not externally accessible. Option C is incorrect because a Cluster Autoscaler scales the number of nodes in the node pool, not the number of pods, so it does not address pod-level scaling based on CPU. Option E is incorrect because a NodePort service exposes the service on a static port on each node's IP, which is not a stable external IP address and is not the recommended approach for external access on GKE.
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
Learn chapter
Sole-Tenant Nodes for Compliance
Key term
GKE
GKE is Google's managed Kubernetes service that automates deploying, scaling, and managing containerized applications in the cloud.
Key term
Anthos
Anthos is a Google Cloud platform that lets you run applications consistently across different computing environments, like on-premises data centers and multiple public clouds.
About these practice questions
This ACE question is part of Courseiva's 775-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Google Cloud exam blueprint
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.