Ensuring Successful Operation of a Cloud Solution
This domain accounts for 20% of the GCP Associate Cloud Engineer exam — the second-largest domain. It tests your ability to manage, monitor, and maintain running GCP resources after they have been deployed. Expect questions on day-2 operational tasks: resizing VMs, scaling GKE clusters, setting up alerting, routing logs, managing storage lifecycle rules, and performing routine database and messaging operations. The exam favors recognizing the correct tool or flag for a specific operational task over broad architectural knowledge.
Managing Compute Engine Resources
Snapshots and Images
Snapshots are incremental backups of Persistent Disk (PD) data. They are stored in Cloud Storage and are global resources (accessible across regions via the snapshot's project).
- First snapshot is a full copy; subsequent snapshots are incremental.
- Can be created while the disk is attached and the instance is running (though quiescing I/O is recommended for consistency).
- To schedule snapshots, use a snapshot schedule policy attached to the disk.
- Use
gcloud compute disks snapshot DISK_NAME --snapshot-names=SNAP_NAME --zone=ZONE.
Custom Images are used to create new boot disks with pre-installed software. Images can be created from:
- A persistent disk (instance must be stopped for a boot disk image to be consistent)
- An existing snapshot
- Another image
- A file in Cloud Storage (RAW or VMDK format)
| Feature | Snapshot | Custom Image |
|---|---|---|
| Purpose | Point-in-time backup/restore | Reusable boot disk template |
| Scope | Global (project) | Global (project, shareable) |
| Source | Persistent Disk | Disk, snapshot, or GCS file |
| Incremental | Yes | No (full copy each time) |
| Instance state | Can be running | Boot disk: stop instance first |
| Use case | Disaster recovery, disk cloning | Golden images, instance templates |
Common traps:
- The exam may say "create a snapshot of a running instance" — this is valid for data disks but risky for boot disks without I/O quiescing.
- Snapshots are not machine images. A Machine Image captures the entire VM state (all disks, metadata, network config) and is the correct answer for "full VM backup."
- Custom images are region-agnostic but snapshot restoration creates a disk in a specific zone.
Resizing Disks and Instances
- Persistent Disk resizing: You can increase disk size without stopping the instance. You cannot decrease disk size. After resizing, you must also resize the filesystem inside the OS (
resize2fsfor ext4,xfs_growfsfor XFS). - Machine type change (CPU/RAM): Instance must be stopped first. Use
gcloud compute instances set-machine-type INSTANCE --machine-type=TYPE. - Autoscaling: Managed Instance Groups (MIGs) scale based on CPU utilization, HTTP load balancing utilization, Cloud Monitoring metrics, or a schedule.
SSH Access
| Method | When to Use |
|---|---|
gcloud compute ssh | Standard SSH via IAP or external IP; uses OS Login or project metadata keys |
| OS Login | Recommended; ties SSH keys to Google accounts; supports 2FA |
| Project metadata SSH keys | Legacy; keys in project metadata apply to all instances |
| Instance metadata SSH keys | Apply to a single instance |
| Cloud IAP for TCP | SSH with no external IP; requires roles/iap.tunnelResourceAccessor |
Common traps:
- OS Login and metadata-based keys are mutually exclusive at the instance level (enable-oslogin=TRUE disables metadata keys).
- IAP TCP tunneling requires the instance to have no external IP and a firewall rule allowing IAP's IP range (
35.235.240.0/20) on port 22.
Managing Google Kubernetes Engine (GKE)
Node Pools
A node pool is a group of nodes within a cluster that share the same configuration (machine type, image, labels). A cluster can have multiple node pools.
- Add a node pool:
gcloud container node-pools create POOL_NAME --cluster=CLUSTER --machine-type=TYPE --num-nodes=N - Delete a node pool:
gcloud container node-pools delete POOL_NAME --cluster=CLUSTER - Taints and tolerations control which pods schedule onto which node pools.
Cluster and Node Upgrades
Bold decision rule: In GKE, the control plane is upgraded first, then node pools.
Node upgrade strategies in GKE:
| Strategy | Description | Disruption |
|---|---|---|
| Surge upgrade (default) | Creates surge nodes, drains old nodes one batch at a time | Low (configurable) |
| Blue-Green upgrade | Full new node pool created, traffic shifted, old pool deleted | Minimal; more expensive (double nodes briefly) |
- Release channels: Rapid, Regular (default), Stable. Channels automate both control plane and node upgrades.
gcloud container clusters upgrade CLUSTER --masterupgrades the control plane only.gcloud container clusters upgrade CLUSTER --node-pool=POOLupgrades a specific node pool.
Scaling Workloads
| Scaling Type | Object | What it Scales |
|---|---|---|
| HPA (Horizontal Pod Autoscaler) | Kubernetes resource | Pod replica count |
| VPA (Vertical Pod Autoscaler) | Kubernetes resource | Pod CPU/memory requests |
| Cluster Autoscaler | GKE feature | Node count in a node pool |
| Node Auto-provisioning | GKE feature | Creates/deletes entire node pools |
- Enable cluster autoscaler:
--enable-autoscaling --min-nodes=N --max-nodes=Mon the node pool. - HPA scales based on CPU/memory or custom metrics (via Cloud Monitoring adapter).
Common traps:
- HPA scales pods, Cluster Autoscaler scales nodes — the exam tests this distinction.
- Blue-Green upgrades are a GKE node upgrade strategy, not a deployment strategy for your applications (though the concepts are related).
--enable-autoscalingis set per node pool, not per cluster.
Unlock with a paid plan
8 more sections (about 2,520 words) continue below. Every paid plan unlocks all ACE study guides, the full question bank and mock exams, from $4.97/month.