Azure Storage backend in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct Terraform backend configuration for Azure Storage

Which option correctly configures Terraform to use an Azure Storage Account as the backend with container 'tfstate' and key 'prod.terraform.tfstate'?

A

terraform {
  backend "azure" {
    resource_group = "rg-terraform"
    storage_account = "stterraform"
    container = "tfstate"
    key = "prod.terraform.tfstate"
  }
}

B

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform"
    storage_account_name = "stterraform"
    container_name       = "tfstate"
    key                  = "prod.terraform.tfstate"
  }
}

C

terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform"
    storage_account_name = "stterraform"
    container_name       = "terraform"
    key                  = "prod.tfstate"
  }
}

D

}
}  
"etatsft.mrofarret.dorp" =                  yek    
"etatsft" =       eman_reniatnoc    
"mrofarretts" = eman_tnuocca_egarots    
"mrofarret-gr" =  eman_puorg_ecruoser    
{ "mreruza" dnekcab  
{ mrofarret

💡 Hint

Check the exact backend type name and parameter names required by Terraform for Azure Storage backend.

Terraform requires the backend type to be 'azurerm' with parameters named exactly: resource_group_name, storage_account_name, container_name, and key. Option B matches these requirements exactly.

❓ service_behavior

intermediate

What happens if the Azure Storage backend container does not exist?

When Terraform initializes with an Azure Storage backend and the specified container does not exist, what is the expected behavior?

A Terraform initialization fails with an error indicating the container does not exist.

B Terraform automatically creates the container in the storage account during initialization.

C Terraform ignores the missing container and proceeds without remote state storage.

D Terraform creates a new storage account with the container automatically.

💡 Hint

Consider whether Terraform manages Azure Storage containers automatically.

Terraform does not create the container automatically. If the container does not exist, initialization fails with an error. The container must be created beforehand.

❓ security

advanced

Securely configuring access to Azure Storage backend

Which option is the most secure way to provide credentials for Terraform to access the Azure Storage backend?

A Use a shared access signature (SAS) token embedded in the backend configuration file.

B Hardcode the storage account access key directly in the backend configuration in the Terraform file.

C Use the Azure CLI logged-in user credentials without any environment variables or config.

D Set the environment variables ARM_CLIENT_ID, ARM_CLIENT_SECRET, and ARM_TENANT_ID with a service principal's credentials.

💡 Hint

Think about best practices for managing secrets and automation.

Using environment variables with a service principal is secure and supports automation. Hardcoding secrets or SAS tokens in files is insecure. Azure CLI credentials may not work in automation contexts.

❓ Architecture

advanced

Designing a multi-environment Terraform state backend in Azure Storage

You want to manage multiple environments (dev, staging, prod) using a single Azure Storage account for Terraform state. Which backend configuration approach correctly isolates state files per environment?

A Use the same container and key for all environments, e.g., container_name = "tfstate", key = "terraform.tfstate".

B Use different storage accounts per environment with the same container and key names.

C Use the same container but different keys per environment, e.g., container_name = "tfstate", key = "dev.tfstate", "staging.tfstate", "prod.tfstate".

D Use different containers per environment, e.g., container_name = "dev", "staging", "prod" with the same key "terraform.tfstate".

💡 Hint

Consider how Terraform identifies state files uniquely in the backend.

Using the same container with different keys per environment isolates state files properly. Using the same key or container for all environments causes conflicts. Different storage accounts is possible but more complex.

🧠 Conceptual

expert

Understanding Terraform state locking with Azure Storage backend

How does Terraform ensure that only one user or process modifies the remote state at a time when using Azure Storage backend?

A Terraform uses Azure Blob Storage's blob lease feature to lock the state file during operations.

B Terraform creates a lock file in the container that users must manually delete after changes.

C Terraform relies on Azure Active Directory permissions to prevent concurrent access.

D Terraform does not support state locking with Azure Storage backend; users must coordinate manually.

💡 Hint

Think about how Azure Blob Storage supports concurrency control.

Terraform uses the blob lease feature of Azure Blob Storage to lock the state file during operations, preventing concurrent modifications.