The azurerm Provider
Configure Terraform's azurerm provider and authenticate to Azure.
To provision Azure with Terraform you configure the azurerm provider — the
plugin that translates Terraform resources into Azure API calls. You pin its
version and declare a provider "azurerm" block with features {}.
Authentication options, from best to worst for automation:
- Managed identity (when running on Azure) — no secrets
- OIDC / workload identity federation (in CI like GitHub Actions) — no secrets
- Service principal with a client secret — works, but a secret to protect
- Azure CLI (
az login) — convenient for local development
Provider config plus a backend (for state) is the foundation every Azure Terraform project starts from.
terraform {
required_version = ">= 1.6"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.110"
}
}
}
provider "azurerm" {
features {}
# Auth via `az login` locally, or env vars / OIDC in CI:
# ARM_CLIENT_ID, ARM_TENANT_ID, ARM_SUBSCRIPTION_ID, ARM_CLIENT_SECRET
}- Write a
required_providersblock pinning azurerm to a major version. - List the four ways to authenticate the provider and rank them by safety.
- Run
terraform initand explain what it downloads. - Explain why the
features {}block is required.
Cheat Sheet▾
| Item | Detail |
|---|---|
| Provider | provider "azurerm" { features {} } |
| Pin version | required_providers |
| Init | terraform init |
| Local auth | az login |
| CI auth | OIDC / service principal env vars |
| Env vars | ARM_CLIENT_ID, ARM_TENANT_ID, … |
Common Interview Questions▾
What is the azurerm provider?
The Terraform plugin that maps Terraform resource definitions to Azure Resource Manager API calls, letting you manage Azure resources declaratively.
What's the most secure way to authenticate Terraform to Azure in CI?
OIDC / workload identity federation or a managed identity — both avoid storing a long-lived secret. A service principal with a client secret works but must be guarded and rotated.