Managing & Provisioning Infrastructure

The planning domain decides what the architecture should be; this domain provisions it. A request lands on a network, the network reaches compute, compute reads and writes storage, and increasingly the workload calls a machine-learning layer on top. At every one of those layers Google Cloud offers a ladder of products that differ mostly in how much of the operational work you keep versus hand to Google, and the exam almost never asks you to configure one in depth. The rule that resolves almost every scenario is to read for the binding constraint first, then choose the highest rung that still satisfies it: an SLA, a data-residency rule, a latency target, a budget, a license that demands dedicated hardware. The trap is the inverse, reaching for the most powerful or most flexible service when a simpler managed one already meets every requirement, because the extra power arrives as operational burden you now own.

Network Topologies comes first because nothing is reachable until you choose how traffic flows: the hybrid and multicloud links (Cloud VPN over the public internet versus the private Cloud Interconnect), how VPCs connect to each other (peering, Network Connectivity Center, or Shared VPC), the load balancer that fronts the workload, and the firewall and private-access controls that protect it. Storage Systems comes next, picked by access shape before anything else (object, block, file, or a managed database) with cost and retention rules layered on top. Compute Systems is where the workload actually runs, chosen by climbing the abstraction ladder from VMs through GKE to Cloud Run until the platform fits, then stopping. Vertex AI ML Workflows covers the case where you build and serve your own custom models across the full lifecycle. Prebuilt AI APIs is the top rung, where you call Google's models or packaged solutions instead of training anything. Read top to bottom and each layer assumes the ones beneath it are already in place.

The single instinct the exam rewards across this domain is to prefer the option that offloads the most operational work, as long as it still meets every hard constraint. That is the same idea phrased differently at each layer: default to GKE Autopilot over Standard and Cloud Run over self-managed nodes in compute; reach for a managed database before a self-run one in storage; and on the AI layers climb the buy-build-tune ladder only as far as real differentiation justifies, calling a pre-trained API before training with AutoML before building a fully custom Vertex AI model. Drop down a rung only when a concrete requirement forces it: node-level control, a license that needs dedicated hardware, data that cannot leave your boundary, or a model that must learn your own patterns. "More managed unless a stated constraint forbids it" resolves most close calls, and it aligns with the Google Cloud Well-Architected Framework's operational-excellence and cost-optimization pillars, where cost-optimal means the cheapest option that still meets the requirements, not the cheapest overall.