Question 1

What is Compute Engine?

Accepted Answer

Compute Engine is GCP's Infrastructure-as-a-Service product: configurable virtual machines running on Google's infrastructure, with a choice of machine type, OS image, persistent or local disks, and networking. You control the guest OS upwards; Google runs the hypervisor, hardware and physical facility. The differentiators worth naming in the same breath are per-second billing after a one-minute minimum, automatic sustained-use discounts, custom machine types, and live migration during host maintenance. Those four together are what makes the answer sound like experience rather than a definition.

Question 2

What are the Compute Engine machine families and when do you use each?

Accepted Answer

General purpose (E2, N2, N2D, N4, C4) for most workloads and the best price-performance balance; compute optimised (C2, C2D, C3) for high per-core performance such as gaming servers or HPC; memory optimised (M1, M2, M3) for large in-memory databases like SAP HANA; accelerator optimised (A2, A3, G2) for GPU and ML workloads; and storage optimised (Z3) for very high local-SSD throughput. The pattern interviewers reward is "start on E2 or N2, measure, then move to a specialised family only when a metric forces it". E2 is the cheapest and uses dynamic resource management, which means it does not support sole-tenancy, GPUs, or committed-use discounts in the same way — that exception is a common follow-up.

Question 3

What is a custom machine type and why would you use one?

Accepted Answer

A custom machine type lets you pick the exact vCPU and memory combination rather than accepting a predefined shape. It is used when a workload sits awkwardly between two predefined types — for example needing 6 vCPU and 40 GB RAM, where the nearest predefined type would waste money on unused cores. The constraints are the interesting part: vCPU count must be 1 or an even number, memory must be a multiple of 256 MB, and memory per vCPU has a permitted range with anything above it billed as "extended memory" at a premium. Knowing that extended memory exists and costs more is the detail that separates a real user.

Question 4

What is the difference between a persistent disk and a local SSD?

Accepted Answer

A persistent disk is network-attached block storage that lives independently of the VM: it survives instance deletion, can be snapshotted, resized while running, and comes in zonal or regional (synchronously replicated across two zones) flavours. A local SSD is physically attached to the host, offers far higher IOPS and lower latency, but is ephemeral — its data is lost when the instance stops, is deleted, or live-migrates fail. The rule to state: persistent disks for anything you cannot afford to lose, local SSD only as a scratch, cache or shuffle tier where the data can be rebuilt. Candidates who suggest putting a database's primary data on local SSD without a replication story fail this question.

Question 5

What persistent disk types exist and how do you choose?

Accepted Answer

pd-standard is HDD-backed and cheapest, suitable for sequential, throughput-oriented workloads. pd-balanced is SSD-backed with a good cost/performance ratio and is the sensible default for boot disks. pd-ssd gives higher sustained IOPS for latency-sensitive databases. pd-extreme (and the newer Hyperdisk family) let you provision IOPS independently of capacity for the most demanding workloads. The non-obvious fact interviewers probe: for pd-standard, pd-balanced and pd-ssd, performance scales with provisioned size and with the VM's vCPU count. A small disk on a small VM will be slow no matter which type you pick — so "the disk is slow" is often really "the disk is too small or the VM is too small".

Question 6

What are Spot VMs (formerly preemptible VMs) and when are they appropriate?

Accepted Answer

Spot VMs use spare Compute Engine capacity at a 60–91% discount, but Compute Engine can reclaim them at any time with a 30-second preemption notice. They are appropriate for fault-tolerant, restartable, stateless work: batch processing, CI runners, rendering, data pipelines with checkpointing, and non-critical GKE node pools. Two differences from the older preemptible VMs are worth naming: Spot VMs have no 24-hour maximum runtime, and their pricing varies rather than being fixed. The design requirement is that your workload must handle the ACPI G2 soft-off signal and checkpoint its progress, otherwise you lose work rather than money.

Question 7

What is a managed instance group (MIG) and how does it differ from an unmanaged one?

Accepted Answer

