What's changed: Created Associate Cloud Engineer Chapter 3 (Domain 3 "Deploying and implementing": Compute Engine and GKE = instances/MIG-autoscaling/instance templates/OS Login/GKE (Autopilot/Standard/regional/private)/kubectl; serverless and data = Cloud Run/Cloud Functions/Eventarc/data products/AlloyDB/loading; networking and IaC = VPC/subnets/firewall/Cloud VPN/VPC Peering/Terraform/Config Connector).
3.1Deploying Compute Engine and GKE
Understand launching Compute Engine instances, autoscaling managed instance groups (MIGs) via instance templates, OS Login for access, and configuring GKE clusters (Autopilot, Standard, regional, private), deploying containerized apps, and using kubectl.
Deployment is the heart of Associate Cloud Engineer (~25% official). First, the two main deploy targets: Compute Engine (VMs) and GKE (containers).
3.1.1Compute Engine and MIGs
On Compute Engine you launch instances specifying disks, availability policy, and SSH keys. To run many VMs of the same config and scale them automatically, create an instance template (a VM blueprint) and use it to build a managed instance group (MIG) with autoscaling (adjust count with load). SSH access to VMs is centrally managed via OS Login integrated with IAM—safer than distributing keys individually.
3.1.2Deploying GKE
Containers deploy to GKE. Cluster modes include Autopilot (Google manages nodes) and Standard (you configure nodes). For higher availability use a regional cluster (spanning zones); to limit exposure use a private cluster. Operate clusters with kubectl, deploying Kubernetes resources (Pods/Services) from container images. Map "no node management = Autopilot" and "fine control = Standard."
Common: requirement → config. E.g., "auto-scale identical VMs" = instance template + MIG + autoscaling; "manage VM SSH via IAM" = OS Login; "run containers" = GKE; "let Google manage nodes" = Autopilot; "high availability across zones" = regional cluster; "limit exposure" = private cluster; "operate a cluster" = kubectl.
Watch the mix-ups: (1) distinguish instance template (blueprint) from MIG (the actual group). (2) Autoscaling is a MIG feature. (3) Autopilot (managed nodes) vs Standard (self-managed nodes). (4) Raise availability with regional/multi-zone.
3.1.3Section summary
- Instance template → MIG → autoscaling for identical VMs; OS Login centralizes SSH via IAM
- GKE modes = Autopilot (managed nodes) / Standard (self-managed); regional for availability, private to limit exposure
- Operate clusters with kubectl
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To auto-scale identical VMs with load, which combination is needed?
Q2. To centralize VM SSH access via IAM and avoid distributing keys, what do you use?
Q3. In GKE, to let Google manage nodes and minimize operational burden, which mode is best?
Q4. To configure a highly available GKE cluster across zones, which choice is appropriate?
Q5. Which tool do you configure and use to operate a GKE cluster and deploy containers?
Q6. Which best describes a key benefit of a managed instance group (MIG)?