Infrastructure as Code, Blueprints and Automation Scripts

What it is

Infrastructure as code (IaC) means describing infrastructure in files kept in version control, then letting a tool create and change it. Changes are reviewed like code, repeatable across environments and easy to roll back.

Google Cloud supports several tools. The exam expects you to pick the right one for the team and to make changes through a pipeline, not the console.

How it works

The tools

Terraform on Google Cloud

Terraform compares the configuration with its state and plans the changes. Keep state remote, locked and versioned, never on a laptop.

terraform {
  backend "gcs" {
    bucket = "acme-tf-state"
    prefix = "prod/network"
  }
}

resource "google_compute_network" "prod" {
  name                    = "prod-vpc"
  auto_create_subnetworks = false
}

Turn on Object Versioning for the state bucket so a corrupted state can be recovered. Run terraform plan on every pull request and terraform apply only from the pipeline, using a service account rather than a person's credentials.

Infrastructure Manager

Infrastructure Manager runs Terraform plan and apply as a managed service, using Cloud Build under the hood. You give it the configuration from a Git repository or a local source, input values and a service account, and it keeps the state and a revision history of each deployment.

It suits teams that want Terraform without operating runners, state buckets and locking themselves. Preview runs show what a change would do before it is applied.

Config Connector and GitOps

Config Connector lets you declare a Cloud Storage bucket, Pub/Sub topic or Cloud SQL instance as a Kubernetes resource. A controller in the cluster creates and continuously reconciles the real resource, so manual drift is corrected.

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: acme-shop-assets
  namespace: shop
spec:
  location: EU
  uniformBucketLevelAccess: true

With GitOps, a cluster agent such as Config Sync or Argo CD watches a Git repository and applies what is there. Combine it with Config Connector and the repository becomes the single source of truth for apps and infrastructure.

Google-recommended practices and blueprints

gcloud beta terraform vet checks a Terraform plan against a policy library so the pipeline can block a non-compliant change.

Automation with scripting

Some tasks do not fit declarative IaC: reports, clean-ups and one-off migrations. Use the Cloud Client Libraries for Python or Go with Application Default Credentials, so the same script runs on a laptop and as a service account.

from google.cloud import compute_v1

client = compute_v1.InstancesClient()
request = compute_v1.AggregatedListInstancesRequest(project="shop-web-dev")
for zone, scoped in client.aggregated_list(request=request):
    for vm in scoped.instances:
        if "owner" not in vm.labels:
            print(zone, vm.name)

Run scheduled scripts as a Cloud Run job triggered by Cloud Scheduler, under a dedicated service account.

A worked example

A platform team creates projects by hand, and settings differ between them. The engineer adopts the Cloud Foundation Toolkit project factory and stores each team's project definition in Git.

A pull request runs terraform plan and policy validation; after approval, Infrastructure Manager applies it with a dedicated service account. Application teams on GKE declare their buckets and topics with Config Connector, synced by Config Sync.

How the exam asks about this

• "The team wants to use Terraform without managing state storage or build runners." Use Infrastructure Manager.
• "A Kubernetes-centric team wants to manage Cloud SQL instances with the same manifests and tooling as their apps." Use Config Connector, ideally with Config Sync.
• "Every new project must have the same labels, APIs and budget alerts." Use a project factory module from the Cloud Foundation Toolkit in a pipeline.