A managed instance group creates identical VMs from an instance template and gives you autoscaling, autohealing based on health checks, rolling updates and regional (multi-zone) distribution. An unmanaged instance group is just an arbitrary collection of pre-existing, possibly dissimilar VMs used as a load-balancer backend — it has none of those lifecycle features. The rule is: use a MIG for anything you want to scale or self-heal, and an unmanaged group only for legacy or heterogeneous VMs you need to put behind a load balancer. Interviewers often follow up on autohealing versus load-balancer health checks — autohealing recreates the VM, the load-balancer check only stops sending it traffic.

Question 8

What is an instance template and can you edit one?

Accepted Answer

An instance template is an immutable definition of a VM — machine type, image, disks, network, metadata, service account and tags — used by MIGs and for one-off instance creation. You cannot edit a template; to change configuration you create a new template and roll the MIG onto it. That immutability is the point: it makes deployments reproducible and gives you a clean rollback target. The follow-up is usually how you roll — a MIG rolling update with maxSurge and maxUnavailable, optionally with a canary by setting two versions with a target size on the new one.

Question 9

How does autoscaling work in a managed instance group?

Accepted Answer

You attach an autoscaler to the MIG with a policy based on average CPU utilisation, load-balancing serving capacity, a Cloud Monitoring metric, or a schedule. The autoscaler adds instances when the signal exceeds the target and removes them when it falls below, within configured minimum and maximum bounds, respecting a cool-down period so new instances have time to warm up before their metrics count. The cool-down period is the detail that matters operationally: set it too short and the autoscaler reacts to boot-time CPU spikes and thrashes. Also worth naming: scale-in is deliberately more conservative than scale-out, and predictive autoscaling can pre-warm capacity based on historical patterns.

Question 10

What is autohealing and how is it configured?

Accepted Answer

Autohealing is a MIG feature that uses a health check to detect an unhealthy VM and recreate it from the instance template. It is configured with a health check plus an initial delay that gives the application time to start before the first probe counts against it. The single most common production incident here is setting the initial delay shorter than the application's boot time, which puts the MIG into a recreate loop — every instance is killed before it can pass a check. If an interviewer describes "instances keep restarting", this is the answer they are fishing for.

Question 11

What is the difference between stopping, suspending and deleting a VM?

Accepted Answer

Stopping shuts the guest down and releases the vCPU and memory — you stop paying for compute but keep paying for persistent disks and any reserved static IP. Suspending saves the in-memory state to storage so the VM resumes where it left off, and you pay a smaller charge for the saved state. Deleting removes the instance entirely, and removes disks too unless they were created with auto-delete disabled. The billing detail interviewers check is that a stopped VM still costs money for its disks and reserved static IPs — the classic "why is my bill not zero after I shut everything down" question. Also: an ephemeral external IP is released on stop and you will get a different one on start.

Question 12

What is the difference between a snapshot, an image and a machine image?

Accepted Answer

A snapshot is an incremental backup of a single persistent disk, stored globally and usable to restore or clone that disk. An image is a bootable template of a boot disk used to create new VMs. A machine image captures everything about an instance — all attached disks, machine type, metadata and network configuration — in one object, which makes it the right tool for cloning or backing up a whole VM. The efficiency detail worth adding: snapshots are incremental after the first one, so subsequent snapshots only store changed blocks, and deleting an older snapshot does not break the newer ones because Compute Engine reshuffles the referenced data automatically.

Question 13

What is a startup script and how does it differ from a custom image?

Accepted Answer

A startup script is code (shell or PowerShell) passed as instance metadata and executed as root on every boot, typically to install packages and fetch configuration. A custom image bakes that software into the disk ahead of time. Startup scripts are flexible and easy to change; custom images boot far faster and are reproducible. The production guidance is "bake what is stable, script what is dynamic" — build a golden image with Packer for the OS and runtime, and use a short startup script only for environment-specific configuration. Long startup scripts are a classic cause of autoscaling being too slow to respond to a traffic spike.

