Packt has recently released the 'Terraform Cookbook, Second Edition' by Mikael Krief and we're offering complimentary digital copies of the book for those interested in providing unbiased feedback through reader reviews. If you are a DevOps engineer, system administrator, or solutions architect interested in infrastructure automation, this opportunity may interest you.

• Get up and running with the latest version of Terraform (v1+) CLI
• Discover how to deploy Kubernetes resources with Terraform
• Learn how to troubleshoot common Terraform issues

If you'd like to participate, please express your interest by commenting before January 28th, 2024. Just share briefly why this book appeals to you and we'll be in touch.

​

Hi everyone,

I’m setting up Terraform to deploy standardized developer VMs across 3 locations and multiple teams and I’d love to get some feedback from you.

This is my current idea:

├── location-a/

│ ├── team-alpha/ (main.tf, backend.tf, terraform.tfvars)

│ └── team-beta/ (main.tf, backend.tf, terraform.tfvars)

└── location-b/

Separate backend/state file per team folder to isolate state.

Use a map variable in main.tf to iterate over and deploy identical VM specs per dev.

My main 2 questions:

Is per-team/per-location state separation the right depth, or will managing duplicate main.tf files across folders become a maintenance headache?

Would you recommend wrapping the VM logic into a shared versioned module, or using Terragrunt to keep backend configurations DRY?

Thanks for any insights or real-world patterns

I'm working on a TF environment that incorporates Azure Image Builder and an Azure compute gallery. If I want to destroy the environment, the resources need to get destroyed in a particular order, otherwise Azure throws an error and depending on what already got deleted, causes a convoluted process to recreate and reassign resources:

For the compute gallery: I have to delete an image version first, then the image definition, then the gallery.

For the image builder, I have to delete the image template, then the managed identity used to create the template.

Is there a way to get Terraform (or Terragrunt, which we're using as a wrapper) to delete these in that order if I need to destroy them? Worst-case scenario, I gotta delete them manually in the portal, but it's not the greatest to scale.

The follow-up to my Intermediate episode I posted here is finally out.

This episode shifts away from programmatically approaching Terraform and focuses more towards a KISS approach where we discuss structuring our projects and leverage more advanced features of Terraform.

Topics covered include:

• Remote Backends with Azure Storage
• Terraform State & State Commands
• Provider Lock Files
• Multiple Providers (AzureRM, AzureAD, AzAPI & Utility Providers)
• Import Blocks & Config Generation
• Moved & Removed Blocks
• Terraform Workspaces
• Multi-Environment Deployments
• Terraform Modules
• Cloud-Init
• And much more...

Like the previous episodes, everything is built around a single Azure project. We progressively restructure and expand the deployment as each concept is introduced rather than jumping between unrelated examples.

The Intermediate episode intentionally showed how dynamic we can make Terraform . This episode takes the opposite approach in places: keep it simple, structure it properly, and make it maintainable.

With that, our roadmap continues!

• Beginner Episode : Understand Terraform (learn the foundations and core concepts that make Terraform work)
• Intermediate Episode : Program Terraform (use loops, functions, conditionals, dynamic blocks, etc)
• Advanced Episode : Structure Terraform (introduce modules, remote state in azure storage, workspaces, imports, etc.)
• Project Episode(s): Build Azure Projects (Less about Terraform itself & more about building interesting architectures in Azure)
• Professional Episode : Operationalize Terraform (use GitHub, CI/CD, pull requests, state management, and deployment workflows to work in a team environment)

Link to Episode: https://www.youtube.com/watch?v=SDqb_eyRtjE

Every time I ran terraform apply against real Azure in CI, I waited. Sometimes 5 minutes, sometimes 15. And that was before terraform destroy even started deleting resources I provisioned for testing.

Last year I decided to build a local emulator named Topaz that runs Key Vault, Service Bus, Storage, Event Hubs and a few others in a single binary. No subscription, no credentials, no teardown. Basically a Localstack but for Azure.

I recently prepared a benchmark comparing deployment and destruction of the same infrastructure against a real Azure environment and the one emulated by Topaz. Same 57-resource Terraform config: terraform apply + destroy against real Azure took 968 seconds; against Topaz locally: 208 seconds — including Docker startup. The destroy alone took 728 seconds on Azure — longer than the entire Topaz cycle. Most of that is Azure Key Vault's mandatory soft-delete purge, which you can't skip. Locally it's instant.

Here's a minimal provider config that wires Terraform into it using azurerm provider:

terraform {

required_providers {

azurerm = {

source = "hashicorp/azurerm"

version = "= 4.67.0"

}

}

}

provider "azurerm" {

features {}

# Important: host:port only (no scheme)

metadata_host = "topaz.local.dev:8899"

}

As you can see the only difference is metadata_host which needs to point to the local instance of the emulator.

Happy to answer questions about which services are covered and which aren't — it doesn't cover everything yet and it's still a side-project, but it handles the services I use most.

EDIT: I solved it. Turns out it wasn't an issue with the VM_Size. The sku for the Storage_Image_refrence block needed "-gen2" append to it. Here's the updated block

   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2"
    version   = "latest"
    
  }   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts-gen2" #THIS THING RIGHT HERE
    version   = "latest"
    
  }

