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.

• ✗

  kubectl create service clusterip web-app --tcp=80:8080

  Why it's wrong here

  The `kubectl create service clusterip` command creates a ClusterIP Service, which assigns the Deployment a stable virtual IP reachable only from inside the cluster—it does not create any external IP, ingress, or load balancer. While the port mapping 80:8080 is valid, this Service type is designed for internal east-west traffic (e.g., other Pods), not for internet-facing access. For a web application that needs a public static IP, a LoadBalancer or explicit Ingress is required, so this option fails to expose the app externally.

• ✗

  gcloud compute forwarding-rules create web-app --port=80

  Why it's wrong here

  `gcloud compute forwarding-rules create` targets classic or external load balancing configurations for Compute Engine instances and instance groups, not Kubernetes-native resources. GKE Services are reconciled by the Kubernetes controller and interact with the cloud provider's load balancing via a Service of type LoadBalancer, so manually creating a forwarding rule does not attach it to the Deployment or open a path to the container ports. Moreover, a forwarding rule requires backend services and health checks; issuing only this command would create an unusable, orphaned rule, and it is not part of the kubectl workflow that GKE expects.

• ✓

  kubectl expose deployment web-app --type=LoadBalancer --port=80 --target-port=8080

  Why this is correct

  This is the correct approach because `kubectl expose deployment` with `--type=LoadBalancer` automatically creates a Kubernetes Service that instructs GKE to provision a cloud load balancer and allocate an external IP address. The `--port=80` specifies the Service port, while `--target-port=8080` directs traffic to the container's actual listening port on the Pod, matching the Deployment's container specification. If a reserved static IP is needed, you would reserve it in advance and add the `--load-balancer-ip` flag or annotate the Service; GKE then assigns that address to the load balancer.

• ✗

  kubectl expose deployment web-app --type=NodePort --port=80

  Why it's wrong here

  `kubectl expose deployment web-app --type=NodePort` creates a Service that exposes the app on a random high-port (default 30000-32767) on every node's IP, rather than providing a managed external load balancer or a static IP. Because the command omits `--target-port`, the Service defaults the target port to the value of `--port` (80), but the container listens on 8080, causing connections to fail. Even if the target port were corrected, NodePort would still expose the app through a volatile node IP/port, which is not a production-grade external endpoint for GKE.

Go deeper

Related to this question