Hi all,
we are preparing to setup a new Azure Tenent completely from scratch with terraform and observing some strange thing on the Azure Policy configuration.
We have applied the Azure Policy configuration successfully and it’s working like it should.
But when we now run terraform plan again, we see following output.
terraform apply the output is still the same on the next plan.
Anyone an idea, why this is happening?
thanks
Joerg
Hi @joerg.lang,
I’m not familiar with this specific resource type, but this symptom seems like a provider bug.
Sometimes remote APIs allow multiple ways to describe the same situation, but when you read an object from the remote API the server “normalizes” the data into some preferred form.
In this case, it seems like the remote API permits parameter_values to be either null or an empty JSON object with equivalent meaning, but when reading from the API it normalizes null to be "{}" instead.
It’s part of a provider’s responsibility to compensate for this sort of normalization rule by noticing if the value returned by the remote system is just a different way to write the same information from the prior state, and then preserving the value from the prior state to avoid proposing a pointless action like the one shown in your screenshot.
It seems that the hashicorp/azurerm provider is lacking a rule to handle this particular situation, and so it’s treating "{}" and null as meaningfully different values, and so it thinks that you’ve changed this value outside of Terraform and is proposing to repair that difference by setting the argument back to null again.
If I’m correct about the above (which I might not be!) then a workaround for now would be to write your configuration so that it sets this argument to be "{}", or equivalently jsonencode({}), in any situation where your configuration would set it to null. (Leaving it totally unset is equivalent to setting it to null.)
That workaround is the best we can do with just changes to your configuration, and a real fix here will require changing the provider itself to include this normalization rule. I think there’s already an issue open for this here, which you could add an upvote 
reaction to if you agree that this issue is describing the problem you’ve encountered:
Many thanks for your awesome feedback, that was indeed the case.
I have add a comment with a little bit more description to whats “not working” and with the workaround.
Many thanks