Azure provider setup in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct Azure provider block for Terraform

Which Terraform configuration block correctly sets up the Azure provider with a specified subscription ID and tenant ID?

A

provider "azurerm" {
  features {}
  subscription = "12345678-1234-1234-1234-123456789abc"
  tenant       = "87654321-4321-4321-4321-cba987654321"
}

B

provider "azure" {
  subscription = "12345678-1234-1234-1234-123456789abc"
  tenant       = "87654321-4321-4321-4321-cba987654321"
}

C

provider "azurerm" {
  subscription = "12345678-1234-1234-1234-123456789abc"
  tenant       = "87654321-4321-4321-4321-cba987654321"
}

D

provider "azurerm" {
  features {}
  subscription_id = "12345678-1234-1234-1234-123456789abc"
  tenant_id       = "87654321-4321-4321-4321-cba987654321"
}

💡 Hint

The official Azure provider for Terraform is named 'azurerm' and requires a 'features' block.

The correct provider block for Azure in Terraform is 'azurerm'. It requires a 'features' block even if empty. The correct attribute names are 'subscription_id' and 'tenant_id'. Option D uses the correct provider name, attributes, and includes the required 'features' block.

❓ service_behavior

intermediate

What happens if 'features' block is missing in Azure provider?

In Terraform, what is the result of configuring the Azure provider without including the 'features' block?

A Terraform throws a configuration error and refuses to initialize the provider.

B Terraform initializes the provider successfully but disables all resource features.

C Terraform initializes the provider successfully with default features enabled.

D Terraform ignores the provider configuration and uses environment variables instead.

💡 Hint

The 'features' block is mandatory even if empty for the Azure provider.

The Azure provider for Terraform requires a 'features' block. Omitting it causes Terraform to throw a configuration error during initialization.

❓ security

advanced

Securely authenticating Terraform Azure provider with Service Principal

Which Terraform provider configuration securely authenticates to Azure using a Service Principal with client ID, client secret, tenant ID, and subscription ID?

A

provider "azurerm" {
  features {}
  client_id       = var.client_id
  client_password = var.client_secret
  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
}

B

provider "azurerm" {
  features {}
  client_id       = var.client_id
  client_secret   = var.client_secret
  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
}

C

provider "azurerm" {
  features {}
  client = var.client_id
  secret = var.client_secret
  tenant = var.tenant_id
  subscription = var.subscription_id
}

D

provider "azurerm" {
  features {}
  client_id       = var.client_id
  client_secret   = var.client_secret
  tenant          = var.tenant_id
  subscription    = var.subscription_id
}

💡 Hint

Use exact attribute names: client_id, client_secret, tenant_id, subscription_id.

The Azure provider expects the attributes named exactly as client_id, client_secret, tenant_id, and subscription_id. Option B uses the correct attribute names and includes the required features block.

❓ Architecture

advanced

Choosing the best Terraform backend for Azure state storage

Which Terraform backend configuration correctly sets up remote state storage in Azure Blob Storage with container 'tfstate' and storage account 'mystorageacct'?

A

terraform {
  backend "azureblob" {
    resource_group  = "myResourceGroup"
    storage_account = "mystorageacct"
    container      = "tfstate"
    key            = "terraform.tfstate"
  }
}

B

terraform {
  backend "azurerm" {
    resource_group_name  = "myResourceGroup"
    storage_account_name = "mystorageacct"
    container_name       = "tfstate"
  }
}

C

terraform {
  backend "azurerm" {
    resource_group_name  = "myResourceGroup"
    storage_account_name = "mystorageacct"
    container_name       = "tfstate"
    key                  = "terraform.tfstate"
  }
}

D

terraform {
  backend "azurerm" {
    resource_group_name  = "myResourceGroup"
    storage_account_name = "mystorageacct"
    container_name       = "tfstate"
    key                  = "state.tf"
  }
}

💡 Hint

The backend type is 'azurerm' and the key must match the state file name.

Option C correctly uses the 'azurerm' backend with all required attributes including resource group, storage account, container, and key matching the state file name. Option C uses a non-existent backend type. Option C omits the key attribute which is required. Option C uses a different key name than specified.

🧠 Conceptual

expert

Understanding Azure Provider Authentication Methods in Terraform

Which authentication method will Terraform use for the Azure provider if no explicit credentials are set in the provider block and environment variables are not defined?

A Terraform will authenticate using the Azure CLI logged-in user context.

B Terraform will fail to authenticate and throw an error immediately.

C Terraform will use Managed Identity if running on an Azure VM with one assigned.

D Terraform will fallback to anonymous access with limited permissions.

💡 Hint

Terraform can use Azure CLI credentials if no other credentials are provided.

When no credentials are set in the provider block or environment variables, Terraform attempts to authenticate using the Azure CLI logged-in user context. If the user is not logged in, it will fail later during resource operations. Managed Identity is only used if explicitly configured or running in certain environments.