After hitting this across enough client projects, I built a free tool to fix it: AzureNamer.

The part that actually bites: per-resource rules

The pattern itself is simple — {type}-{workload}-{environment}-{region}-{instance}, e.g. kv-payments-prod-eus-001. What's not simple is that the rules change per resource:

So stPayments-Prod looks perfectly reasonable and then fails at deploy — storage accounts reject hyphens and capitals. Multiply that across 200+ resource types and you've got the problem.

What the tool does

• Generates CAF compliant names for 200+ resource types, applying each one's real length and character rules automatically (verified against Microsoft's official naming-rules doc).

• Exports straight to CSV, Terraform, Bicep, JSON or a Markdown — so you get multiple options to export as per your needs.

• Reverse parser: paste an existing name (kv-payments-prod-eus-001) and it breaks back into type / workload / environment / region.

• Free, no login, no signup. It's a static site — nothing to deploy or configure.

Honest scope

It validates format — length, characters, separators. It can't check global uniqueness (that needs a live Azure API call), so it won't save you from a StorageAccountAlreadyTaken collision — but it flags which resources are global and bakes in region + instance entropy to lower the odds.

I'd genuinely like feedback — wrong abbreviations, missing resources, anything off. There's a feedback link on the site.

If naming Azure resources has ever cost you a deploy: https://azurenamingconventions.com

This blog is my Learn in Public journey where I openly document my open-source contributions, real-world DevOps challenges, and the lessons I learn along the way.

This week I shipped my first two Pull Requests to the official hashicorp/terraform-provider-azurerm repository. Here's the complete story.

PR #1: Better Documentation for capacity_reservation_group_id

Issue: #32197

When you associate an existing zonal VM to a Capacity Reservation Group, Terraform was causing a reboot. The reporter asked: “Should this require a reboot, or should the documentation clearly state it?”

What I did:

• Added a clear warning in both azurerm_linux_virtual_machine and azurerm_windows_virtual_machine resources.

• Explained that for zonal VMs this is possible without deallocation, but the feature is currently in Preview by Microsoft.

• Updated the public documentation with the same note and link to Microsoft docs.

PR: docs: improve capacity_reservation_group_id documentation with reboot/Preview note (closes #32197)

PR #2: Fixing a Regression in azurerm_private_endpoint

Issue: #32206

A recent change (#31705) moved validation to plan-time. Suddenly, this config started failing:

private_service_connection {
  name                              = "x_private_endpoint"
  is_manual_connection              = true
  private_connection_resource_alias = "..."
  request_message                   = ""   # ← This was now invalid
}

What I did:

• Changed validation from StringLenBetween(1, 140) to StringLenBetween(0, 140).

• Removed the overly strict empty-string check in CustomizeDiff.

Now the behavior matches the official documentation (the field is truly Optional when is_manual_connection = true).

PR: fix: allow empty request_message when is_manual_connection = true in azurerm_private_endpoint (closes #32206)

The Real Journey

The hardest part wasn’t the code — it was setting up the development environment on Windows:

• Fighting with .terraformrc vs terraform.rc

• Understanding dev_overrides

• Cleaning cache and lock files again and again

• Relearning git rebase and force-pushing

There were multiple moments where terraform plan kept using the old released version. The struggle taught me a lot about how Terraform providers actually work.

What I Learned

• How to properly claim issues and contribute to large Go-based providers.

• The importance of reading CustomizeDiff and schema definitions.

• Git workflow for open-source contributions.

• That even “small” fixes (docs + validation) are genuinely valuable to the community.

What’s Next?

I’m planning to continue contributing regularly to the Terraform AzureRM provider and other DevOps-related open-source projects.

Would love your suggestions — which issue should I tackle next? Drop a comment or tag me on X.

Links

• First PR: docs: improve capacity_reservation_group_id documentation with reboot/Preview note (closes #32197)

• Second PR: fix: allow empty request_message when is_manual_connection = true in azurerm_private_endpoint (closes #32206)

• Terraform AzureRM Provider: https://github.com/hashicorp/terraform-provider-azurerm