Faced with the repetitive task of spinning up secure ‘Landing Zones’ for my Terraform projects and bootstrapping an initial Terraform codebase, I decided to create a vending machine for that. My Terraform UseCase Vending solves that problem by packaging every required building block into a single reproducible workflow.

My Module is inspired by two awesome projects:

• az-bootstrap
• Automate the Automation with Terraform (GH-ATAT)

Development workflow

The setup optimized for my development workflow:

1. A new GitHub branch is created for each new feature.
2. Once the feature is complete, a pull request (PR) is submitted to merge it into the main branch.
3. A GitHub action is executed as part of the PR. This validates the code (TFlint), performs a security scan (Trivy), and generates a plan.
4. If the pull request is merged into the main branch, a deployment is carried out in the development environment via a GitHub action.
5. A drift-detection task performs a final verification.
6. The result is then manually checked (human in the loop).
7. If the desired result is achieved, a GitHub release is created, triggering a GitHub action that deploys to the production environment.
8. Another drift-detection task performs a final verification.

The drift-detection is implemented as terraform plan with detailed exitcode:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

    - name: Terraform Plan as Drift Check
      run: |
        export exitcode=0
        terraform plan -var-file=./environments/$VAR_FILE  -input=false -detailed-exitcode -no-color || export exitcode=$?
        
        echo "exitcode=$exitcode" >> $GITHUB_OUTPUT
        
        if [ $exitcode -eq 1 ]; then
          echo Terraform Plan as Drift Check Failed!
          exit 1
        else 
          exit 0
        fi

Components

• Azure Identity & Terraform State
  • Creates EntraID Federated Identity Credential
  • Sets up an Azure Storage Account for Terraform remote state (with CMK encryption and security best practices)
• GitHub Integration
  • Creates a GitHub repository with:
    • Two deployment environments
    • Secrets and variables for deployments
    • Branch protection rule
• Project Starter Code
  • Adds a basic Terraform Azure codebase with:
    • Minimal Terraform File- and Variables-Structure
    • GitHub Copilot instructions
    • GitHub devcontainer configuration
    • GitHub Actions for deployments
    • VSCode configuration
    • Trivy, TFLint configuration files for security scan and linting

Azure Identity

For each UseCase an individual EntraID Federated Identity Credential-Pair (one per environment) is created. The Credential uses the GitHub Environment as identifier, e.g. ‘repo:vMarkusK/terraform-azure-aabb:environment:dev’.

The following chapters will cover how to configure GitHub with OIDC for Terraform deployments, including remote state.

Terraform State

In one of my previous blog posts, I already shared my Terraform AzureRM Backend Automation. Most of the code from this project was reused and integrated with the other components.

The Azure Storage Account and the prerequisites for the encryption are placed in a dedicated Resource Group.

GitHub environments

My Terraform projects typically follow the ‘single stack with configuration files per environment’ pattern. This involves creating two GitHub environments: Production and Development.

Each GitHub environment (Production and Development) contains the unique configurations for the stage.

GitHub Branch protection rule

The branch protection rule can be difficult to manage with Terraform if you regularly update some of the files. I decided to temporarily remove the branch protection rule when a ‘managed file’ needs to be updated. The other option would be to create a branch and merge with a pull request (PR). This might be cleaner, but it would be much more complex to implement.

Temporarily removing branch protection is implemented using explicit dependencies and the ‘replace_triggered_by’ lifecycle attribute:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

resource "github_repository_ruleset" "this" {
  name        = "protect-branch"
  repository  = github_repository.this.name
  target      = "branch"
  enforcement = "active"

  conditions {
    ref_name {
      include = ["~DEFAULT_BRANCH"]
      exclude = []
    }
  }

  rules {
    pull_request {
    }
  }

  depends_on = [
    github_repository_file.gitignore,
    github_repository_file.devcontainer,
    github_repository_file.tflint,
    github_repository_file.trivy,
    github_repository_file.vscode_settings,
    github_repository_file.github_settings,
    github_repository_file.github_env_tfvars,
    github_repository_file.github_env_tfbackend,
    github_repository_file.github_tf_files,
    github_repository_file.github_wf_files
  ]

  lifecycle {
    replace_triggered_by = [
      github_repository_file.gitignore,
      github_repository_file.devcontainer,
      github_repository_file.tflint,
      github_repository_file.trivy,
      github_repository_file.vscode_settings,
      github_repository_file.github_settings,
      github_repository_file.github_env_tfvars,
      github_repository_file.github_env_tfbackend,
      github_repository_file.github_tf_files,
      github_repository_file.github_wf_files
    ]
  }

}

Project Starter Code

The vended project comes with a broad set of files. Some are supporting files (e.g. devcontainer.json), while others are required for the Terraform module.

