IaC in a team: reviews, pipelines and policy

Why process matters

IaC removes click mistakes, but a wrong line of code can now delete a production database in seconds. The answer is the same discipline developers use for application code: version control, review, automated checks and a controlled way to release. The goal is simple: no change reaches production without a reviewed plan.

The pull request workflow

1. Create a branch and change the .tf files or the template.
2. Open a pull request (PR). The CI pipeline (an automated build system such as GitHub Actions, GitLab CI or AWS CodePipeline) runs fmt, validate, policy checks and plan.
3. The pipeline posts the plan output in the PR, so the reviewer sees "Plan: 1 to add, 0 to change, 0 to destroy." and the details.
4. A teammate reviews both the code and the plan. A surprise destroy or replace is a reason to stop.
5. After merge to main, the pipeline applies. For production, it waits for a manual approval first.

name: infra
on:
  pull_request:
    paths: ['infra/**']
  push:
    branches: [main]
    paths: ['infra/**']
permissions:
  id-token: write   # lets the job get short-lived AWS credentials (OIDC), no stored keys
  contents: read
jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v7
      - uses: hashicorp/setup-terraform@v3
      - uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: arn:aws:iam::111122223333:role/github-terraform
          aws-region: ap-south-1
      - run: terraform init -input=false
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan -input=false -out=tfplan
      - if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: terraform apply -input=false tfplan

Environments: dev, stage and prod

Every environment should come from the same code, with differences only in settings. In Terraform, use a variable file per environment (dev.tfvars, prod.tfvars) and a separate state for each, either a separate folder and backend key per environment or Terraform workspaces. In CloudFormation, deploy the same template as separate stacks with different parameters. Many companies also put production in its own AWS account, so a mistake in dev cannot touch it.

Never put secrets in templates

A secret (a password, API key or token) written in a .tf file or template ends up in Git history forever, where anyone with read access can find it. Store secrets in AWS Secrets Manager, AWS Systems Manager Parameter Store, Azure Key Vault or Google Secret Manager, and let the code reference them. CloudFormation has dynamic references such as {{resolve:secretsmanager:prod/results/db:SecretString:password}}. Even better, let the service manage the secret: Amazon RDS can create and store the master password in Secrets Manager for you (ManageMasterUserPassword in CloudFormation, manage_master_user_password in Terraform).

Policy as code

Policy as code means writing your rules ("no public buckets", "every resource has an owner tag", "only these instance types") as code that runs automatically in the pipeline, before apply. A human reviewer gets tired on Friday evening; a policy check does not.

• Checkov: an open-source scanner with hundreds of ready-made checks for Terraform, CloudFormation, Kubernetes and more.
• Open Policy Agent (OPA): a general policy engine. You write rules in a language called Rego and run them against the plan in JSON form, often with a tool called conftest.
• AWS CloudFormation Guard (cfn-guard): an AWS open-source tool that checks templates against rules you write.
• At the cloud level, AWS Config rules, Service Control Policies and Azure Policy catch what slips through, even for changes made outside IaC.

Tagging standards

Tags are key and value labels on resources, such as env=prod, owner=payments-team, cost-centre=CC-104 and project=results. They let finance split the bill by team, let operations find who owns a forgotten server, and let backup plans select resources. Agree on required tags, check them with policy as code, and set them once for all resources: the Terraform AWS provider supports default_tags in the provider block.

Importing what was built by hand

Most companies already have resources created in the console. You do not need to delete and rebuild them. Terraform can bring existing resources under management with an import block (Terraform 1.5 and later) or the terraform import command, and CloudFormation can import existing resources into a stack. After importing, run plan until it shows no changes, which proves the code matches reality.

Stop console changes

Give people read-only console access to production and let only the pipeline role make changes. Keep a "break-glass" admin role for real emergencies, log its use, and copy any emergency fix back into the code the same day. Run plan or drift detection on a schedule so drift is noticed within hours, not months.