This message was deleted.

i'd recommend against doing a count-based approach like this. Imagine if you remove a policy in the middle of the list, it would cause each item after that to be renamed and thus recreated. I think a better approach would be to name your PolicyAssignments based on the data you are reading in. E.g. the

policyname

in your JSON object.

The documentation doesn't delve very deep into using external data or more complex configurations beyond simple key/values.

i think this is on purpose. the best way to retrieve outside data depends on your specific situation, and since you're given the full power of a general purpose language, there's a lot of options. In your specific case, where is the "source of truth" for this configuration data you want to pass into Pulumi?

Thanks for the feedback Mike, your right about the count naming. I didn't consider that I could just reuse the policy name. Right now I'm wanting to do a proof of concept comparison between how Terraform deploys a landing zone based set of azure policies across various management groups. Ideally I would have json files with a list of the policies and let the iterate through that so that they can be updated easily then rerun. That way an architect can provide the policies without needing to fully understand the automation, just the expected data structure. I did a quick test just now of reshuffling the policy order in the inline list and I can see why using the count is a silly idea.

reading a json file into a python object and iterating over it makes sense then. Can just parse it with

json.load

f = open("./path/to/yourData.json")
policySet = json.load(f)
...

Ah right, very cool that we can treat it as pure code with classes that do magic.