In this article I’m going to show you a mechanism to test for destructive changes when writing Terraform modules. You could re-use this capability in your own module development process, for transparency I’m going to do this in the context of a public Azure Verified Module. Some of you may be familiar with my previous post on converting the AVM virtual network module resource to be 100% AzAPI, where I mentioned an experimental PR.

..a simple step to avoid exposing your DevOps Org

Have you noticed how some committers on GitHub have a ‘verified’ badge? This isn’t because the person is special (sorry to burst my own bubble), but rather they have signed their commits with a tool such as the Gnu Privacy Guard (GPG). Commit validation ensures the authenticity and integrity of code by verifying the identity of the author through GPG signatures, providing trust and security in collaborative projects.

Can you make a verified module with only AzAPI?

One of the cool feature switches in the AzAPI Terraform provider is preflight validation. If enabled, this provides further checks against your resources at plan stage, one of which is checking for Azure Policy violations. Cool, right? Let’s see how to enable it: 1 2 3 provider "azapi" { enable_preflight = true } That. Is. It. We’ll make a couple resources: a resource group, a built-in policy assignment restricting locations to New Zealand North & then a demo that will: