Cloud / Google Compute Engine Interview questions

Google Compute Engine (GCE) is Google Cloud's Infrastructure-as-a-Service offering. It lets you create and run virtual machines on Google's infrastructure, with full control over the operating system, software stack and networking.

You pick a machine type, a boot image and a disk, and the VM is running in under a minute. You pay per second (with a one-minute minimum) for the resources you use.

Typical uses are lift-and-shift of existing servers, custom databases, batch and HPC jobs, and any workload that needs OS-level access which managed services do not give you.

A VM is assembled from a few building blocks that you choose when you create it:

• Machine type - the vCPU and memory shape.
• Boot disk - a Persistent Disk or Hyperdisk created from an image.
• Network interface - attaches the VM to a VPC subnet, with an internal IP and optionally an external one.
• Service account - the identity the VM uses to call Google APIs.
• Metadata - key-value data such as startup scripts and SSH settings.
• Zone - the physical location where the VM runs.

Extras like additional disks, GPUs, labels and network tags are optional.

A machine family is a group of machine series tuned for a kind of workload. Within a family you pick a series (such as E2 or N2) and then a machine type.

Newer series get added regularly, so check the current list in the docs before you commit to one.

Compute Engine offers three kinds of machine types:

• Predefined - fixed vCPU and memory ratios such as n2-standard-4 (4 vCPUs, 16 GB). Variants are standard, highmem and highcpu.
• Custom - you choose the exact vCPU count and memory, within allowed ratios. Useful when no predefined size fits and you don't want to pay for unused memory.
• Shared-core - small E2 types like e2-micro, e2-small and e2-medium that share a physical core and can burst briefly.

Custom machine types cost a bit more per unit than predefined ones, so they pay off only when the saved resources outweigh that premium.

A region is a geographic area, like us-east1. A zone is an isolated deployment area inside a region, like us-east1-b. Each region has three or more zones.

Compute Engine VMs and zonal disks live in a single zone. If that zone has an outage, resources there are affected, while other zones in the region keep running.

For high availability, spread instances across zones in a region (a regional managed instance group does this for you). For disaster recovery, spread across regions.

There are three storage options you can attach to a VM:

• Persistent Disk - network-attached block storage that survives VM deletion if you keep it. Types are pd-standard (HDD), pd-balanced, pd-ssd and pd-extreme.
• Hyperdisk - the newer block storage line where you can provision IOPS and throughput independently of size.
• Local SSD - physically attached, very fast, but ephemeral.

pd-balanced is the usual default for general workloads. Pick pd-ssd or Hyperdisk when latency or IOPS matter, and Local SSD for scratch data or caches.

A Local SSD is a solid-state drive physically attached to the host server. Because it avoids the network, it delivers very high IOPS and low latency compared with Persistent Disk.

The catch is durability. Data survives a guest OS reboot and live migration, but it is lost when the VM is stopped, deleted or preempted. You also cannot snapshot a Local SSD.

Use it for caches, scratch space, temporary processing data and replicated databases where the application itself handles redundancy. Never keep your only copy of important data on it.

An instance template is a reusable definition of a VM: machine type, boot image, disks, network settings, service account, labels and metadata. It does not create anything by itself.

You use it to launch identical VMs or as the blueprint for a managed instance group. Templates are immutable. To change something, you create a new template and point the group at it.

Templates can be global or regional. Because they are just configuration, they are a key piece of repeatable, scripted deployments.

A managed instance group runs a set of identical VMs created from one instance template and treats them as a single unit.

It gives you things you don't get with standalone VMs:

• Autoscaling based on load or schedule
• Autohealing, which recreates VMs that fail a health check
• Rolling updates to a new template
• Multi-zone deployment with a regional MIG
• Integration with load balancers

If an instance in a MIG is deleted or crashes, the group recreates it to match the target size.

You can pay for Compute Engine in a few ways, and most real deployments mix them.

Sustained use discounts don't apply to every series (E2, for example, doesn't get them), so check eligibility.

Spot VMs are spare Compute Engine capacity sold at a steep discount (often well over 50% off on-demand prices). The trade-off is that Google can reclaim them at any time when it needs the capacity.

When that happens, the VM gets a short preemption notice (about 30 seconds) and is then stopped or deleted, depending on the termination action you set. Spot VMs have no maximum runtime, unlike the older preemptible VMs, and they don't come with an availability SLA.

They are a good match for batch processing, CI jobs, rendering and stateless workers. They are a bad match for a single database server.

Use gcloud compute instances create and pass the VM name plus the options you care about. Anything you leave out falls back to a default.

gcloud compute instances create web-1 \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --boot-disk-size=20GB \
  --tags=http-server

Run gcloud compute instances list to confirm it is running, and gcloud compute ssh web-1 --zone=us-central1-a to connect.

An image is a template of a boot disk's contents (OS plus anything installed) used to create new boot disks. There are three flavors:

• Public images - maintained by Google or partners, such as Debian, Ubuntu, Windows Server and Rocky Linux.
• Custom images - ones you build from your own disks, snapshots or other images.
• Image families - a named pointer that always resolves to the newest non-deprecated image in the family.

Using a family such as debian-12 means new VMs automatically get the latest patched image without you tracking version names.

A snapshot is a point-in-time backup of a Persistent Disk or Hyperdisk. The first snapshot copies all used blocks, and later ones store only the blocks that changed, so they are incremental.

Snapshots are stored in Cloud Storage-backed multi-regional or regional locations that you choose. You can restore one by creating a new disk from it, even in a different zone or project.

You can automate them with a snapshot schedule, set a retention period, and take them while the VM is running, though quiescing the filesystem first gives a cleaner backup.

Every VM can read key-value metadata from the metadata server at http://metadata.google.internal/computeMetadata/v1/. Requests must carry the header Metadata-Flavor: Google.

A startup script is stored as the startup-script metadata key (or startup-script-url for a Cloud Storage file). The guest agent runs it every time the VM boots, which is handy for installing packages or pulling config.

curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/name

A matching shutdown-script runs on a best-effort basis when the VM is being stopped.

A service account is the identity that software on the VM uses when calling Google Cloud APIs. Applications fetch short-lived tokens for it from the metadata server, so no key file needs to sit on disk.

By default, new VMs use the Compute Engine default service account, which often has broad permissions. It's better to create a dedicated service account with only the roles the workload needs.

Access also depends on access scopes on older setups, but the recommended approach is to grant IAM roles to the service account and keep scopes wide.

Network tags are text strings you attach to a VM. They are mainly used as targets or sources in VPC firewall rules and in custom routes.

For example, tag web servers with http-server and create an ingress rule that allows TCP 80 only for instances carrying that tag. New VMs with the same tag are covered automatically.

Tags are not the same as labels. Labels are for organizing and billing, and they have no effect on traffic.

Each VM gets an internal IP from its subnet's range, and can optionally get an external IP for internet access.

Unused reserved static external addresses are billed, so release the ones you no longer need.

Both are metadata on a VM, but they serve different purposes.

Use labels to answer 'who owns this and what does it cost', and tags to control 'what can talk to what'.

A VM moves through a set of states, and billing depends on which one it is in.

On creation it goes from PROVISIONING (resources reserved) to STAGING (booting) to RUNNING. From running you can stop it, suspend it or delete it. A stopped VM ends in TERMINATED, which still keeps its disks, while SUSPENDED keeps memory state too. REPAIRING appears if the platform is fixing a failed instance.

stateDiagram-v2
  [*] --> PROVISIONING
  PROVISIONING --> STAGING
  STAGING --> RUNNING
  RUNNING --> STOPPING
  STOPPING --> TERMINATED
  TERMINATED --> PROVISIONING : start
  RUNNING --> SUSPENDING
  SUSPENDING --> SUSPENDED
  SUSPENDED --> RUNNING : resume
  RUNNING --> REPAIRING
  REPAIRING --> RUNNING
  TERMINATED --> [*] : delete

While a VM is TERMINATED you don't pay for vCPU and memory, but you still pay for attached disks and reserved IPs.

They differ in what happens to memory and the guest OS.

Suspend is not available for every machine type (for example, those with GPUs or Local SSD), so check before relying on it.

A snapshot protects one disk. A machine image protects a whole VM.

If you only need to bring back data, a snapshot is enough. If you need the VM back exactly as it was, with its machine type, labels and every disk, use a machine image.

A zonal Persistent Disk lives in one zone and can attach only to VMs in that zone. A regional Persistent Disk synchronously replicates data between two zones in the same region.

That replication means that if one zone fails, you can force-attach the disk to a VM in the other zone and keep going. The price is higher cost and slightly higher write latency, because every write goes to both zones.

Regional disks are common for databases that need a simple failover story without application-level replication.

