Google Compute Engine, or GCE, provides scalable, high-performance virtual machines that run on Google's infrastructure. A virtual machine is a software-based simulation of a physical computer, which lets you run an operating system and applications in an isolated environment on top of shared physical hardware. For a database engineer, GCE is the option you reach for when you want full control over the database software and the host, because you are installing and operating the database yourself rather than handing it to a managed service. The Professional Cloud Database Engineer exam tends to test whether you can recognize when that level of control is actually warranted, and when a managed service is the better answer.
It helps to look at GCE as three layers. At the base is the physical infrastructure, which is the hardware: CPUs, disk storage, and RAM. These resources supply the computational power, memory, and storage that everything above them depends on. Above that sits the hypervisor, which is the layer responsible for virtualization. The hypervisor abstracts the physical hardware into multiple independent virtual machines by securely dividing and managing the underlying resources, so each VM operates as if it has its own dedicated hardware even though it shares the same physical machine with other instances. At the top are the virtual machines themselves, each running its own operating system and applications in isolation.
This layered design is what gives Compute Engine its combination of isolation, flexibility, and scale. For a self-managed database, it means you get a clean environment that behaves like a dedicated server, with you responsible for what runs inside it. That includes installing the database engine, configuring it, patching the operating system, setting up backups, and handling high availability and replication. None of that is provided for you the way it would be on a managed service.
When you provision a VM, one of the key decisions is the machine type, which defines the virtual hardware for the instance. This is similar in spirit to sizing a Cloud SQL instance, but Cloud SQL uses predefined machine series that are optimized for database workloads, while Compute Engine offers more general-purpose configurations. Machine types are grouped into categories, and within each category there are specific series that reflect the architecture and capabilities of the machines.
There are four main categories to know. Standard, also called general purpose, covers balanced workloads with moderate CPU and memory requirements, with series such as N1, N2, and E2. High Memory is optimized for memory-heavy tasks and large datasets that need more memory to process efficiently, with series such as M2 and M3. High CPU is best for CPU-bound work that requires heavy computation, with series such as C2 and C2D. Shared Core is the low-cost option for lightweight workloads with minimal resource requirements, such as development environments or small, low-traffic applications, with options such as e2-micro and e2-small.
One detail worth carrying into the exam is the naming convention. The number at the end of a machine type name tells you how many virtual CPUs, or vCPUs, the instance has. For example, n1-standard-32 has 32 vCPUs, and e2-standard-4 has 4 vCPUs. You do not need to memorize every option, but understanding how the categories and naming are organized lets you read a machine type at a glance and reason about whether it fits a database workload.
Beyond the presets, Compute Engine lets you build a custom machine by setting both the number of vCPUs and the amount of memory independently. This is useful when you have particular requirements that none of the presets match well, such as needing slightly more memory than one tier offers but not as much as the next tier up. It can help with cost optimization by avoiding over-provisioning. Custom machines may incur additional costs compared to presets, so this is a feature to weigh rather than reach for by default.
This is the part the Professional Cloud Database Engineer exam cares about most. The general guidance is that GCP services are favored over custom scripts or cron jobs running on Compute Engine. In other words, when a managed service such as Cloud SQL, AlloyDB, Spanner, or one of the NoSQL options can satisfy the requirements, that is usually the intended answer, because the managed service handles patching, backups, replication, and failover for you. Running the same database yourself on a VM means you take on all of that operational work, which adds risk and effort without adding capability in most scenarios.
Self-managing a database on Compute Engine becomes the right call in narrower situations. The most common is when you need a database engine, version, or extension that no managed service offers, or when you need operating-system level access and control that a managed service does not expose. A lift-and-shift migration where the goal is to move an existing self-managed database without re-architecting it is another case where a VM is reasonable, at least as a starting point. When you see an exam scenario that emphasizes a specific unsupported engine or deep host control, that is the signal pointing toward Compute Engine. When the scenario is a standard relational or NoSQL workload with normal requirements, a managed service is almost always the better fit, and the answer that quietly assembles cron jobs and scripts on a VM is usually the one to rule out.
Our Professional Cloud Database Engineer course covers Compute Engine and self-managed databases alongside Cloud SQL sizing and the managed-versus-self-managed decision, with practice questions that drill these distinctions.