Question 14

How do you SSH into a Compute Engine VM securely without a public IP?

Accepted Answer

Use Identity-Aware Proxy TCP forwarding: gcloud compute ssh with the --tunnel-through-iap flag. IAP brokers the connection through Google's infrastructure, so the VM needs no external IP and you can restrict access with IAM rather than with a firewall rule open to the internet. You must allow ingress from IAP's range 35.235.240.0/20 on port 22. The alternatives to contrast with are a bastion/jump host, which you then have to patch and monitor, and OS Login, which ties SSH access to IAM identities and works well combined with IAP. Suggesting "just open port 22 to 0.0.0.0/0 and use a key" is an instant fail in any security-conscious loop.

Question 15

What is OS Login and why is it better than metadata SSH keys?

Accepted Answer

OS Login binds Linux user accounts to Google identities, so SSH access is controlled through IAM roles (roles/compute.osLogin and roles/compute.osAdminLogin) rather than by public keys stored in project or instance metadata. Access is revoked instantly when the IAM binding is removed, and every login is auditable against a real identity. The problem it solves: metadata SSH keys are effectively a shared, hard-to-audit key list that survives employee departures. OS Login also supports two-factor authentication and works with organisation policy constraints that force it on across the whole estate.

Question 16

What is a sole-tenant node?

Accepted Answer

A sole-tenant node is a physical Compute Engine server dedicated to one project — no other customer's VMs share the hardware. It is used for compliance and licensing requirements, particularly bring-your-own-licence Windows Server or SQL Server where licences are counted per physical core, and for workloads that need guaranteed physical isolation. The trade-off is cost: you pay for the whole node whether or not you fill it, and you take on the job of packing VMs onto it efficiently with node affinity labels. It also constrains live migration to within your own node group.

Question 17

What is a Shielded VM?

Accepted Answer

A Shielded VM uses secure boot, virtual trusted platform module (vTPM) measured boot and integrity monitoring to defend against boot-level and kernel-level malware such as rootkits and bootkits. Integrity monitoring reports to Cloud Monitoring when the boot measurements change unexpectedly. It requires a UEFI-enabled image, which is the practical constraint when someone tries to enable it on an older custom image. It is generally free and often mandated by an organisation policy constraint in regulated environments, so "we turn it on by default and only exempt where an image cannot support it" is the answer that reads as production experience.

Question 18

What is a Confidential VM?

Accepted Answer

A Confidential VM encrypts data while it is in use, in memory, using hardware-based memory encryption from AMD SEV (or equivalent Intel technology on supported families). It closes the last gap in the encryption story — data is already encrypted at rest and in transit by default on GCP, and this covers in-use memory so even a compromised hypervisor cannot read it. Name the trade-off: a modest performance overhead and a restricted set of machine types and images. It matters for regulated data, multi-party computation and any scenario where the customer will not accept trusting the cloud operator's hypervisor.

Question 19

How is data encrypted on Compute Engine by default, and how do CMEK and CSEK differ?

Accepted Answer

All persistent disks and snapshots are encrypted at rest by default with Google-managed keys, at no cost and with no configuration. With CMEK (customer-managed encryption keys) you supply a Cloud KMS key that Google uses, so you control rotation and can revoke access by disabling the key. With CSEK (customer-supplied encryption keys) you pass the raw key with every API call and Google never stores it — lose it and the data is unrecoverable. The decision framing: default for most workloads, CMEK when compliance requires key custody and auditable rotation, CSEK only when the requirement is that Google must never hold the key at all. Mentioning that disabling a CMEK key renders the disk unreadable — which is both the security benefit and the operational risk — is the mark of a senior answer.

Question 20

What are committed use discounts and sustained use discounts?

Accepted Answer

