Skip to main content

Infrastructure as Code

Exam guide§2.4

IaC means your infrastructure is declared in files, version-controlled, reviewed, and applied repeatably - not clicked together in the console. The console is fine for learning and one-offs; anything reproducible or auditable should be code.

GotchaWhy IaC over the console

Console changes are manual, unreviewable, and drift-prone - you can't diff them, peer review them, or reliably recreate the environment. IaC gives version history, code review, and identical dev/stage/prod. If a question stresses "repeatable / reviewable / consistent across environments," the answer is IaC, not clicking.

What IaC solves​

The rise of cloud demand drove a cultural shift - DevOps - that emphasizes collaboration between developer and operations teams and automates software delivery and infrastructure changes. As those environments grow, DevOps teams hit four recurring challenges that IaC directly targets.

Inability toscale rapidlyBusiness demand needsfast IT scalingOperationalbottlenecksHard to manage infraconsistently at scaleDisconnectedfeedback loopsCommunication gapbetween dev and opsHigh manualerrorsMore scale means morehuman error
Four scaling challenges IaC addresses

Benefits of IaC​

DeclarativeSpecify the desired endstate, not the stepsCode managementCommit, version, andcollaborate like sourceAuditablePreview and diff desiredvs current before applyPortableReusable modules acrossapps, regions, the org
What you get by treating infrastructure as code

The auditable benefit is why IaC beats the console: unlike raw infrastructure, code carries comments explaining why a change was made, and a preview lets you detect drift before applying. Version control gives collaborative ownership - a developer needing a firewall port opens a pull request instead of waiting in a queue for an admin.

FactsPortability and reuse
  • Build reusable modules that encapsulate conventions, then deploy many instances of the same template across applications or regions instead of rebuilding by hand.
  • Google publishes vetted modules in the Cloud Foundation Toolkit - documented, tested infrastructure code you adopt rather than write from scratch.

Imperative vs declarative​

Most programming is imperative - you spell out the exact steps ("create five servers"). That breaks for infrastructure: re-run the script and it may create five more servers, because it can't tell live state from desired state. IaC is declarative - you state the end result and the tool reconciles reality to match it.

Imperative (command)Command line"Give me five servers"HOW to createvsDeclarative (statement)YAML / HCL"I should have five servers"WHAT to create
Imperative names the steps (HOW); declarative names the result (WHAT)
GotchaDeclarative self-heals to desired state

Delete one of the five servers by hand and the next run restores just the missing one - it sees four exist and adds one, not five. Imperative re-runs can't make that distinction, so they repeatedly recreate resources. Declarative management focuses on the WHAT, not the HOW.

Provisioning vs configuration management​

These two terms get conflated. IaC provisions cloud resources (create the VM, the network, the GKE cluster); configuration management handles what runs inside them (OS packages, services, dependencies, updates). IaC frameworks manipulate Google Cloud APIs; config management handles package configuration and software maintenance.

Infrastructure as code• Provisions and manages cloud resources• Manipulates Google Cloud APIs to deploy infra• Example: create and provision a VM instance• Example: launch a GKE clusterConfiguration management• Handles VM OS-level configuration• Package config and software maintenance• Example: configure the internals of the VM• Example: deploy containers into the GKE cluster→create the resourcethen set up what runs on itprovision the VM / cluster, then configure its OS / containers
IaC provisions the resource; configuration management sets up its internals

GCP supports several IaC tools - Chef, Puppet, Ansible, and Packer - but Terraform is the first-class, focus tool and the exam's default.

Terraform - the default answer​

Terraform (HashiCorp) is the go-to IaC tool on GCP: declarative HCL, a state file tracking real resources, plan to preview, apply to converge. It's cloud-agnostic and the exam's default "provision infrastructure as code" answer.

Its five-phase workflow and the init/plan/apply/fmt/destroy commands are the hands-on tool that implements everything on this page.

Infrastructure Manager​

Infrastructure Manager (also called Infra Manager) is a managed service that automates the deployment and management of Google Cloud infrastructure resources. You define the infrastructure in Terraform, and Infra Manager deploys it onto Google Cloud for you - so you get Infrastructure as Code without running the Terraform workflow yourself.

TerraformconfigurationInfrastructure Managermanaged service(deploys the Terraform)Google Cloudinfrastructure resourcesApplicationsCloud Build /Cloud DeployInfra Manager scope: infrastructure onlyapp delivery is a separate tool
Infra Manager takes your Terraform configuration and deploys the infrastructure onto Google Cloud. It stops at the resources - deploying applications onto those resources is the job of Cloud Build, Cloud Deploy, or your own toolchain.
GotchaInfra Manager deploys infrastructure, not applications

Infrastructure Manager does not manage the deployment of applications onto your resources. To deploy applications, use products like Cloud Build and Cloud Deploy, third-party tools, or your own toolchain. If a question pairs Infra Manager with "deploy the app," that is the wrong tool - Infra Manager stops at provisioning the infrastructure.

Config Connector​

Config Connector manages GCP resources as Kubernetes objects - you kubectl apply YAML and a controller in the cluster reconciles the real GCP resources. The answer for teams that want to manage infra the Kubernetes / GitOps way. It underpins Config Sync in Anthos/GKE fleet management.

Helm for GKE​

Helm is the package manager for Kubernetes - it templates and versions application manifests into installable charts (helm install, helm upgrade). Scope: deploying apps into a GKE cluster, not provisioning the cluster or cloud resources themselves.

Recap​

DECISIONWhich IaC tool?
Provision any GCP infra, declaratively→Terraform
Run your Terraform as a GCP-managed service→Infrastructure Manager
Manage GCP resources via kubectl / GitOps→Config Connector
Package and deploy apps into GKE→Helm
Curated Terraform blueprints/modules→Cloud Foundation Fabric (FAST)
Pick this when: match the tool to what you're provisioning
0%0 of 147 pages studied