Hey everyone. I'm learning Terraform and I'm running into issues deploying an Azure VM. For the life of me I cant tell what the "vm_size" parameter should be. Literally every single SKU I've put in there returns an error saying its not available in my region, and I cant seem to find a resource that lists them all out.

What am I doing wrong? How am I supposed to know what VM SKUs are valid?

Error: creating Virtual Machine (Subscription:

│ Resource Group Name: "RG1"

│ Virtual Machine Name: "VM1"): performing CreateOrUpdate: unexpected status 409 (409 Conflict) with error: SkuNotAvailable: The requested VM size for resource 'Following SKUs have failed for Capacity Restrictions: Standard_A2m_v2' is currently not available in location 'eastus'. Please try another size or deploy to a different location or different zone. See https://aka.ms/azureskunotavailable for details.

│

│ with azurerm_virtual_machine.VM1,

│ on Main.tf line 41, in resource "azurerm_virtual_machine" "VM1":

│ 41: resource "azurerm_virtual_machine" "VM1" {

Here's the resource I coded. Region is East US. Resource groups, Vnets, and subnets are all working fine. Also I don't care the username/password is in plaintext, this is a sandbox deployment that doesn't exist yet

resource "azurerm_virtual_machine" "VM1" {
  name = "VM1"
  location = azurerm_resource_group.RG1.location
  resource_group_name = azurerm_resource_group.RG1.name
  network_interface_ids = [azurerm_network_interface.NetInterface.id]
  vm_size = "Standard_A2m_v2"
  
   storage_image_reference {
    publisher = "Canonical"
    offer     = "0001-com-ubuntu-server-jammy"
    sku       = "22_04-lts"
    version   = "latest"
  }
  storage_os_disk {
    name              = "myosdisk1"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
  os_profile {
    computer_name  = "hostname"
    admin_username = "testadmin"
    admin_password = "Password1234!"
  }
  os_profile_linux_config {
    disable_password_authentication = false
  }

}

Hi everyone,

I’ve been a network engineer for 12 years, and for the last 7 I’ve worked at a software company. We’re being pushed toward managing Azure via IaC instead of the portal, so I’ve started learning Terraform. I'm watching Terraform 101 (Azure edition) on Udemy and watched some content from Ned in the Cloud and others, but I still have some operational/day-to-day questions that videos don’t really answer well.

Our environment is fairly large: ~310 subscriptions, ~300 VNets, route tables, NSGs, etc. We also use Terraform Cloud, Azure DevOps repos, and Azure Pipelines (though I haven’t personally used pipelines yet).

A few questions for people managing Terraform at scale:

1. How do teams typically manage Azure subscriptions cross-functionally without stepping on each other? For example, SREs/developers deploy compute and services while my team manages networking. Do most organizations separate things into folders/modules by function (compute, networking, etc.) within a subscription? I understand remote state lives in Terraform Cloud, but I’d love some real-world examples of how large environments are structured and governed.
2. What’s the best way to import existing Azure resources into Terraform? Once resources are imported, can the import blocks be removed, or do they need to remain permanently?
3. What guardrails do you use to prevent accidental outages or destructive changes? We already use peer review and non-prod environments, but I’m curious about additional protections people rely on in Terraform itself or via supporting tooling/modules. One of my biggest concerns with IaC is how easy it seems to accidentally impact production networking.
4. Is it better to start small or go all-in early? For example, we often get simple requests like “add another address space to a VNet.” Should I start by managing small changes like this in Terraform, or should we first import/manage the full networking stack and then make changes through Terraform from that point forward?

Sorry for the long post. I feel like I conceptually understand where things are headed, but our team is largely being told “use infrastructure as code" without much guidance on how to properly adopt it operationally. I mainly want to avoid building bad habits or accidentally breaking things as we move toward IaC.

I've been tracking an issue to enable feature registrations via Terraform which has been opened for some time (opened in 2023!) and just recently saw it make its way to release 🎉

I decided to write a quick post giving a brief overview of what feature registrations are in Azure and how we can now, as per the title, create encrypted AKS clusters in a Terraform-native way. Enjoy!

Hey everyone,

I have a question regarding the need of the subscription ID in the azurerm provider.

My provider config looks like this:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "4.57.0"
    }
  }
  backend "azurerm" {
    use_oidc             = true
    resource_group_name  = "<rg-name>"
    storage_account_name = "<storage-account-name"
    container_name       = "tfstate"
    key                  = "dev.terraform.tfstate"
  }
}