Most files are created 1:1, but some require templating with variables to fit the target project. Here are both examples of how the vending machine manages files in the target repository:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

# created 1:1
resource "github_repository_file" "trivy" {
  repository          = github_repository.this.name
  branch              = "main"
  file                = "trivy.yaml"
  content             = file("${path.module}/files/trivy.yaml")
  commit_message      = "Managed by Terraform"
  commit_author       = var.commit_user.name
  commit_email        = var.commit_user.email
  overwrite_on_create = true
}

# templating with variables
data "template_file" "env_tfvars" {
  for_each = toset(local.environments)

  template = file("${path.module}/files/tfvars.tftpl")
  vars = {
    subscr_id = var.subscription_id
    env       = each.key
    usecase   = var.usecase
    suffix    = random_string.suffix.result
  }
}

resource "github_repository_file" "github_env_tfvars" {
  for_each = toset(local.environments)

  repository          = github_repository.this.name
  branch              = "main"
  file                = format("environments/%s.tfvars", each.key)
  content             = data.template_file.env_tfvars[each.key].rendered
  commit_message      = "Managed by Terraform"
  commit_author       = var.commit_user.name
  commit_email        = var.commit_user.email
  overwrite_on_create = true

  lifecycle {
    ignore_changes = [
      content
    ]
  }
}

Repo content after vending:

.
├── .devcontainer
│   └── devcontainer.json
├── .github
│   ├── copilot-instructions.md
│   └── workflows
│       ├── Test.yml
│       ├── ValidateAndDeploy.yml
│       └── ValidateAndPlan.yml
├── .gitignore
├── .tflint.hcl
├── .vscode
│   ├── extensions.json
│   └── settings.json
├── README.md
├── environments
│   ├── dev.tfbackend
│   ├── dev.tfvars
│   ├── prod.tfbackend
│   └── prod.tfvars
├── locals.tf
├── main.tf
├── outputs.tf
├── trivy.yaml
└── variables.main.tf

Environments

The files in the Environments folder are the glue that hold the ‘single stack with configuration files per environment’ pattern together. There are dedicated backend configurations and variable values for each environment.

GitHub Workflows

Pull Request

The workflow is triggered by pull requests (PRs) to reduce the risk of failed deployments and ensure code quality.

0. Workflow Trigger

• Executes on PR creation or updates (opened, synchronize)
• Can be triggered manually via workflow_dispatch

1. Lint Job

• Runs TFLint to validate Terraform code syntax
• Minimum severity level: error
• Uses latest TFLint version

2. Scan Job

• Executes Trivy security scanner in IaC (Infrastructure as Code) mode
• Fails on CRITICAL, HIGH, or MEDIUM severity findings
• Prevents insecure configurations from proceeding

3. Terraform Dev Job (Depends on Lint & Scan)

• Network Access: Dynamically whitelists GitHub Runner IP to access hardened Storage Account
• Authentication: Uses Azure OIDC (no secrets needed)
• Steps:
  • Azure login via federated identity
  • Whitelist runner IP (required for state access)
  • Checkout code
  • Initialize Terraform with backend config
  • Format check
  • Validation
  • Generate plan
  • Remove runner IP from whitelist (cleanup)
  • Post plan summary as PR comment with collapsible sections

Push to Main or Release

This workflow is triggered by pushes to the main branch and by release creation. Both triggers result in a deployment (terraform apply), but to different environments.

0. Workflow Trigger

• Executes on push to main branch
• Executes on GitHub release creation
• Can be triggered manually via workflow_dispatch

1. Lint Job

• Runs TFLint to validate Terraform code syntax
• Minimum severity level: error
• Uses latest TFLint version

2. Scan Job

• Executes Trivy security scanner in IaC (Infrastructure as Code) mode
• Fails on CRITICAL, HIGH, or MEDIUM severity findings
• Prevents insecure configurations from proceeding

3. Terraform Dev Job (Only on push to main)

• Network Access: Dynamically whitelists GitHub Runner IP
• Authentication: Uses Azure OIDC (no secrets needed)
• Steps:
  • Azure login via federated identity
  • Whitelist runner IP (required for state access)
  • Checkout code
  • Initialize Terraform with backend config
  • Apply changes to development environment
  • Remove runner IP from whitelist (cleanup)

4. Terraform Prod Job (Only on release)

• Network Access: Dynamically whitelists GitHub Runner IP
• Authentication: Uses Azure OIDC (no secrets needed)
• Steps:
  • Azure login via federated identity
  • Whitelist runner IP (required for state access)
  • Checkout code
  • Initialize Terraform with backend config
  • Apply changes to production environment
  • Remove runner IP from whitelist (cleanup)

5. Drift Detection Jobs (Both environments)

• Runs after Dev and Prod deployments complete
• Performs terraform plan to detect state drift
• Alerts if actual infrastructure diverges from desired state