DEV Community

Haripriya Veluchamy
Haripriya Veluchamy

Posted on

When Terraform Taught Me a Version Lesson, Not a Python One

You know those moments in DevOps where everything looks fine until it just… isn’t?
Yeah, this was one of those.


🚀 The setup

I was spinning up a new project in Azure that needed the same Terraform setup as one of my older deployments.
So, naturally, I copied my existing Terraform configuration, made a few small tweaks, and hit terraform apply.

All was well until one small line decided to ruin my day.

In this project, I wanted to run Python 3.12 as my App Service runtime.
My previous setup used Python 3.11, so I just updated the version like this:

site_config {
  python_version = "3.12"
}
Enter fullscreen mode Exit fullscreen mode

Simple change, right?
But Terraform disagreed.


⚠️ The problem

The deployment failed with a strange message saying “Python 3.12 is not available for your system setup.”

That threw me off because when I checked the Azure Portal, the 3.12 runtime was clearly listed.
So why was Terraform acting like it didn’t exist?

At first, I suspected maybe my App Service Plan or region didn’t support it.
Nope. Everything was fine.

Then it hit me: What if it’s not Azure… but Terraform?


🧠 The discovery

I checked the docs for my AzureRM provider version it was 3.75.
Then I noticed something interesting: support for Python 3.12 in App Service was added only in provider version 4.x.

Boom 💡
That was it.

Terraform wasn’t the problem my Terraform provider was outdated and didn’t even know Python 3.12 existed yet.


🔧 The fix

I updated my Terraform block to use the newer provider:

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Ran terraform init -upgrade, then terraform apply again…
and just like that, everything worked perfectly.


💬 The lesson

That day, Terraform taught me something subtle but important:

Sometimes it’s not your code that’s outdated it’s the tool that talks to the cloud.

In this case, my HCL configuration was fine.
The problem was the language barrier between Terraform and Azure fixed instantly by updating the provider version.


🧭 Key takeaway

When you hit strange errors like:

  • “Resource not available”
  • “Invalid attribute”
  • “Value not supported”

…even though the cloud UI says otherwise, check your provider version first.
Cloud APIs evolve fast Terraform needs to stay in sync to understand the new toys.


✨ Final thought

That small hiccup reminded me that DevOps isn’t just about writing perfect code.
It’s about understanding how all the moving parts providers, versions, runtimes, APIs evolve together.

And honestly, sometimes, a failed deployment teaches you more than a smooth one ever could.


Top comments (0)