Infrastructure Best Practices

Managing infrastructure as code on Google Cloud requires disciplined practices across organisation, security, state management, testing, and operations. This lesson consolidates best practices for Deployment Manager, Terraform, and the broader IaC workflow on GCP.

---

Organisation and Structure

Project Structure

Organise your IaC code to match your environments and team structure:

infrastructure/
  modules/
    vpc/
    gke-cluster/
    cloud-run-service/
    cloud-sql/
  environments/
    dev/
      main.tf
      variables.tf
      terraform.tfvars
      backend.tf
    staging/
      main.tf
      variables.tf
      terraform.tfvars
      backend.tf
    production/
      main.tf
      variables.tf
      terraform.tfvars
      backend.tf

Naming Conventions

Resource Type	Convention	Example
Projects	{org}-{env}-{service}	acme-prod-payments
VPCs	{env}-{purpose}-vpc	prod-main-vpc
Subnets	{env}-{region}-{purpose}	prod-euw1-web
GKE clusters	{env}-{region}-{name}	prod-euw1-primary
Service accounts	{service}-{role}@	payments-api@
Buckets	{project}-{purpose}	acme-prod-terraform-state

Tagging and Labels

Apply labels consistently to all resources:

locals {
  common_labels = {
    environment = var.environment
    team        = var.team
    managed_by  = "terraform"
    cost_centre = var.cost_centre
  }
}

resource "google_compute_instance" "web" {
  # ...
  labels = local.common_labels
}

---

State Management

Terraform State Best Practices

Practice	Description
Remote state	Always use GCS backend — never commit state to Git
State locking	GCS provides automatic locking
State per environment	Separate state files for dev, staging, production
Versioned bucket	Enable versioning on the state bucket for recovery
Encrypt state	State contains sensitive data — use CMEK if required
Limit access	Only CI/CD service accounts should write to state

terraform {
  backend "gcs" {
    bucket = "acme-terraform-state"
    prefix = "environments/production"
  }
}

State Isolation

Never share state across environments. A mistaken terraform destroy on a shared state could delete production resources:

Approach	Description	Pros	Cons
Separate directories	One directory per environment	Simple, clear isolation	Code duplication
Workspaces	Terraform workspaces	Less code duplication	Easy to forget which workspace
Terragrunt	Wrapper for Terraform	DRY configuration	Additional tool to learn

---

Security Best Practices

Authentication

Practice	Description
Workload Identity Federation	Use for CI/CD — no service account keys
Dedicated service accounts	One per pipeline stage with least privilege
No key files	Avoid downloading service account JSON keys
Short-lived credentials	Use impersonation for elevated access

Least Privilege

# Grant only the roles needed for deployment
resource "google_project_iam_member" "deployer" {
  project = var.project_id
  role    = "roles/run.admin"
  member  = "serviceAccount:${google_service_account.deployer.email}"
}

# Avoid using roles/owner or roles/editor

Sensitive Data

Practice	Description
Secret Manager	Store secrets in Secret Manager, not in Terraform variables
Encrypt state	Terraform state may contain passwords — encrypt the bucket
Mark sensitive	Use sensitive = true for variables containing secrets
No secrets in Git	Never commit .tfvars files with secrets

variable "db_password" {
  type      = string
  sensitive = true
}

---

Module Best Practices

Writing Good Modules