Since IAM Access Control is available per resources and can be combined with MSI now, it would be great to make use of these features inside ARM template.

Take this use-case: I create a new VM and someResource. The VM runs a daemon, which is supposed to modify someResource whenever needed. It's easy to click this setup in the portal and make VM a Contributor for someResource, but impossible to deploy using arm template. Technically, I'm aware that privileges live elsewhere (in AAD), but from user perspective, intuitively they are an attribute of arm resource.

BTW, this one is linked to "RBAC rules need an option to block IAM inheritance" idea.

As a developer, I would like to dynamically create Bot Framework bots in Azure (Bot Channels Registration resources), and use them from NodeJS backend. The creation goes well with azure-cli (with botservice extension), but azure-cli does not allow me to create or generate a password (Microsoft App Password, or App Secret) for the bots. I guess a password is generated upon registration but I am also unable to get that password.

I am creating a "Bot Channels Registration" with the following commands:

$ az bot create --kind registration --location "global" --sku S1 -e <url> --resource-group <group> --name <resource-name> --p "something"
$ az bot msteams create --resource-group <group> --name <resource-name>

... and I want to connect to the bot instance with the following NodeJS code:
this.connector = new teams.TeamsChatConnector({
appId: <MSA-APP-ID>,
appPassword: <PASSWORD>
});

Today, if you apply a lock to a resource group, it will apply to both:
- Resource group
- Any existing or new object within that resource group

What I'd to do is have a resource group have a Lock that only applies to it. In other words, ability to deselect inheritance. This is handy for protecting resource groups from being deleted in one operation, but doesn't limit individual changes. Present day Locks imply once a resource group is created, it is "Locked" to that state forever - which makes logical sense but doesn't seem to fit in spirit of azure.

Use case: Automation account today creates temporary clone of existing production DB to back it up to separate blob storage account. At the end of the automation workbook, it will attempt to remove the DB. Since the tempDB is in the resource group that has a lock on it, the DB can't be removed. I could in theory rework the automation workbook to move the tempDB into another resource group and attempt to delete it from there but that doesn't seem like the correct approach.

I have a Service Bus Namespace that is tagged. It is the only resource in a resource group that is the only resource group in the subscription.

When evaluating the costs on the subscription there is an untagged cost classified as Other classic resources => Base Unit - Standard Messaging.

My problem is that the tags from the Service Bus Namespace is not inherited to the Base Unit - Standard Messaging, and tagging on the Service Bus Namespace is the lowest level of tagging I have access to.

Could inheriting of the tags from the Service Bus Namespace to the units associated with the Service Bus Namespace be enabled?

Could a similar inheriting be enabled in general in similar scenarios.

I have created first VM from Azure portal interface and it works good. I tried to deploy second VM using ARM template that is available from first VM. And I can't do it quickly. Primarily, I have to solve task with some dependency loops because I got message 'Circular dependency detected on resource: '/subscriptions/xxxxxxxxx/resourceGroups/MOD03VDSC/providers/Microsoft.Network/networkInterfaces/autoconfigvm7312'.
You can't use template soon after creating VM by portal. This template will not work. You will get an error. Firstly you have to analyze this template for circular dependency instead of use it immediately.
In this template in declaration of network interface there is a part "dependsOn" where is a link to the parameter of VM. If you delete this dependence template will work.
So, I can't quickly redeploy simple VM after first creating. It looks like a bug.