GitOps with Terraform: Zero-Drift Infrastructure Automation

Infrastructure as Code (IaC) is only effective when changes are strictly governed by automated version control. In ad-hoc environments, engineers often make manual console adjustments that lead to catastrophic configuration drift.

At Austin Software Services, we established a 4-tier GitOps model where no human engineer possesses write permissions in GCP Console. All modifications flow through audited pull requests.

1. The 4-Tier Infrastructure Hierarchy

Our infrastructure is segmented into isolated repositories with strict dependency boundaries:

1. Layer 1 (austinss-org-iac): Root GCP Organization policies, top-level folder hierarchy, and bootstrap state project.
2. Layer 2 (austinss-projects-iac): Project provisioning (austinss-web-dev, austinss-web-prod), shared VPC networks, and WIF pools.
3. Layer 3 (austinss-website-iac / austinss-blog-iac): Workload infrastructure (Cloud Run services, Firestore, Cloud DNS, Load Balancers).
4. Layer 4 (austinss-website-app / austinss-blog-app): Application source code, Dockerfiles, and runtime configurations.

2. Automated PR Plan Verification

Every pull request to develop or prod triggers an automated speculative Terraform plan:

- stage: Plan
  jobs:
    - job: Plan
      steps:
        - template: templates/gcp-wif-auth.yml
        - script: terraform init -backend-config=$(backendFile)
        - script: terraform plan -var-file=$(tfvarsFile) -out=tfplan
        - task: PublishPipelineArtifact@1
          inputs:
            targetPath: tfplan
            artifactName: tfplan-$(envName)

The exact binary plan artifact (tfplan) is archived and passed to the gated apply stage, guaranteeing that the code reviewed on PR is byte-for-byte identical to what executes in production.