Mastering Terraform for Multi-Cloud: Real-World Workflows, Automation, and Best Practices

main.tf — declare two providers explicitly

terraform {
  required_version = ">= 1.8, < 2.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

provider "azurerm" {
  features {}
  subscription_id = var.azure_subscription_id
}

resource "aws_vpc" "primary" {
  cidr_block = "10.10.0.0/16"
  tags = {
    Name        = "${var.project}-aws-vpc"
    Environment = var.environment
  }
}

resource "azurerm_resource_group" "primary" {
  name     = "${var.project}-${var.environment}-rg"
  location = var.azure_location
  tags = {
    Environment = var.environment
  }
}

Production note: keep version constraints compatible with the modules you have tested and commit .terraform.lock.hcl. Provider versions shown here are illustrative baselines, not an instruction to upgrade an existing platform without testing.

terraform init — initialize providers and state

Initialize the selected backend and download provider plugins recorded in the dependency lock file.

terraform init -input=false -lockfile=readonly

Check: confirm the backend and workspace before continuing; initializing against the wrong state is an operational incident waiting to happen.

terraform fmt and terraform validate — normalize and check configuration

Formatting keeps reviews readable, while validation catches schema and reference errors before cloud access is required.

terraform fmt -check -recursive
terraform validate -no-color

Limit: validation does not prove permissions, quotas or runtime behavior in AWS or Azure.

terraform plan — review the predicted impact

Create a saved plan from protected code and current state. Read replacements, deletions, address changes and unknown values carefully.

terraform plan -input=false -out=tfplan
terraform show -no-color tfplan

Protect it: plan files can contain configuration and sensitive data. Encrypt them, restrict access and keep retention short.

terraform apply — deploy the approved plan

Apply the exact reviewed artifact from a protected environment instead of calculating an unreviewed plan at deployment time.

terraform apply -input=false tfplan

Verify: confirm application reachability, routes, policies, monitoring and cloud-native health after Terraform exits successfully.

.github/workflows/terraform.yml — validate, plan and apply

name: Terraform CI/CD

on:
  pull_request:
    paths: ['**/*.tf', '.terraform.lock.hcl']
  push:
    branches: [main]
    paths: ['**/*.tf', '.terraform.lock.hcl']

env:
  TF_IN_AUTOMATION: 'true'
  TF_INPUT: 'false'

jobs:
  validate:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v7
      - uses: hashicorp/setup-terraform@v4
        with:
          terraform_wrapper: false
      - run: terraform fmt -check -recursive
      - run: terraform init -backend=false -lockfile=readonly
      - run: terraform validate -no-color

  plan:
    if: github.event_name == 'push'
    needs: validate
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    concurrency:
      group: terraform-production
      cancel-in-progress: false
    steps:
      - uses: actions/checkout@v7
      - uses: hashicorp/setup-terraform@v4
      - name: Authenticate to the cloud with OIDC
        run: ./scripts/configure-cloud-identity.sh
      - run: terraform init -lockfile=readonly
      - run: terraform plan -out=tfplan
      - run: terraform show -no-color tfplan > tfplan.txt
      - uses: actions/upload-artifact@v7
        with:
          name: terraform-production-plan
          path: |
            tfplan
            tfplan.txt
          retention-days: 1

  apply:
    if: github.event_name == 'push'
    needs: plan
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v7
      - uses: hashicorp/setup-terraform@v4
      - uses: actions/download-artifact@v8
        with:
          name: terraform-production-plan
      - name: Authenticate to the cloud with OIDC
        run: ./scripts/configure-cloud-identity.sh
      - run: terraform init -lockfile=readonly
      - run: terraform apply tfplan

Adapt before use: replace the identity helper with your cloud's official OIDC action or CLI flow, set the Terraform working directory, and ensure plan and apply use the same operating system, architecture, absolute checkout path, Terraform version and locked provider versions.

Use workspaces only for intentionally similar environments

CLI workspaces select separate state instances for the same configuration. They are convenient for repeatable dev or test copies, but they do not create a security boundary.

terraform workspace new dev
terraform workspace new prod
terraform workspace list
terraform workspace select dev

Choose separate roots and backends instead when environments use different credentials, approval paths, ownership, compliance controls or architecture.

Use separate least-privilege cloud identities

Give AWS and Azure distinct workload identities with only the actions and resource scope required by their stacks. Prefer OIDC or workload identity federation over stored long-lived secrets, and bind trust to protected code and deployment environments.

Control dependencies and supply chain

Constrain Terraform and provider versions, commit .terraform.lock.hcl, and promote module or provider upgrades through testing and review. Treat provider binaries as privileged code.

Scan configuration and enforce policy

Use maintained IaC scanners and organizational policy checks to detect public exposure, weak encryption, wildcard permissions, missing logs and unapproved regions before deployment.

Detect drift without blindly reconciling it

Run scheduled plans and investigate unexpected differences. An out-of-band change may be an incident response or emergency repair, so identify ownership and impact before deciding whether code or infrastructure is authoritative.