Managing and Provisioning the Cloud Solution Infrastructure
This domain tests how infrastructure gets created repeatedly, safely, and with the right guardrails.
Infrastructure as Code
Declarative IaC is the default answer. Terraform with the Google provider is the most common tool; keep state in a Cloud Storage backend with locking, split state by environment, and pin provider versions. Config Controller / Config Connector cover Kubernetes-native management of Google Cloud resources. Deployment Manager is legacy - recognize it, but don't recommend it for new builds. Anything created twice by hand should be codified.
Delivery pipelines
Cloud Build handles CI (build, test, produce images into Artifact Registry, run Terraform plans). Cloud Deploy handles CD with release promotion across GKE, Cloud Run, and Anthos targets, including approvals. Private pools and private worker pools matter when builds must not use public IPs.
Guardrails and governance
Organization policies enforce constraints across the hierarchy (e.g., disable service account key creation, restrict external IPs, limit resource locations for data residency). Policy cannot be loosened at a lower node than where it was set. Quotas are per-project and must be raised proactively before a launch. Billing accounts, budgets, and labels tie spend back to owners. Marketplace images and Terraform modules speed up provisioning but still inherit hierarchy controls.
Traps
Confusing Cloud Build (CI) with Cloud Deploy (CD); treating org policy as advisory; assuming a project inherits a quota increase from its folder; forgetting that state locking prevents concurrent applies; recommending imperative scripts for repeatable environments.
Rule of thumb: Terraform describes the desired end state of cloud resources; Cloud Deploy describes the safe promotion of an artifact through environments. Keep the two responsibilities separate in your answers.