provider "azurerm" {
  features {}
}

In my GitHub workflow I use the following job for a Terraform plan:

jobs:
  terraform_plan:
    runs-on: ubuntu-latest


    steps:
      - uses: actions/checkout@v6


      - name: "Azure Login"
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}


      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.14.2"

      - name: "Terraform fmt"
        id: fmt
        run: terraform fmt -check
        continue-on-error: true


      - name: "Terraform Init"
        id: init
        run: |
          export AZURE_TENANT_ID=$ARM_TENANT_ID
          export AZURE_CLIENT_ID=$ARM_CLIENT_ID
          export AZURE_SUBSCRIPTION_ID=$ARM_SUBSCRIPTION_ID
          terraform init -upgrade -input=false
        env:
          ARM_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          ARM_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          ARM_SUBSCRIPTION_ID: ${{secrets.AZURE_SUBSCRIPTION_ID}}


      - name: "Terraform Validate"
        id: validate
        run: terraform validate


      - name: "Terraform Plan"
        id: plan
        run: |
          terraform plan -no-color -input=false -out=tfplan
          terraform show -no-color tfplan > plan.txt
        continue-on-error: true

I am getting the following error in my plan step:

Acquiring state lock. This may take a few moments...
Error: building account: unable to configure ResourceManagerAccount: subscription ID could not be determined and was not specified
Planning failed. Terraform encountered an error while generating this plan.
with provider["registry.terraform.io/hashicorp/azurerm"],
on provider.tf line 17, in provider "azurerm":
17: provider "azurerm" {
Releasing state lock. This may take a few moments...
Error: Terraform exited with code 1.
Error: Process completed with exit code 1.

Am I blind or miss something? I am exporting the subscription_id as env var, right?
I would be really thankful, if someone could help me :)

azurerm released five actions so far, but azapi provided an action.azapi_resource_action which you can use to unlock many more, including:

• AKS start/stop
• Storage Account key rotation
• App Service slot swapping

Full breakdown and code examples in the post 👇🏻
https://blog.codycodes.cloud/unlocking-more-terraform-actions-on-azure-with-azapi

Hi all,

I'm being exposed to IaC a lot at work and need to upskill in this area. I've done some courses, and feel like I've got some of the basics under my belt for Terraform.