Sustained use discounts apply automatically, with no commitment, and increase as an eligible VM runs for a larger share of the month — up to about 30% for a full month on N1 and some other families. Committed use discounts require you to commit to a quantity of vCPU and memory (resource-based) or a spend amount (spend-based) for one or three years, in exchange for discounts of roughly 37% and 55%. The important operational point: CUDs are a billing construct, not a reservation — they do not guarantee capacity, and they continue to bill whether or not you use them. If you need guaranteed capacity you need a reservation, which can be combined with a CUD. That distinction is a favourite senior interview question.

Question 21

What is a Compute Engine reservation?

Accepted Answer

A reservation blocks out capacity of a specific machine type in a specific zone so it is guaranteed to be available when you need it. You are billed for reserved capacity whether or not you consume it, and reservations can be specifically targeted or automatically consumed by any matching instance. The scenario that makes it click: a scheduled batch run or a seasonal traffic spike where a "resource not available in zone" error at the moment of scale-out is unacceptable. Reservations also work with committed use discounts, so you get both the capacity guarantee and the price break.

Question 22

What is live migration and when does it not apply?

Accepted Answer

Live migration transparently moves a running VM to another host in the same zone during host maintenance, with no reboot, no IP change and only a brief performance dip. It does not apply to VMs with attached GPUs or local SSDs in certain configurations, nor to Spot or preemptible VMs — those use the TERMINATE maintenance policy instead. This is a genuine GCP advantage over the equivalent AWS behaviour of scheduling an instance retirement. The GPU exception is what interviewers use to test whether you have actually operated accelerated workloads, because it forces you to design for planned interruption.

Question 23

How do you give a VM access to a Cloud Storage bucket?

Accepted Answer

Attach a service account to the VM and grant that service account an IAM role on the bucket — typically roles/storage.objectViewer or roles/storage.objectAdmin. The VM then obtains short-lived tokens from the metadata server automatically, with no key file. You also need the VM's access scope to permit the storage API, though scopes are legacy and the modern practice is to set cloud-platform scope and control access purely with IAM. The classic trap: the service account has the right IAM role but the VM was created with a restrictive default scope, so calls still fail with a 403. Knowing that scopes and IAM are two separate gates that must both pass is exactly what this question tests.

Question 24

What is the difference between an ephemeral and a static external IP address?

Accepted Answer

An ephemeral IP is assigned automatically and released when the instance is stopped or deleted, so it can change. A static IP is reserved to your project and persists until you explicitly release it, which is what you need for DNS records, allowlisting by a third party, or anything with a fixed endpoint. The billing catch that comes up constantly: a reserved static IP that is *not* attached to a running resource is charged at a higher rate precisely to discourage hoarding. "My bill has charges for IP addresses I am not using" is exactly this.

Question 25

How do you resize a persistent disk on a running VM?

Accepted Answer

You grow the disk with gcloud compute disks resize, which can be done online with no downtime, and then extend the filesystem inside the guest OS with a tool such as resize2fs for ext4 or xfs_growfs for XFS. Persistent disks can only be grown, never shrunk. The half-answer that loses marks is stopping at the gcloud command — the disk is bigger but the filesystem still reports the old size until you extend it in the guest. The "cannot shrink" constraint is the other half interviewers check; to shrink you create a smaller disk and copy the data.

Question 26

What is a regional persistent disk?

Accepted Answer

A regional persistent disk synchronously replicates every write to two zones in the same region, so if one zone fails you can force-attach the disk to a VM in the surviving zone and continue with no data loss. It is the building block for a zone-fault-tolerant stateful workload that cannot use a managed database. The trade-offs to name: roughly double the cost, somewhat higher write latency because of synchronous replication, and a manual or scripted force-attach step in the failover. It gives you RPO of zero but not RTO of zero.

Question 27

How would you migrate an on-premises VM to Compute Engine?

Accepted Answer

Use Migrate to Virtual Machines (formerly Migrate for Compute Engine), which replicates the source VM's disks continuously while it stays running on-premises, then performs a short cutover to a Compute Engine instance. For simpler cases you can import a virtual disk image directly with the image import tool, or rebuild the VM from a custom image built with Packer. The strong answer covers the non-technical half too: dependency mapping first, then a test-clone migration into an isolated VPC to validate before touching production, and an agreed rollback. Interviewers asking migration questions are usually testing sequencing and risk management more than tool names.

