Planning and implementing a cloud solution practice questions

Spot VMs are Compute Engine capacity sold at a steep discount because Google can preempt them at any time; they are the standard cost lever for fault-tolerant, interruptible workloads like batch processing.

The job's checkpoint-and-restart design means preemption costs only a few minutes of rework, so the workload matches the Spot model exactly and captures the largest possible discount. Sustained use discounts are small and usage-proportional, committed use requires paying for capacity around the clock, and sole-tenant nodes increase cost rather than reduce it.

1. Confirm the workload is fault tolerant: it checkpoints and can resume after interruption.
2. Map fault-tolerant batch work to Spot VMs, the discount model built for preemptible capacity.
3. Reject discount models designed for steady always-on usage (sustained use, committed use) and premium isolation options (sole-tenant).

Exam tip: If a workload can survive preemption, Spot VMs are almost always the most cost-effective Compute Engine choice.

Compute Engine custom machine types decouple vCPU count from memory size so you can match a VM precisely to a workload instead of rounding up to the nearest predefined shape.

The requirement (6 vCPUs, 52 GB) falls between predefined shapes, which is exactly the gap custom machine types exist to fill. If 52 GB exceeds the default memory-per-vCPU ceiling for the machine family, the extended memory option covers the difference. Every alternative either overpays for unused vCPUs, re-architects the app unnecessarily, or destroys performance by substituting disk for RAM.

1. Determine the exact vCPU and memory requirement of the workload.
2. Compare against predefined machine types and note the misfit in the CPU-to-memory ratio.
3. Create a custom machine type with the precise shape, enabling extended memory if the ratio exceeds the family default.

Exam tip: When predefined machine shapes force you to overprovision, custom machine types (with extended memory) buy exactly what the workload needs.

Managed instance groups (MIGs) create and manage identical VMs from an instance template, which is the reusable definition of machine type, boot image, disks, network, and startup configuration.

The creation order is fixed: define the instance template, create the MIG from it, then attach an autoscaling policy (for example, target CPU utilization of 60 percent). Without a template the MIG has nothing to instantiate. Unmanaged groups cannot autoscale, snapshots are unrelated to instance creation, and MIGs are leaderless by design.

1. Create an instance template capturing the web server's machine type, image, and startup script.
2. Create the managed instance group from that template in the target zone or region.
3. Configure autoscaling on the group with a target metric such as average CPU utilization.

Exam tip: Instance template first, managed instance group second, autoscaling policy third - a MIG cannot exist without a template to stamp instances from.

GKE offers two modes: Standard, where you manage node pools and pay per node, and Autopilot, where Google manages the nodes and you pay for the CPU, memory, and storage your Pods request.

The two requirements - keep the Kubernetes API, drop node management with per-Pod-request billing - are the definition of Autopilot. Standard with node auto-provisioning automates node pool creation but leaves node lifecycle and per-node billing with the team. Cloud Run trades away the Kubernetes API entirely, and MIGs provide no orchestration at all.

1. Confirm the team needs real Kubernetes (kubectl, the full API), ruling out non-Kubernetes platforms.
2. Confirm they want zero node management and Pod-request-based billing.
3. Select GKE Autopilot, the mode built to combine the Kubernetes API with Google-managed nodes.

Exam tip: Kubernetes API without node operations and with per-Pod billing means GKE Autopilot, not Standard mode or Cloud Run.

GKE cluster availability is determined by where the control plane runs: zonal and multi-zonal clusters have a single-zone control plane, while regional clusters replicate the control plane across zones.

Only a regional cluster satisfies the requirement, because it runs multiple control-plane replicas in different zones of the region. The classic trap is the multi-zonal cluster: its nodes span zones, but its control plane does not, so a zonal outage can take down the API server. Auto-repair and private networking address different concerns entirely.

1. Identify that the requirement is about control-plane availability, not just node availability.
2. Recall that zonal and multi-zonal clusters both run the control plane in a single zone.
3. Choose a regional cluster, which replicates both the control plane and (by default) nodes across multiple zones.

Exam tip: Multi-zonal spreads only nodes; regional is the only GKE configuration that makes the control plane survive a zone outage.

Private GKE clusters give nodes internal IPs only, so any outbound internet access must be provided by Cloud NAT, which performs source NAT for egress without exposing the instances to inbound traffic.

Cloud NAT is the purpose-built answer for exactly this pattern: internal-only instances that need to reach public endpoints. External IPs violate the security requirement, load balancers only serve inbound traffic, and a VPN tunnel targets private connectivity to on-premises rather than internet egress.

1. Recognize the need: outbound internet access from nodes that have no external IPs.
2. Create a Cloud Router in the cluster's region and VPC.
3. Configure a Cloud NAT gateway on that router covering the cluster's subnet and Pod ranges.

Exam tip: Private cluster plus internet egress equals Cloud NAT - outbound access with no inbound exposure.