Google Cloud offers several ways to run applications, and the choice between Compute Engine, Google Kubernetes Engine (GKE), and Cloud Run is fundamentally a choice about control, orchestration, and operational responsibility. The current Professional Cloud Architect<\/a> exam expects candidates to choose services from workload requirements rather than from personal preference. A virtual machine, Kubernetes cluster, and serverless container can all host application code, but they create very different responsibilities for patching, scaling, networking, deployment, and reliability.<\/p>\n Google\u2019s current compute-selection guidance makes the trade-off explicit: use Cloud Run when Google should manage the infrastructure, Compute Engine when you need control of virtual machines or bare metal, and GKE when you need Kubernetes orchestration for containerized workloads. The decision is rarely based on one feature. Architects should combine runtime requirements, portability, state, networking, scaling behavior, security boundaries, team skill, and cost before choosing the operating model.<\/p>\n Control requirements should be written precisely. Needing a custom environment variable is not a reason to manage VMs, while needing a kernel module, privileged device access, or a licensed appliance may be. Teams should distinguish operating-system control, runtime control, network control, and deployment control because managed platforms expose some of these while abstracting others. That precision prevents \u201cwe need control\u201d from becoming a default argument for the most labor-intensive option.<\/p>\n Compute Engine gives the application team direct control over VM machine type, operating system, boot configuration, attached storage, network interfaces, startup behavior, and much of the guest environment. That control is valuable for commercial software, specialized kernels, legacy applications, custom network appliances, or workloads that cannot be packaged easily into a managed container platform.<\/p>\n The cost of control is responsibility. The team must patch guest operating systems, manage images, design instance-group behavior, configure health checks, and make deliberate choices about scaling and recovery. The site\u2019s virtualization fundamentals<\/a> provide useful background because Compute Engine remains a VM-centric model even though Google manages the physical infrastructure underneath it.<\/p>\n Managed instance groups can narrow the operational gap between VMs and higher-level platforms. Instance templates provide repeatable configuration, health checks can recreate failed instances, and autoscaling can respond to demand. Images should still be patched and versioned, and state should be kept outside replaceable instances where possible. Designing VMs as disposable members of a group is generally more resilient than treating each instance as a uniquely maintained server.<\/p>\n Compute Engine is a strong fit when software assumes a traditional server, requires privileged operating-system access, needs custom drivers, depends on fixed licensing, or uses stateful patterns that are difficult to modernize immediately. Managed instance groups can still add autoscaling, rolling updates, health-based recreation, and regional distribution, so choosing VMs does not require giving up automation.<\/p>\n Architects should distinguish a legitimate VM requirement from habit. A team may request VMs because that is what it has always managed, even though the application is stateless and could run with less operational effort elsewhere. PCA questions often test this distinction by including phrases such as \u201crequires root access,\u201d \u201ccustom kernel,\u201d or \u201clift and shift\u201d when Compute Engine is appropriate, and \u201cminimize infrastructure management\u201d when it is not.<\/p>\n GKE also becomes compelling when the application relies on Kubernetes-native policy or ecosystem integrations such as operators, custom resources, service meshes, or standardized deployment tooling used across several environments. Those capabilities can justify the platform even if a simpler service could technically run each container. The architecture case should be based on the lifecycle and control model the organization needs, not on containerization by itself.<\/p>\n The choice between Autopilot and Standard should reflect the amount of node-level control the workload needs. Autopilot reduces node administration and applies opinionated management, while Standard exposes more configuration for workloads with specialized requirements. In both cases, application teams still own container images, Kubernetes objects, security context, requests and limits, and application behavior. A managed control plane does not remove workload responsibility.<\/p>\n GKE is designed for containerized applications that benefit from Kubernetes scheduling, service discovery, deployment primitives, policy, and ecosystem tooling. Standard mode gives teams more control over node pools and cluster configuration, while Autopilot shifts more node and capacity management to Google. In either mode, Kubernetes becomes part of the application\u2019s operating model rather than merely a packaging format.<\/p>\n This makes GKE powerful for microservices, platform teams, multi-service applications, and organizations already standardized on Kubernetes APIs. It also creates complexity that should be justified. The site\u2019s explanation of pods and containers<\/a> helps clarify that Kubernetes manages groups of containers and their lifecycle; it is not simply a way to run one container with extra terminology.<\/p>\n Jobs and request-driven services should also be separated conceptually. A background task that runs to completion may fit a Cloud Run job, while an API needs a continuously addressable service. Event-driven designs should consider retry behavior and idempotency because automatic retries can repeat side effects. Serverless removes server management, but application-level resilience patterns remain the developer\u2019s responsibility.<\/p>\n Cloud Run is especially effective when traffic is uneven and instances can be created or removed without coordinating local state. Cold-start sensitivity, concurrency, minimum-instance settings, and downstream connection limits should be tested with realistic traffic. A service that scales from zero can reduce idle cost, but a database that cannot accept a sudden burst of connections may require connection pooling, rate control, or minimum capacity to keep the full system stable.<\/p>\n Cloud Run is attractive when an application can be packaged as a container and the team wants Google to manage servers, cluster control planes, and most capacity decisions. It scales instances according to demand, supports request-driven services and jobs, and reduces the amount of infrastructure that application teams must maintain. That makes it a strong choice for APIs, event-driven services, web applications, and background jobs that fit the service model.<\/p>\n Serverless does not mean \u201cno architecture.\u201d Teams still need to design authentication, concurrency, timeouts, networking, data access, secrets, observability, and failure handling. They should also understand how minimum instances, scaling limits, CPU allocation, and downstream dependencies affect performance and cost. The trade-off is less infrastructure control in exchange for less infrastructure operations.<\/p>\n Data gravity can change the best compute choice. If a large dataset sits in one region, moving compute near that data can reduce latency and transfer cost. If the application must serve globally, caching, replication, or regional services may be more important than the runtime platform itself. Architects should therefore draw the data flow before deciding where containers or VMs will run; otherwise compute is optimized around an incomplete picture.<\/p>\n Compute choice should not force application state into the wrong place. Containers and VMs can both access managed databases, object storage, caches, and messaging services. Stateless application tiers are easier to scale horizontally, while local disk or in-memory state can complicate replacement and autoscaling. GKE persistent volumes and Compute Engine disks can support stateful patterns, but managed data services are often preferable when they meet the requirement.<\/p>\n Architects should map data durability, consistency, locality, and recovery independently from the runtime. A Cloud Run service can be highly elastic while still depending on a database that has fixed connection or throughput limits. A GKE deployment can add pods quickly while a stateful backend becomes the bottleneck. Capacity planning must follow the whole request path.<\/p>\n Regional design should match the failure target. A managed instance group or GKE cluster can distribute capacity across zones, while Cloud Run is regional and can be deployed to multiple regions behind global routing when the requirement justifies it. Multi-region application design adds state, deployment, and consistency concerns, so it should be driven by recovery and latency requirements rather than by a generic preference for global architecture.<\/p>\n Autoscaling needs safe minimum and maximum boundaries. A minimum protects latency and baseline capacity, while a maximum protects budgets and downstream dependencies from uncontrolled fan-out. Health checks should test whether an instance can serve real traffic, not merely whether its process exists. Deployment strategies such as gradual rollout can also reduce the chance that a bad version is scaled rapidly across the entire fleet.<\/p>\n Cloud Run can scale automatically with incoming demand, GKE can scale pods and nodes, and Compute Engine managed instance groups can add or remove VMs. The mechanisms differ, but the design question is the same: what signal should cause scaling, how quickly must capacity appear, and what happens to in-flight work when an instance is replaced?<\/p>\nStart with the amount of infrastructure control you need<\/h3>\n
Choose Compute Engine for VM-level requirements<\/h3>\n
Use GKE when Kubernetes is part of the requirement<\/h3>\n
Use Cloud Run when the container should be the main unit of deployment<\/h3>\n
Evaluate state and data dependencies separately from compute<\/h3>\n
Design scaling and availability around workload behavior<\/h3>\n