Terraform is a "desired state" system, where configuration describes a set of objects that should exist and then Terraform itself (with the help of provider plugins) plans a set of changes to converge on that state.
Although it's possible to write configurations where the desired state is derived from existing objects in remote systems, it's important to ensure that the desired state you are describing won't change the source objects you were making the decision based on, because in a situation like that you can easily create a contradiction and therefore a configuration that can never converge because each time you apply it you change the desired state.
In your case, consider what would happen over the course of several runs if you start with none of the VLANs claimed:
- On the first
terraform apply
, VLAN 100 is available and so will be used. Presumably a side-effect of applying that change is to "claim" that VLAN.
- On the second
terraform apply
, VLAN 100 is no longer available and so this configuration would select VLAN 101. Applying this change would "claim" VLAN 101 as an updated VLAN for this resource, but would release VLAN 100.
- On the third
terraform apply
, VLAN 100 is available again and so the configuration reverts back to claiming that one, releasing VLAN 101 back to the available pool again.
- ...
This cycle would continue indefinitely, because each time you apply a change you alter the source information that the desired state was based on and thus change the desired state.
To achieve a design like this will typically require something outside of Terraform to be issuing leases for VLANs and tracking when they are released so that they can be reused. An existing example of that in AWS is how you would typically declare an EC2 instance without specifying an explicit IP address for it and EC2 itself will choose an available IP address from the selected subnet and associate it with the EC2 instance's network interface.
The IP address is not specified as part of the desired state, so there is no contradiction: the instance just gets whichever IP address it gets, and the remote system keeps track of its assignment to that EC2 instance and returns it to the pool afterwards.
There may not be an existing similar ready-to-use system for assigning VLAN IDs as you want to do here, and so you may need to build that system yourself if you intend to manage these with Terraform. You might also conclude that Terraform is not a good tool to use for your particular problem, since you seem to need a system that is able to itself track leases of objects from a pool and Terraform is not designed to do that.