Question 28

What are guest OS access scopes and are they still relevant?

Accepted Answer

Access scopes are a legacy authorisation layer set at instance creation that limits which Google APIs the attached service account may call from that VM, regardless of its IAM roles. They are still enforced, but current practice is to set the broad cloud-platform scope and rely entirely on fine-grained IAM roles on the service account, because scopes cannot express least privilege usefully. The reason to know them at all is debugging: an inherited or default-scoped VM will return 403 on an API the service account is fully authorised for. Recognising that failure mode quickly is the practical value.

Question 29

A VM is unreachable over SSH. How do you troubleshoot it?

Accepted Answer

Work outward in layers. Confirm the instance is RUNNING and check the serial console output for boot or disk errors. Check that a firewall rule allows ingress on TCP 22 from your source (or from IAP's 35.235.240.0/20 if tunnelling). Verify the route to the internet or to your on-premises network exists. Then check identity — OS Login IAM roles or metadata keys — and finally whether sshd is actually running inside the guest, using the serial console to log in if you enabled it. The signal here is a systematic layered approach rather than a list of guesses. Naming the serial console specifically is the strongest single move, because it is the only way in when the network stack or sshd inside the guest is broken.

Question 30

What is the difference between a zonal MIG and a regional MIG?

Accepted Answer

A zonal MIG places all its instances in one zone, so a zone outage takes the whole group down. A regional MIG spreads instances across three zones in the region by default and will rebalance to keep them evenly distributed, so the group survives a single-zone failure. Regional is the default recommendation for anything production-facing. The capacity nuance to add: with a regional MIG you should size the group so that losing one zone still leaves enough capacity to serve peak traffic — which in practice means running at roughly 150% of single-zone need if you have three zones.

Question 31

What is instance metadata and how do you use custom metadata?

Accepted Answer

Metadata is a key-value store attached to a project or an individual instance, readable from inside the VM through the metadata server. Google populates reserved keys such as instance name, zone and service-account tokens; you can add your own custom keys to pass configuration, environment names or startup scripts without baking them into an image. The security warning worth volunteering: never put secrets in metadata. Anyone with access to the VM, or any SSRF vulnerability in the app, can read it. Secrets belong in Secret Manager, fetched at runtime using the attached service account.

Question 32

How does per-second billing work on Compute Engine?

Accepted Answer

Compute Engine bills vCPU, memory and disks per second after a one-minute minimum charge. So a VM running for 90 seconds is billed for 90 seconds, and one running for 20 seconds is billed for the 60-second minimum. This is materially cheaper than hourly billing for short, bursty or autoscaled workloads. The design consequence is that aggressive autoscaling is cheap on GCP — you are not penalised for adding a VM for three minutes. Contrast this with billing models that round up to the hour, where scale-out is a much more expensive decision.

Question 33

What is the difference between a node in an instance group and a node in a node group?

Accepted Answer

An instance group is a logical collection of VM *instances* used for load balancing and lifecycle management. A node group is a set of sole-tenant *physical* nodes onto which you place VMs for hardware isolation. They operate at different layers: instance groups manage the virtual machines, node groups manage the physical hosts underneath them. This deliberately confusing pair shows up in certification-style interviews. The clean way to remember it: instance group is about scaling and serving, node group is about isolation and licensing.

Question 34

How do you patch a fleet of Compute Engine VMs?

Accepted Answer

Use VM Manager's OS patch management, which lets you run one-off or scheduled patch jobs across a filtered set of instances, with pre- and post-patch scripts, reboot configuration and a report of compliance. The alternative for immutable infrastructure is not to patch at all — rebuild a new golden image and roll the MIG onto it. The best answer states a preference and a reason: immutable rebuild is safer because the running fleet always matches a tested artefact, and in-place patching should be reserved for long-lived stateful VMs that cannot be recreated. Naming OS Config agent as the prerequisite shows hands-on knowledge.

Question 35

What happens to a VM's data when the instance is deleted?

Accepted Answer

Boot disks are deleted with the instance by default because auto-delete is on; additional attached disks default to auto-delete off and therefore survive. Local SSD data is always lost. Any snapshots or images taken earlier are unaffected because they are stored independently. This is a favourite because the default differs between boot and data disks. In production you normally flip the boot disk to no-auto-delete for forensics on stateful VMs, or use a deletion protection flag on the instance to prevent accidental deletion entirely.

Question 36

What is the guest environment and why does it matter?

Accepted Answer

The guest environment is a set of Google-provided packages and daemons installed in public images — the metadata script runner, the guest agent that manages SSH keys and account provisioning, the network daemon and OS Config agent. Without it, features like OS Login, startup scripts and VM Manager silently do not work. This is the answer to "I imported a custom image and startup scripts do not run". Any imported or hand-built image needs the guest environment installed manually, which is exactly the sort of practical detail an experienced candidate has been bitten by.

Question 37

How would you reduce Compute Engine cost by 40% without hurting performance?

Accepted Answer

In order of impact: right-size using the machine-type recommendations from Active Assist; delete or snapshot-and-delete idle VMs and orphaned disks and unattached static IPs; move restartable batch work onto Spot VMs; apply committed use discounts to the stable baseline; switch general-purpose workloads to E2 or the newer efficient families; and move boot disks from pd-ssd to pd-balanced where IOPS is not the constraint. The framing that scores best is baseline versus burst: commit to the steady-state floor with CUDs, serve the peak with autoscaled on-demand, and serve fault-tolerant work with Spot. Adding "and I would measure before and after with a billing export to BigQuery" turns an opinion into an engineering answer.

Question 38

What are GPUs on Compute Engine and how are they attached?

Accepted Answer

GPUs are attached as accelerators to a VM, either through an accelerator-optimised machine type such as A2 or A3, or by attaching a compatible GPU to an N1 instance. You must install the NVIDIA driver and CUDA toolkit in the guest, or use a Deep Learning VM image that has them pre-installed. GPU-attached VMs cannot live-migrate, so their maintenance policy must be TERMINATE. Two operational realities worth naming: GPU quota is separate from CPU quota and often needs a support request in advance, and GPU capacity in a given zone is genuinely scarce, so a multi-zone or reservation strategy is usually necessary for a training schedule you have to hit.

Question 39

What is the difference between Compute Engine and Google Kubernetes Engine for running containers?

Accepted Answer

You can run containers on a Compute Engine VM yourself — even directly with a container-optimised OS image — but you then own scheduling, restarts, scaling, rolling updates, service discovery and bin-packing. GKE provides all of that through Kubernetes. Compute Engine makes sense for a single container per VM or for legacy processes; GKE makes sense as soon as you have many services or need orchestration. The under-appreciated middle ground worth mentioning is Cloud Run, which runs containers with no cluster at all. A senior answer positions all three on a spectrum of operational surface rather than treating it as a binary.

Question 40

Design a highly available, cost-efficient web tier on Compute Engine. Walk me through it.

Accepted Answer

A regional managed instance group spanning three zones, built from a versioned golden image, sitting behind a global external HTTP(S) load balancer with Cloud CDN and Cloud Armor in front. Autoscaling on load-balancer serving capacity rather than raw CPU, autohealing on a real application health endpoint with a realistic initial delay, and no external IPs on the instances — egress through Cloud NAT and administration through IAP. Cost-wise, a committed use discount covering the steady baseline, on-demand for the peak, and pd-balanced boot disks. This is the standard closing question for a Compute Engine round and it is really testing whether you connect availability, security and cost in one design instead of listing services. The details that mark it as senior are the health-check initial delay, autoscaling on serving capacity, and instances with no public IP.

GCP Compute Engine (VMs) Interview Questions and Answers

How to use this set