Hi all, I'm working with the azure-native provider using the pulumi Java SDK. It works too well 🙂 I have two stacks called

development

and

production

. I also have two Azure subscriptions called

development

and

production

. I want the stack for each environment to provision resources in its corresponding subscription. I have

Pulumi.development.yaml

and

Pulumi.production.yaml

config files. I noticed that even if I don't do

pulumi config set azure-native:subscriptionId <subscription id>

then pulumi works just fine for both stacks. This is surprising because I would expect pulumi / native axure provider to fail or use the default az account, which in my case is set to

development

. However, both the

dvelopment

and

peoduction

stacks work well (when I do pulumi refresh I get no changes for both except for a minor etag on a vnet, which changes all the time). This is a little concerning because if pulumi uses some magic to decide which subscription to target then this is a cause for concern. Can someone explain what's going on? am I missing something or misunderstanding something? (edited)

Locally Pulumi uses the Azure CLI to authenticate to Azure, so it should create your resources in the subscription where your are currently logged in. If your resources are already created, the state contains the identifiers of the resources so I guess whatever the subscription you are currently logged in, pulumi can sucessfuly do a refresh (if your azure cli account has the permissions on both the subscriptions). At least that's how I understand it

OK. I see. That makes sense. Possibly it's even at the stack level. Whenever a stack is created it is created for a particular subscription. So, even when creating new resources it uses the correct subscription.

I've ran into problems before where I managed to deploy half the resources in another subscription because the wrong one was selected via az cli. Now I have

pulumi.Config("azure-native").require("subscriptionId")

in all of my stacks so that it has to be excplitily defined.