Google Cloud offers four main compute services, and choosing between Compute Engine, Cloud Run, App Engine, and Cloud Functions is one of the most common decision points on the Associate Cloud Engineer exam. The right answer depends on how much control you need, what your workload looks like, and how much infrastructure management you want to take on. The four services sit on a spectrum from most control and most overhead to least control and least overhead.
Compute Engine runs virtual machines on Google's infrastructure. You configure the machine type, operating system, boot disk, network settings, and preemptibility. Google manages the physical hardware. You manage everything above it, including patching, scaling, and monitoring.
Use Compute Engine when you need complete control over your environment. Common scenarios include lift-and-shift migrations where an application needs a specific OS configuration, workloads with specialized hardware requirements, or applications that rely on software that cannot run in containers. Compute Engine is also the right choice when you need persistent stateful instances, where the same VM needs to maintain its configuration and data across restarts.
The trade-off is operational overhead. You configure autoscaling explicitly through Managed Instance Groups, set up health checks, manage OS updates, and monitor instance health. This is more work than any of the managed alternatives, which is why it is the right choice when you genuinely need that level of control rather than as a default.
Google Kubernetes Engine runs containerized applications on a managed Kubernetes cluster. GKE handles the Kubernetes control plane. You are responsible for your workloads, your node pools, and the configuration of pods and deployments. GKE is more abstracted than Compute Engine but still requires knowledge of Kubernetes concepts like pods, nodes, deployments, and services.
GKE is the right choice when you are already running Kubernetes or when your workloads need its orchestration capabilities: complex multi-container services that need to communicate with each other, stateful applications with persistent storage, or workloads that require fine-grained control over scheduling and resource allocation. GKE Autopilot mode reduces the operational burden significantly by managing node provisioning and configuration automatically, making it a strong option for teams that want the Kubernetes model without the node management work.
Cloud Run runs stateless containers without you managing any infrastructure. You package your application in a container image, deploy it to Cloud Run, and Google handles provisioning, scaling, and load balancing. Cloud Run scales horizontally based on incoming HTTP requests, adding container instances when traffic increases and removing them when traffic drops, including scaling to zero when there are no incoming requests.
Cloud Run is purpose-built for stateless workloads: APIs, microservices, and web applications that do not need to retain data between requests. It is a strong choice when your traffic is intermittent, since you only pay while requests are being handled. The container-based model gives developers more control over the runtime environment than App Engine while still removing all server management work.
App Engine is a platform-as-a-service that deploys your application code without requiring you to build or manage a container. You write your code, provide a YAML configuration file specifying the runtime and scaling parameters, and App Engine handles the rest including packaging, deployment, and scaling.
App Engine supports several programming language runtimes including Python, Java, Go, and Node.js. It scales automatically based on traffic, though unlike Cloud Run it keeps at least one instance running at all times to avoid cold start delays. App Engine is regional: once you choose a region for an App Engine application, you cannot change it without creating a new project. This constraint comes up on the exam. App Engine also supports traffic splitting between versions, which enables gradual rollouts and A/B testing without downtime.
Cloud Functions is the most abstracted compute service on GCP. You write individual functions that execute in response to events: an HTTP request, a new message in Pub/Sub, a file uploaded to Cloud Storage, or a change in Firestore. There are no servers to configure and no containers to manage. You pay only for the time your function is executing.
Cloud Functions is well suited for lightweight, event-driven workloads where running a persistent service would be wasteful. Processing an uploaded file, triggering a notification when a Pub/Sub message arrives, or building a small webhook endpoint are common use cases. Cloud Functions has limits on execution time and memory that make it less suited for long-running or compute-intensive tasks. Think of it as the right tool for small, focused jobs that run in response to something happening elsewhere in your system.
Start with your workload requirements. If you need a full VM with a specific OS or software stack, use Compute Engine. If you are running Kubernetes workloads or need container orchestration with stateful workloads, use GKE. If you want to deploy stateless containers without managing infrastructure, use Cloud Run. If you want to deploy code without managing containers and your team prefers a higher-level abstraction, use App Engine. If you have event-driven code that runs in response to triggers, use Cloud Functions.
The Associate Cloud Engineer exam often presents a scenario and asks which compute service fits. The deciding factors are usually whether the workload is stateless or stateful, whether containers are involved, whether the team wants to manage infrastructure, and whether the workload is event-driven or always-on. One other signal: any scenario that mentions stateless containers and HTTP traffic should lead you toward Cloud Run.
The GCP Study Hub Associate Cloud Engineer course covers each compute service in depth, including the scenarios where each one is the right answer on the exam and in real GCP environments.
