Deploying and implementing a cloud solution Study Guide — ACE

Deploying and Implementing a Cloud Solution

This domain covers the hands-on deployment of GCP infrastructure across compute, containers, serverless, storage, databases, and networking. It accounts for 25% of the exam — the largest single domain — meaning roughly 12–13 questions on a 50-question exam. Questions test whether you can select the right service, configure it correctly, and know the default behaviors and limits that distinguish one option from another. Expect scenario-based questions where the wrong answers are plausible but differ on one critical detail.

Compute Engine: Instances, Templates, MIGs, and Autoscaling

Core Concepts

Compute Engine provides IaaS virtual machines (VMs). Every VM runs inside a VPC network and belongs to a zone within a region. Key facts:

• Machine families: General-purpose (E2, N2, N2D, N1), Compute-optimized (C2, C2D), Memory-optimized (M1, M2, M3), Accelerator-optimized (A2, G2). The exam favors E2 for cost-optimized and N2 for balanced performance.
• Preemptible VMs (legacy) and Spot VMs (current): up to 91% cheaper, can be reclaimed with a 30-second notice. Use for fault-tolerant, batch workloads.
• Sustained use discounts apply automatically for N1/N2/N2D when run > 25% of the month. Committed use discounts require 1-year or 3-year commitments.
• Custom machine types: specify exact vCPU and memory. Available on N1, N2, E2.
• Boot disk defaults: persistent disk (pd-standard), 10 GB for most Linux images. You can use pd-ssd, pd-balanced, or pd-extreme.
• Sole-tenant nodes: physically isolated hardware for compliance or licensing.

Instance Templates

An instance template is a global (non-zonal) resource that captures machine type, image, disk, network, metadata, and startup scripts. Templates are immutable — you cannot edit one in place; you create a new version. They are required to create a Managed Instance Group (MIG).

Managed Instance Groups (MIGs)

MIGs can be zonal (single zone) or regional (multi-zone, recommended for HA). Autohealing recreates VMs that fail health checks. Rolling updates let you deploy a new template to a percentage of instances at a time.

Autoscaling

Autoscaling policies:

• CPU utilization — scale when average CPU crosses a threshold (default target 60%)
• HTTP load balancing serving capacity — based on requests per second or utilization
• Pub/Sub queue depth — scale based on unacknowledged messages
• Cloud Monitoring custom metric — any GAUGE metric
• Schedule-based scaling — predictive, time-of-day scaling

Minimum/maximum instance counts are always set. Scale-in cooldown default is 10 minutes.

Common traps

• Instance templates are global resources, not regional — a common distractor states "you must create one per region."
• Preemptible VMs have a maximum lifetime of 24 hours, not unlimited.
• Autohealing requires a health check to be configured on the MIG; without it, MIG only replaces crashed VMs.
• Regional MIGs distribute across at least 2 zones, not all zones in the region by default.
• You cannot change the machine type of a running VM without stopping it.

Worked scenario: You need to run a stateless web application that scales with traffic, recovers from VM failures automatically, and can handle a zone outage. → Create a regional MIG with a health check for autohealing and attach an HTTP(S) load balancer. A zonal MIG would fail during a zone outage.

GKE: Cluster Creation, Workloads, and kubectl

Autopilot vs Standard

Autopilot is the recommended default for the exam — choose it unless the scenario requires node-level access, custom node images, or specific GPU configs.

Cluster Modes and Networking

• VPC-native clusters (alias IP): recommended, required for many features. Pods get IPs from a secondary IP range on the subnet.
• Private clusters: nodes have no external IPs; the control plane is accessible via a private endpoint. Useful for security-sensitive workloads.
• Workload Identity: the recommended way to give GKE Pods access to Google Cloud APIs (replaces service account key files).
• Node pools: groups of nodes within a cluster sharing the same machine type and config. You can have multiple node pools per Standard cluster.

Deploying Workloads

Key Kubernetes objects:

• Deployment: manages a ReplicaSet; used for stateless apps. Supports rolling updates.
• StatefulSet: for stateful apps (databases); stable network IDs and persistent storage.
• DaemonSet: one Pod per node; used for logging agents, monitoring.
• Job / CronJob: for batch or scheduled tasks.
• Service types: ClusterIP (internal), NodePort (exposes on node IP), LoadBalancer (creates a GCP L4 load balancer), ExternalName.
• Ingress: manages external HTTP(S) access; backed by a GCP L7 (HTTP(S)) load balancer.

kubectl Basics

Common traps

• Autopilot does not allow DaemonSets from users — Google manages node-level daemons.
• kubectl apply is idempotent; kubectl create fails if the resource already exists.
• A LoadBalancer Service creates a Network (L4) load balancer, not an HTTP(S) load balancer.
• To get HTTPS with path-based routing on GKE, use an Ingress, not a Service of type LoadBalancer.
• Workload Identity is the exam's preferred answer for Pod-to-GCP authentication — not mounting a service account key as a Secret.

Decision tree for cluster type selection:

Choosing between GKE Autopilot, Standard, and alternative compute: