Compute Engine is the foundation of nearly every workload I see on Google Cloud, and it shows up across the Professional Cloud Architect exam in more places than any other service. Before any of the more interesting architecture questions make sense, you need to be solid on what a VM actually is, where it lives, and which of those choices you can change later. This article covers the intro material and the location decision you make at creation time.
Google Compute Engine (GCE) gives you scalable, high-performance virtual machines running on Google's infrastructure. A VM is a software-based simulation of a physical computer. It runs an operating system and your applications inside an isolated environment that sits on top of real hardware shared with other tenants.
The stack has three layers. At the bottom is physical infrastructure: CPU, disk, and RAM in a Google data center. On top of that sits a hypervisor, which is the virtualization layer responsible for carving the physical hardware into multiple independent virtual machines. The hypervisor allocates and isolates resources so each VM behaves as if it has its own dedicated hardware even though it is sharing a host with other VMs. The top layer is the VM itself, where your operating system and workloads run.
That layered model is what makes Compute Engine flexible. You get the isolation of a dedicated machine, the scalability of a shared platform, and the reliability of Google's global infrastructure underneath. For the Professional Cloud Architect exam, the practical takeaway is that GCE is the most general-purpose compute option on the platform. If a workload needs an OS you control, GCE is usually where you start before considering managed services like GKE, Cloud Run, or App Engine.
One of the first decisions you make when creating a VM is its location, meaning the region and zone. Regions are broad geographic areas like us-central1 (Iowa), and zones are isolated locations within those regions. I covered the region and zone model earlier in the course, but the rule that matters here is specific to VMs.
Once you set a VM's location, it is permanent. You cannot move a VM to a different region or zone after it is created. If you need to change the location, you create a new VM in the desired zone, often from a snapshot or machine image of the original, and decommission the old one.
If you do not specify a zone at creation, Google Cloud picks one for you. That can actually help with availability, since GCP can route you to a zone that is less resource-constrained at that moment. But for any production workload you want to be deliberate about which zone the VM lands in, because the location drives a few decisions you cannot easily undo.
There are three considerations that should drive the location decision, and the Professional Cloud Architect exam will lean on all three.
Ingress and egress. Communication within the same region is cheaper and faster than communication between regions. If a VM is going to talk constantly to a Cloud SQL instance, a GCS bucket, or another VM, putting them in the same region keeps latency down and avoids inter-region network charges. For chatty workloads this is the dominant cost driver, not the VM itself.
Failover and redundancy. Designing across multiple zones (and sometimes multiple regions) is how you protect against outages. Two VMs in two different zones of the same region give you high availability if one zone goes offline. Spreading across regions protects against the rarer case of a full regional failure. Whenever the exam asks how to make a system resilient, the answer almost always involves splitting workloads across zones or regions rather than running everything in one place.
Hardware availability. Not every region and zone offers the same machine types or accelerators. If you need a specific GPU, a TPU, or a memory-optimized machine type, you have to check which zones support it before you commit to a region. This catches people out when they design for a region that turns out not to have the hardware they need.
You cannot always optimize for all three at once. Sometimes the region with the GPU you need is far from your users, so you trade some egress cost for hardware availability. Sometimes the zones where your specialty hardware is available do not give you the redundancy footprint you want, so you accept a slightly weaker HA story to get the machine type. The Professional Cloud Architect exam tests whether you can reason about those trade-offs, not whether you can find a perfect answer that satisfies everything.
The pattern to internalize is: pick the region first based on user proximity and hardware availability, then pick zones within that region to give you the redundancy you need, and only then start sizing the actual VM. Location is the one decision you cannot walk back, so it gets made first.
My Professional Cloud Architect course covers Compute Engine basics and VM location alongside the rest of the compute material.