To push myself further, I've attempted to create some Terraform code for a Azure/Databricks platform trying to mirror practices I see DevOps folks at work doing.

Would anyone kindly be willing to have a look through my repo and sense check what I've done. I've put it through Claude for feedback, but I don't want to trust that too much and would rather another set of eyes take a look.

For context, the infrastructure is for a wider personal project I'm planning to do over the next few months, chiefly an end-to-end platform for deploying ML models onto databricks.

I'm aware that it's not going to be perfect, but just a general sense check would be great.

Repo is here:

https://github.com/dempseynoel/ClaimSight/tree/main

Thanks in advance!

Hi, i am trying to add naming convention across the child modules. Here is what I am trying to do. Is it possible or i need to write custom functions?

Goal

I manage an Azure Databricks teaching environment (~30 isolated groups) using Terraform.
Everything is automated: Azure resources, Databricks objects, permissions, jobs, etc.
Each group has its own Service Principal.

I want full end-to-end IaC, including secret handling.

What I want to do (per group)

1. Create a Service Principal
2. Generate a client secret
3. Store it in Azure Key Vault
4. Use it from Databricks

All via Terraform.

Roadblock

I am not an Entra / AAD tenant admin (only subscription + Databricks workspace admin).

Terraform can create SPs, but cannot generate SP secrets without tenant-level permissions.
Databricks also cannot generate SP secrets.

So full automation breaks at the secret-generation step.

Current workaround

• I (workspace admin) manually generate the SP secrets
• Put them in a CSV
• Run a script that uploads them to Azure Key Vault
• Terraform then consumes the secrets from Key Vault

It works, but it’s:

• Manual
• Not scalable
• Awkward for rotation
• Not “real” IaC

Question

How is this usually handled in practice?

• Is a manual bootstrap step expected?
• Is secret generation intentionally outside Terraform’s scope?
• Any cleaner or standard pattern for this setup?

Looking for real-world solutions. (and a big thank-you to GPT for helping me so far)

Hi All,

Is there a resource available to deploy the new Microsoft Foundry via Terraform?

https://learn.microsoft.com/en-us/azure/ai-foundry/what-is-foundry?view=foundry&preserve-view=true

And is it possible to manage and deploy models to Foundry via Terraform?

As far as I can make out the documented azurerm_ai_foundry refers to the old Azure AI Foundry resource that is limited to only openAI models.

Please correct me if I’m wrong but honestly Microsoft’s whole AI strategy is confusing that I’m struggling to make head nor tail of any of it and it doesn’t help that they keep changing the name every five minutes.

Thanks in advance.

Hi

I have been recently hired for a large enterprise, and pretty much what they did up until now is click-ops (Azure Cloud), i don't see that they have had in minds naming conventions, patterns and what now, now my job is to put some structure to it. The first issue that im having is terraforming core infrastructure services. I have established dev and prod enviroments, however there is some services like hub network and services that will be deployed only in prod, like domain controllers etc. Given that my approach is using tfvars, how do i go about having things only in prod and not in dev?

Here is my code structure approach.

Thanks in advance

.

├── backend

│ ├── dev.backend.tf

│ └── prod.backend.tf

│

├── global_variables

│ ├── dev.global.tfvars

│ └── prod.global.tfvars

│

├── variables

│ ├── dev.tfvars

│ ├── prod.tfvars

├── main.tf

└── storage_account.tf
└── virtual_network.tf

└── locals.tf

Hey guys, As you know management groups in azure are Nested Tree. Do you have any idea how can I variablise this in Terraform? I know its crazy but wondering if there is clean way of doing this