It depends on how much control over performance you need. With Persistent Disk, IOPS and throughput are tied largely to disk size and type, so you sometimes buy extra capacity just to get speed.

Hyperdisk lets you provision size, IOPS and throughput independently, so you pay only for the performance you need. Several newer machine series support Hyperdisk, and some of them support only Hyperdisk, so check compatibility.

For a simple web server, pd-balanced is fine and cheap. For a busy database with a known performance target, Hyperdisk is usually the better fit.

When Google needs to patch or repair a host, live migration moves your running VM to another host without a reboot. Memory, CPU state and network connections are copied across while the VM keeps running, and the final cut-over pause is typically very short.

It's controlled by the onHostMaintenance setting. MIGRATE is the default for standard VMs. TERMINATE stops the VM instead, which is required for most GPU VMs and is how Spot VMs behave.

sequenceDiagram
  participant S as Source host
  participant D as Destination host
  S->>D: Copy memory pages while VM runs
  S->>D: Re-copy dirtied pages
  S->>D: Brief pause, send final state
  D-->>S: VM resumes on destination
  Note over D: VM keeps same IP and disks

Because the VM keeps its IP and disks, applications usually don't notice.

The autoscaler compares a signal with a target and adjusts the number of VMs between your minimum and maximum.

Common signals are average CPU utilization, load balancing serving capacity, Cloud Monitoring metrics and schedules. For example, with a CPU target of 60%, the group adds VMs when average CPU goes above that and removes them when it falls well below.

The initialization period tells the autoscaler how long a new VM takes to warm up, so it ignores data from VMs that aren't ready yet. Scale-in controls can also limit how fast VMs are removed to avoid flapping.

Autohealing replaces VMs whose application is unhealthy, not just VMs that are powered off. You attach an application-level health check (HTTP, HTTPS, TCP and so on) to the group.

If a VM fails the check for the configured number of consecutive probes, the MIG recreates it from the instance template. An initial delay setting stops the group from killing VMs that are still booting.

Autohealing health checks are separate from load balancer health checks. The first decides recreation, the second decides whether to send traffic.

A managed instance group (MIG) is built from a template and the platform keeps it healthy and correctly sized. An unmanaged group is just a manual collection of existing, possibly different VMs.

Unmanaged groups are mostly used to put existing, differently configured VMs behind a load balancer.

E2 is the cost-optimized general-purpose series. It runs on a mix of CPU platforms, offers dynamic resource management and gives the lowest price for light to moderate workloads. It doesn't get sustained use discounts.

N2 uses Intel Cascade Lake or newer processors, gives more consistent per-core performance, supports larger sizes and qualifies for sustained use discounts and a wider set of features.

Pick E2 for dev/test, small web apps and microservices where price matters most. Pick N2 when you need steadier performance, bigger shapes or features such as certain local SSD configurations.

A sole-tenant node is a physical Compute Engine server dedicated to your project, so your VMs don't share the host with other customers.

You'd choose it for compliance rules that require physical isolation, for bring-your-own-license software that is licensed per physical core or socket, or to control VM placement using node affinity labels.

You pay for the whole node whether it's full or not, so it only makes economic sense when the isolation or licensing reason is real.

Shielded VM hardens a VM against boot-level and kernel-level malware such as rootkits and bootkits. It combines three features:

• Secure Boot - only signed, trusted boot components can load.
• vTPM - a virtual trusted platform module used for measured boot.
• Integrity monitoring - compares boot measurements to a known-good baseline and reports differences in Cloud Monitoring.

It needs a Shielded VM-capable image, and it's on by default for many current public images.

OS Login ties Linux SSH access to IAM instead of SSH keys scattered in project or instance metadata. You grant roles/compute.osLogin for normal access or roles/compute.osAdminLogin for sudo.

The benefits are central control and clean offboarding. Remove the IAM role and access is gone everywhere, with no key hunting. You can also enforce two-step verification and get audit logs of logins.

gcloud compute instances add-metadata web-1 --metadata enable-oslogin=TRUE

Several options work without exposing the VM publicly:

• Identity-Aware Proxy (IAP) TCP forwarding - gcloud compute ssh --tunnel-through-iap connects over Google's network after an IAM check.
• Bastion host - a hardened VM with an external IP that you hop through.
• VPN or Cloud Interconnect - reach the internal IP from on-premises.

For outbound access (updates, package installs) use Cloud NAT. For Google APIs only, enable Private Google Access on the subnet. IAP needs a firewall rule allowing the range 35.235.240.0/20 to your SSH port.

