Google ACE Practice Question: Arrange the steps to deploy a containerized…

Answer analysis

Option-by-option breakdown

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

• ✓

  Create GKE cluster, then create Deployment, then expose Deployment as a Service

  Why this is correct

  This is the only valid sequence. You must first provision a GKE cluster so that the Kubernetes API server is reachable and kubeconfig points to it; then you can kubectl create a Deployment, which instructs the API server to create a ReplicaSet and then the Pods running your containers. Finally, you expose that Deployment as a Service (e.g., type LoadBalancer or ClusterIP) whose label selector matches the Pods created by the Deployment, giving the application a stable network endpoint and load balancing.

• ✗

  Create Deployment, then create GKE cluster, then expose Deployment as a Service

  Why it's wrong here

  You cannot create a Deployment before a cluster exists because kubectl sends a request to the Kubernetes API server; without a cluster, there is no API server to receive the create request, and kubectl will fail with a connection error. Provisioning the GKE cluster after the fact does not retroactively apply the Deployment, so the intended order is impossible. The dependency is the key: the API server, ReplicaSet controller, and kubelet that actually run your containers all live inside the cluster, so the cluster must be up and available first.

• ✗

  Expose Deployment as a Service, then create GKE cluster, then create Deployment

  Why it's wrong here

  A Service can only expose Pods that exist, so creating a Service before the Deployment means its selector matches zero Pods, and the Service's Endpoints object will be empty; furthermore, a Service cannot be created in a nonexistent cluster, so this ordering violates two dependencies at once. Even if you later create the Deployment, the Service will only become functional after the Deployment's Pods come up, but the steps in this sequence are not in the correct operational order. The Service must come last because it is a front-end abstraction that relies on the labels applied by the Deployment's Pod template.

• ✗

  Create GKE cluster, then expose Deployment as a Service, then create Deployment

  Why it's wrong here

  Even with a cluster available, exposing a Service before creating the Deployment is invalid because the Service's selector will find no Pods until the Deployment creates them, so the Service has no backends to route to. Creating the Deployment afterward technically starts the Pods, but the Service will only work after they become Ready; this ordering contradicts the principle that you cannot expose something that has not yet been created. In a correct pipeline, the Deployment must be applied first so its Pods exist and are labeled, and only then can the Service select and expose them reliably.

Go deeper

Related to this question