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.

• ✗

  Ingress

  Why it's wrong here

  Ingress is an optional layer-7 HTTP/HTTPS routing resource, not a workload controller. It does not define or manage pods, nor does it provide a stable external IP on its own. A Service of type LoadBalancer already exposes the microservice with a static IP, so Ingress only adds value when you need host/path-based routing, TLS termination, or to expose multiple services behind a single load balancer. Without an Ingress controller installed, an Ingress resource has no effect.

• ✓

  Deployment

  Why this is correct

  A Deployment is the core workload resource that declaratively manages a set of identical pods through a ReplicaSet. It defines the desired state—container image, replicas, and labels—and performs rolling updates and rollbacks, ensuring pods converge to that state. For a stateless microservice, a Deployment is mandatory to run the application reliably; scaling (manually or via HPA) and service selection all operate on the Deployment's pod labels. Without it, you would have no managed pod lifecycle, no self-healing, and no update strategy.

• ✓

  Service (type LoadBalancer)

  Why this is correct

  A Service of type LoadBalancer provisions a cloud-agnostic external load balancer (e.g., an L4 TCP/UDP load balancer in GCP) with a static IP address. It selects pods via a label selector and forwards traffic to them, providing both stable external access and internal load balancing. This Service is required for clients outside the cluster to reach the Deployment's pods, and it gives the microservice a fixed endpoint that remains unchanged across pod restarts or scaling. It is a fundamental component for exposing the microservice to the public internet or to other services.

• ✗

  ConfigMap

  Why it's wrong here

  A ConfigMap is an API resource for storing non-confidential configuration data as key-value pairs, such as environment variables, command-line arguments, or config files. It does not manage pod lifecycles, perform scaling, or create external endpoints; it only injects configuration into existing pods. For deploying a new microservice, you can use ConfigMaps optionally to decouple configuration from the container image, but it is not a required component for deployment, exposure, or autoscaling. Omitting a ConfigMap has no effect on the availability or scaling of the microservice.

• ✓

  HorizontalPodAutoscaler

  Why this is correct

  A HorizontalPodAutoscaler (HPA) is a separate controller that automatically adjusts the number of pod replicas in a Deployment, ReplicaSet, or StatefulSet based on observed metrics like CPU utilization, memory consumption, or custom application metrics. It requires a target workload (typically a Deployment) and a defined min/max replica range, and it modifies the Deployment's `spec.replicas` accordingly. While it is a best practice for adapting to load and ensuring elasticity, it is not a prerequisite to deploy a microservice—a fixed replica count works without it. If used, the HPA must reference the correct Deployment and the Deployment must define resource requests for meaningful CPU-based autoscaling.

Go deeper

Related to this question