As I think you’ve already learned from the documentation, Terraform’s “drift detection” is highly dependent on how a provider is implemented, and so unfortunately there cannot be a consistent general answer for how it will behave in all cases.
However, it might help to know how Terraform defines “drift”:
During the plan step, Terraform asks the providers to read the remote object bound to each of the resource instances and generate a new state object based on the current remote object state. Terraform then saves that updated object. Next, it sends the updated state object and the current configuration object to the provider so the provider can compare the two and determine whether the configuration and state are equal. If not, one of the following is presumably true:
- The remote system was unchanged but the configuration has changed since the last apply. (The normal case: updating the configuration)
- The configuration is unchanged but the remote system has changed since the last apply. (This case is what you might call “drift”.)
This operation only considers the current state and the current configuration, so it can’t actually distinguish between the two cases above and the result is the same in either case: the provider tells Terraform to take some sort of action that will produce a new state object.
Under this model, there are a number of different reasons why a particular sort of “drift” might not be detected, including but not limited to:
- It might be a change to some aspect of the remote object that the current provider version isn’t aware of at all, so the change is invisible to the provider.
- It might be a change to something that was not specified in the configuration at all but instead selected dynamically by the remote API. In that case, the provider has no option but to assume the remote API is the “correct” value, because there’s no configuration to compare it with.
- The change was to something value that the underlying API considers to be “write-only”, and so the provider can’t read back the updated value to compare it with the configuration. This is essentially the opposite of the previous case: the provider assumes the configuration is correct because it has no remote API value to compare with.
- You might have created something that the provider considers to be an entirely new object rather than a change to your existing object, in which case the new object gets ignored so that multiple Terraform configurations and potentially other systems can all coexist in the same account. (The provider assumes that the new thing you created is managed by some other Terraform configuration or some other system.)
- The provider might consider the change you made to have a “functionally equivalent” meaning to what you originally configured, and so decline to perform an update for it. One example of this is if a particular value is a JSON string and you just changed some space characters between tokens, and so the it still represents the same JSON value even though the source code is different.
- There’s just a bug in the provider that causes it to fail to report a change that it ought to have reported.
I’m not familiar enough with the specific azure features you mentioned to known if what you saw is caused by one of the situations I described above, or some other similar situation I didn’t think of while I was writing this out.
However, your note that “it computes these settings” sounds like the terminology provider developers typically use to talk about values that are unstated in the configuration and chosen by the remote system, and so my guess would be that this is a situation where the configuration doesn’t say anything about IP restrictions, and so the provider is just assuming that the objects chosen by the remote API must be correct.