Committed use discounts (CUDs) trade a 1 or 3 year commitment for a lower price. There are two broad styles:

• Resource-based - commit to a quantity of vCPUs and memory in a region.
• Spend-based (flexible) - commit to an hourly spend amount that can apply across eligible machine families and regions.

Choose them for the steady baseline you know you'll run for a long time, and leave spikes to on-demand or autoscaling. You pay for the commitment even if you use less, so don't commit to peak usage.

VPC firewall rules are stateful and apply at the VM's network interface, not at the subnet edge. Each rule has a direction, priority (0 to 65535, lower wins), action, protocol and port, and a target.

Two implied rules always exist at the lowest priority: deny all ingress and allow all egress. So by default nothing gets in until you allow it.

Targets can be all instances, VMs with certain network tags, or VMs running as a particular service account. Service-account targeting is safer because tags can be set by anyone with edit rights on the VM.

Spot VMs run on spare capacity. When Google needs that capacity back for on-demand customers, it preempts the VM after a short notice of about 30 seconds.

The application has to expect this. Practical handling looks like this:

1. Run a shutdown-script that flushes state or uploads a checkpoint to Cloud Storage.
2. Poll the metadata key instance/preempted so the app can react sooner.
3. Put the VMs in a MIG so replacements are created when capacity returns.
4. Design jobs to be restartable, with small units of work or regular checkpoints.

curl -H "Metadata-Flavor: Google" \
 http://metadata.google.internal/computeMetadata/v1/instance/preempted

Spot VMs suit batch and stateless work. A job that cannot resume after a kill should not run on them.

Work from the outside in, so you don't waste time on the guest OS when the cause is the network.

1. Check the VM is RUNNING and has the IP you expect.
2. Verify a firewall rule allows TCP 22 from your source (or the IAP range 35.235.240.0/20 if you use IAP).
3. Run a Connectivity Test in Network Intelligence Center to spot routing or rule blocks.
4. Read the serial port output (gcloud compute instances get-serial-port-output) for boot errors, a full disk or an sshd failure.
5. Enable the interactive serial console to log in and fix sshd or permissions.
6. Check OS Login or metadata key settings if authentication is rejected.

If the disk is corrupted, attach the boot disk to a rescue VM and repair it there.

Start by finding waste, then match purchase options to the workload.

Labels plus a billing export to BigQuery make it easy to see which team or service is driving spend.

You create a new instance template and tell the MIG to move to it. The group replaces VMs gradually, so the service stays up.

Two settings control the pace. maxSurge is how many extra VMs may be created above the target size. maxUnavailable is how many may be down at once. In proactive mode the group actively replaces VMs, while opportunistic mode only updates VMs when they get recreated for other reasons.

gcloud compute instance-groups managed rolling-action start-update web-mig \
  --version=template=web-v2 \
  --max-surge=3 --max-unavailable=0 \
  --region=us-central1

For a canary, list two versions and give the new one a target size of, say, 10%.

You can only increase a disk's size. Shrinking isn't supported. The resize itself works while the VM runs, but the extra space is unusable until you grow the partition and filesystem inside the OS.

gcloud compute disks resize web-1 --size=100GB --zone=us-central1-a
# then inside the VM (ext4 example)
sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1

Take a snapshot first as a safety net. To get a smaller disk, create a new smaller disk and copy the data over.

A VPC network in Google Cloud is global, and its subnets are regional. A VM gets its internal IP from the subnet in its zone's region, and VMs in different regions of the same VPC reach each other over internal IPs with no extra routing.

Traffic decisions come from three things: routes (where packets go), firewall rules (what is allowed) and, for internet-bound traffic, an external IP or Cloud NAT. Internal DNS resolves VM names like web-1.us-central1-a.c.PROJECT.internal.

flowchart LR
  VM1["VM in us-east1 subnet"] -->|internal IP| R["VPC routes"]
  R --> FW{Firewall rules}
  FW -->|allowed| VM2["VM in europe-west1 subnet"]
  FW -->|to internet| NAT["External IP or Cloud NAT"]

Because the VPC is global, one network can span regions without VPN tunnels between them.

Choose a regional MIG when the service has to keep running if one zone fails. It spreads VMs across up to three zones in a region, and the autoscaler and load balancer work across all of them.

A zonal MIG stays in one zone. It is simpler, and it can make sense for dev environments, workloads tied to zonal resources such as a zonal disk or a specific GPU, or when cross-zone traffic cost matters.

A regional MIG needs enough quota and capacity in each zone, and your app must tolerate being served from several zones.

Remove single points of failure at each layer.

1. Run VMs in a regional MIG across at least two zones.
2. Put a global or regional load balancer in front, with health checks.
3. Enable autohealing and autoscaling so failed VMs are replaced and capacity follows load.
4. Keep state out of the VMs: use Cloud SQL (HA), Spanner or a regional Persistent Disk.
5. Add a second region for disaster recovery if the target demands it.

flowchart TD
  U[Users] --> LB["Load balancer"]
  LB --> Z1["MIG instances zone A"]
  LB --> Z2["MIG instances zone B"]
  Z1 --> DB[(HA database)]
  Z2 --> DB

Test it by deleting a zone's VMs on purpose and checking that traffic keeps flowing.

With immutable infrastructure you never patch a running VM. You bake a new image, then replace the VMs.

A typical flow is: build a golden image with Packer or an image builder pipeline, publish it into an image family, create a new instance template that references it, and roll the MIG to the new template. Rollback means switching back to the previous template.

flowchart LR
  A["Build image with Packer"] --> B["Publish to image family"]
  B --> C["New instance template"]
  C --> D["Rolling update on MIG"]
  D -->|problem| E["Roll back to old template"]

This avoids configuration drift and makes every VM identical and reproducible.

Confidential VMs encrypt data in use. The VM's memory is encrypted with keys managed by the CPU hardware (AMD SEV, SEV-SNP or Intel TDX depending on the series) and the keys aren't accessible to Google.

This protects against a compromised host or privileged insider reading memory. It adds to the usual encryption at rest and in transit.

The trade-offs are a restricted list of supported machine series and regions, some feature limits (such as live migration support varying by type) and a small performance overhead. Use them for regulated or sensitive workloads.

Neither wins everywhere. It depends on how much control you need versus how much operations work you want to avoid.

If the app is a stateless HTTP service in a container, Cloud Run usually saves effort and money. If it needs custom OS setup, persistent local state or specialized hardware, use Compute Engine.

There are two models. On accelerator-optimized series such as A2, A3 and G2, GPUs come built into the machine type. On N1, you attach GPUs (like NVIDIA T4 or V100) to the VM yourself.

VMs with GPUs usually can't live migrate, so onHostMaintenance must be TERMINATE and the VM restarts around maintenance events. You also have to install the NVIDIA driver, or use a Deep Learning VM image that already has it.

gcloud compute instances create gpu-1 \
  --zone=us-central1-a --machine-type=g2-standard-4 \
  --maintenance-policy=TERMINATE

Check GPU quota per region first, since requests fail quickly when quota is zero.

Security is layered, so combine several controls rather than relying on one.

• Identity - dedicated least-privilege service accounts, OS Login for SSH.
• Network - no external IPs where possible, tight firewall rules, IAP for admin access, Cloud NAT for outbound.
• Host hardening - Shielded VM, and Confidential VM for sensitive memory.
• Data - customer-managed encryption keys (CMEK) on disks when policy requires it.
• Patching - VM Manager patch management on a schedule.
• Governance - organization policies such as blocking external IPs or requiring Shielded VM.

Audit logs and Security Command Center findings help you spot drift from this baseline.

VM Manager is a suite for managing OS-level operations across a fleet of VMs. It relies on the OS Config agent, which is preinstalled on many public images.

It offers three main capabilities:

• OS patch management - scan for missing updates and run scheduled patch jobs with maintenance windows.
• OS inventory - collect installed packages and OS details.
• OS configuration management - apply OS policies that keep packages, files and settings in a desired state.

It must be enabled per project and the VM's service account needs the right permissions.

Google's tool for this is Migrate to Virtual Machines (the successor to Migrate for Compute Engine). It replicates the source VM's disks to Google Cloud while the source keeps running.

1. Set up a connection and a source (VMware, AWS, Azure and others).
2. Add the VM and let it replicate continuously.
3. Create a test clone to validate the app without touching production.
4. Schedule the cutover: a final sync, stop the source, and start the VM in Compute Engine.
5. Finalize and clean up replication resources.

flowchart LR
  A["On-prem VM"] --> B["Continuous replication"]
  B --> C["Test clone"]
  C --> D[Cutover]
  D --> E["VM runs on Compute Engine"]

Test clones keep the risk low, since you can rehearse as often as needed before the real cutover.