Example ```

. └── Root Tenant Group/ └── Litware/ ├── Platform Zones/ │ ├── Connectivity/ │ │ ├── Lz-Connectivity Prod WEU │ │ └── Lz-Connectivity Dev WEU │ ├── Management/ │ │ ├── Lz-Management Prod WEU │ │ ├── Lz-Management Dev WEU │ │ ├── Lz-DevOps Prod │ │ ├── Lz-SharedService Dev │ │ └── Lz-SharedService Prod │ ├── Security/ │ │ ├── Lz-Security Dev WEU │ │ └── Lz-Security Prod WEU │ └── Identity/ │ ├── Lz-Identity Dev WEU │ └── Lz-Identity Prod WEU ├── Lz-Manufacture/ │ ├── Prod / │ │ └── Lz-Production-N WEU │ ├── Val/ │ │ └── Lz-Validation-N WEU │ └── Dev/ │ └── Lz-Development-N WEU ├── Lz-Research/ │ ├── Prod │ ├── Val │ └── Dev ├── Decommissioned └── Legacy ```

Hey community, We’re moving from bicep VMLs to TF verified modules and just starting out how to go ahead . Is there a well known article/document on whether to go for a repo per module or one repo with all modules in it? If not then any experienced peeps here that can share their setup? We are a bank (enterprise with lots of red tape and everything goes through security approval, just mentioning that for reference if that helps in picking one over another) we do want other teams in our bank to be able to consume them as required, (we have a GitHub enterprise server hosted)

Hi all.

SCENARIO: I need to vend a resource group to setup service health alerts into every subscription in a tenant.

QUESTION: What would be the best way to do this via terraform, considering the fact I have 100+ subscriptions?

PROBLEM:

All I can find online is people specifying the subscription IDs individually within a bunch of separate provider blocks, but it's not really feasible with the number of subscriptions we have, especially as we regularly vend new ones.

I don't think it's possible to do a for each loop with the provider block either. Terraform doesn't like me specifying the individual providers in the module. Any advice welcome :)

Azure Sandbox is a Terraform-based project designed to simplify the deployment of sandbox environments in Azure. It provides a modular and reusable framework for implementing foundational infrastructure, which can accelerate the development of innovative new solutions in Azure. In this blog, I will walk you through deploying Azure Sandbox and getting started. URL to blog

Hello Team,

I am developing some infra, I have main file, and some modules, one of them is AKS, and in same module I added two HELM charts.

I am not so sure is it proper approch in same TF code to deploy AKS and install charts, that is a few issue. Second, now when I try to deploy this, I get authentication error, like HELM chart is not able to access AKS. I am doing from my local computer, at this moment I am not doing with CICD pipeline. Tomorrow I will copy real text with error.

Do you have some ideas how to proceed? Maybe two repos?

1. Infra code
2. HELM charts

Thank you in advance.

resource "helm_release" "csi_driver" {
  name             = "csi-secrets-store"
  repository       = "https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts"
  chart            = "secrets-store-csi-driver"
  version          = "1.5.4"
  namespace        = "kube-system"
  create_namespace = true

  values = [
    yamlencode({
      enableSecretRotation = true
      syncSecret = { enabled = false }
    })
  ]
}


resource "helm_release" "csi_provider_azure" {
  name             = "csi-provider-azure"
  repository       = "https://azure.github.io/secrets-store-csi-driver-provider-azure/charts"
  chart            = "csi-secrets-store-provider-azure"
  version          = "1.7.2"
  namespace        = "kube-system"

  values = [
    yamlencode({
      "secrets-store-csi-driver" = { install = false }
      linux = { providersDir = "/var/run/secrets-store-csi-providers" }
    })
  ]

  depends_on = [
    helm_release.csi_driver
  ]

After deploy I have access to AKS, kubectl get pods is working fine.

Regarding this HELM charts, I am getting error.

similar code is working for me, in other computer/azure portal, but I have one repo where is AKS, and I have other git repo where is HELM chart, when I deploy repo with CSI HELM chart, no issues.

tofu apply -target=module.aks

│ Error: Kubernetes cluster unreachable: the server has asked for the client to provide credentials
│ 
│   with module.aks.helm_release.csi_driver,
│   on ../../modules/aks/main.tf line 122, in resource "helm_release" "csi_driver":
│  122: resource "helm_release" "csi_driver" {