3.4.1. Infrastructure as Code Tooling

💡 First Principle: Infrastructure as Code turns "what did we actually deploy" from a question answered by clicking through the console into a question answered by reading a file in version control — making infrastructure changes reviewable, repeatable, and auditable the same way application code already is.

Terraform (HashiCorp) is the most widely adopted multi-cloud IaC tool and is heavily represented in Google's own documentation and quickstarts, despite being third-party. Config Connector takes a different, Google-native approach: it lets you manage Google Cloud resources as Kubernetes custom resources, applying the same kubectl apply workflow you'd use for application deployments to infrastructure itself. Fabric FAST is Google's opinionated, batteries-included Terraform framework for bootstrapping an entire multi-project, multi-environment Google Cloud organization from scratch, following Google's own recommended landing zone patterns. Helm packages and templates Kubernetes manifests themselves (not Google Cloud resources broadly), letting complex multi-resource Kubernetes applications be installed and upgraded as a single versioned unit.

⚠️ Exam Trap: A scenario asking specifically for a Google Cloud-native way to manage infrastructure resources using the same Kubernetes-style tooling and API patterns already used for workloads is pointing at Config Connector, not Terraform — Terraform is a valid general answer for "infrastructure as code" but the exam sometimes narrows the question to test whether you know the Kubernetes-native option exists.

Reflection Question: A platform team wants infrastructure changes reviewed through the same pull-request workflow as application code, with a clear historical record of every change. What category of tooling accomplishes that, and why does clicking through the console fail to provide it?