What is the Preferred Practice to Create an Azure ALM-Friendly Development and Deployment Environment?

I am finally jumping into the Azure development party, and I have a question in regards to the preferred practice in creating my development and deployed environments.

To start with, I am learning Azure Key Vault and it has presented the perfect example scenario of my core question.

In my development (and ALM) process, I usually have:

• Local development environment
• Deployed development environment (CI/CD)
• Testing Environment
• Staging
• Production

For each environment, I usually have an App.config or Web.config with XDT environment transforms that run for each environment and place in environment settings for each of the environments for the external resources that my application uses.

Now, I did see this question, but it is a few years old, so I wanted to revisit it as there seems to have been a lot of work done in particular with the new Azure Resource Manager and the Azure Management API that seems to have replaced Azure Service Management model.

In the case of Azure Key Vault, I am thinking of creating 4 Resource Groups (Development, Testing, Staging, Production) and create an Azure Key Vault instance within each of those groups.

My questions are:

1. Is this a correct way of looking at Azure Resource Groups?
2. From my local development environment, should I connect to resources stored in the Development Azure Resource Group that I create, or is there another preferred mechanism for developing locally? (For instance, are there other emulators like the Azure Storage Emulator that I should consider using?)
3. Is there a more preferred approach to handling my environments than what I have presented?

Thank you in advance for any assistance and clarification!

IMHO (..and I can't pretend I'm an expert),

1. Yes, a resource group per environment sounds reasonable. However, you might want to consider separate subscriptions too (or a separate one just for production) because there are things like AAD (which I assume you're using for Key Vault) that are outside the scope of a resource group. You probably don't want your dev app to accidentally access the production key vault..
2. That really depends on what you're building but if there is no real need to separate between local and cloud dev environments, then I'd say just have 1 environment.
3. See above :)