Introduction

• Identify core Azure concepts Terraform interacts with: tenants, subscriptions, and resource groups.
• Explain how Terraform maps configuration and state to Azure subscriptions and resource groups so resources are created in the intended scope.
• Describe common approaches for environment separation in Azure (for example: dev, test, production) when using Terraform.
• Provide guidance on choosing an appropriate environment separation strategy based on scale, access control, and governance requirements.

​

Key Azure concepts Terraform interacts with

​

Example: Provider configuration

provider "azurerm" {
  features = {}

  subscription_id = var.subscription_id
  tenant_id       = var.tenant_id

  # Recommended: authenticate with a service principal, environment variables,
  # or managed identity rather than hard-coding credentials.
}

​

How Terraform maps configuration and state to Azure

• Provider scope: The AzureRM provider determines the tenant and subscription used for resource operations. You can set subscription_id and tenant_id in the provider or rely on the environment/credentials.
• Resource group mapping: Terraform resources that require a resource group (for example, azurerm_virtual_network, azurerm_storage_account) include a resource_group_name argument to place them in the intended group.
• State file considerations:
  • A single state file can manage many resources across multiple resource groups in one subscription.
  • Use workspaces or separate state backends to separate environments or teams.
  • Store Terraform state remotely (for example, in an Azure Storage Account with blob locking via Azure Blob Storage + azurerm backend) to enable collaboration and locking.

​

Common approaches for environment separation

​

Implementation patterns and examples

• Small scale / low risk: Use a single Azure subscription; create resource groups per environment. Use Terraform workspaces or separate state files per environment.
• Medium scale: Use one subscription per environment. Configure provider per environment or use different backend states and variable sets.
• Enterprise scale: Use management groups to organize subscriptions, centralize shared services in dedicated subscriptions, and enforce Azure Policy and RBAC. Use separate Terraform state backends and Service Principals or Managed Identities with least privilege per subscription.

​

Example folder layout for multiple environments

• live/
  • dev/
    • network/
    • app/
  • prod/
    • network/
    • app/

​

Choosing the right strategy

• Do you need billing and quota isolation per environment?
• Do different teams require separate ownership and RBAC?
• Is governance (Azure Policy, security baselines) required consistently across all workloads?
• How many subscriptions and management groups will you manage at scale?

• If you need simple separation with limited overhead, use resource groups inside one subscription.
• If billing, quota, and isolation are important, use separate subscriptions per environment.
• For enterprise governance and scale, combine management groups, subscription separation, and centralized shared services.

​

Best practices

• Authenticate Terraform using service principals, managed identities, or secure CI/CD credentials—avoid hard-coded secrets.
• Store Terraform state remotely with locking (Azure Storage Account backend) and enable versioning.
• Use modules to encapsulate environment-agnostic components and reduce duplication.
• Apply Azure Policy and RBAC at the appropriate scope: management group, subscription, or resource group.
• Test changes in a non-production subscription or resource group before applying to production.

​

Links and references

• Azure Provider for Terraform (azurerm)
• Azure management groups and subscriptions documentation
• Azure Resource Manager (ARM) overview