Introduction
In modern cloud-based application development, manually creating and configuring infrastructure through the Azure Portal, AWS Console, or other cloud management portals can become difficult as applications grow.
A typical enterprise .NET application may require multiple infrastructure components such as:
Azure Virtual Network
Azure Kubernetes Service (AKS)
Azure Container Registry (ACR)
Azure SQL Database
Azure Service Bus
Azure Key Vault
Azure API Management
Application Gateway
Application Insights
Azure Monitor
Storage Accounts
Managed Identities
Creating all these resources manually can be time-consuming and error-prone.
This is where Terraform becomes extremely useful.
Terraform allows us to define infrastructure using code and manage that infrastructure consistently across different environments such as:
Development
QA
UAT
Production
Terraform is an Infrastructure as Code (IaC) tool developed by HashiCorp.
Instead of manually creating infrastructure, we describe what infrastructure we need in Terraform configuration files, and Terraform creates and manages those resources for us.
1. What Is Terraform?
Terraform is an Infrastructure as Code tool used to provision and manage infrastructure using configuration files.
For example, instead of opening the Azure Portal and manually creating a Resource Group, we can write:
resource "azurerm_resource_group" "oneview" {
name = "rg-oneview-dev"
location = "East US"
}Terraform interprets this configuration and creates the corresponding Azure Resource Group.
The basic idea is:
Terraform Configuration
|
v
Terraform
|
v
Azure Provider
|
v
Azure InfrastructureTerraform can manage infrastructure from many platforms and services.
Examples include:
Microsoft Azure
Amazon Web Services
Google Cloud
Kubernetes
GitHub
Databases
Monitoring platforms
SaaS applications
2. What Is Infrastructure as Code?
Infrastructure as Code means managing infrastructure through machine-readable configuration files instead of manually configuring infrastructure.
Traditional Approach
Suppose we need to create an AKS cluster.
An engineer may manually:
Open Azure Portal
Create Resource Group
Create Virtual Network
Create Subnet
Create AKS
Configure networking
Configure identity
Configure permissions
Configure monitoring
Connect AKS with ACR
This process can be repeated for every environment.
Developer
|
v
Azure Portal
|
+--> Resource Group
+--> VNet
+--> Subnet
+--> AKS
+--> ACR
+--> SQL
+--> Service BusThe problem is that manual configuration can introduce inconsistencies.
For example:
DEV -> 2 AKS nodes
QA -> 3 AKS nodes
UAT -> 4 AKS nodes
PROD -> 6 AKS nodesSome differences may be intentional, while others may happen because of manual configuration.
Infrastructure as Code Approach
With Terraform:
Terraform Code
|
v
Terraform Plan
|
v
Terraform Apply
|
v
Azure InfrastructureThe infrastructure configuration is stored in Git just like application source code.
3. Why Do We Need Terraform?
Terraform solves several infrastructure management problems.
3.1 Automation
Infrastructure can be created automatically.
3.2 Repeatability
The same infrastructure configuration can be reused for multiple environments.
3.3 Version Control
Terraform files can be stored in Git.
For example:
Git
|
+-- Terraform Code
|
+-- Version History
|
+-- Pull Requests
|
+-- Code Reviews3.4 Consistency
Dev, QA, UAT, and Production can use standardized infrastructure modules.
3.5 Disaster Recovery
Infrastructure can be recreated from code when appropriate.
3.6 Collaboration
Multiple developers, architects, and DevOps engineers can work with the same infrastructure definition.
4. Terraform Architecture
The Terraform architecture can be represented as follows:
Terraform Configuration
|
v
Terraform CLI
|
+--------------+--------------+
| |
v v
Terraform State Terraform Provider
|
v
Azure APIs
|
v
Azure InfrastructureThe major components are:
Terraform CLI
Terraform Configuration
Providers
Resources
Variables
Data Sources
State
Backend
Modules
Outputs
Let's understand each one.
5. Terraform Configuration Files
Terraform configuration files generally use the .tf extension.
For example:
main.tf
variables.tf
outputs.tf
provider.tf
network.tf
aks.tf
sql.tf
servicebus.tfTerraform reads all .tf files in the working directory.
Therefore, we don't have to put everything into one file.
A large enterprise project can be organized into multiple files.
6. HCL — HashiCorp Configuration Language
Terraform configurations are generally written using HCL.
For example:
resource "azurerm_resource_group" "oneview" {
name = "rg-oneview-dev"
location = "East US"
}The syntax is:
resource "RESOURCE_TYPE" "RESOURCE_NAME" {
configuration
}In this example:
resource
|
+-- azurerm_resource_group
|
+-- oneview7. Terraform Providers
A provider allows Terraform to communicate with an external platform or service.
For Azure, we commonly use:
azurermExample:
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
}
provider "azurerm" {
features {}
}The provider acts as the bridge between Terraform and Azure.
Terraform
|
v
Azure Provider
|
v
Azure API
|
v
Azure Resources8. Installing Terraform
After installing Terraform, verify the installation:
terraform versionYou should see the installed Terraform version.
For Azure development, Azure CLI is also useful.
Check Azure CLI:
az versionLogin to Azure:
az loginYou can then select the required Azure subscription.
az account set --subscription "<subscription-id>"9. Real-Time Project Example
Let's consider a real-world .NET application called:
OneView Workforce Planning Platform
Suppose OneView contains the following microservices:
Forecast Service
Workforce Service
Capacity Service
Hiring Service
A possible architecture is:
Users
|
v
Application Gateway
|
v
Azure API Management
|
+----------------+----------------+
| | |
v v v
Forecast API Workforce API Capacity API
| | |
+----------------+----------------+
|
v
Azure Service Bus
|
v
Hiring Service
|
v
Azure SQLSupporting Azure services might include:
AKS
ACR
Azure SQL
Service Bus
Key Vault
API Management
Application Gateway
Application Insights
Azure Monitor
Virtual Network
Managed IdentityTerraform can provision much of this infrastructure.
10. Creating the Terraform Project
Let's create the following project structure:
oneview-infrastructure/
│
├── provider.tf
├── variables.tf
├── resource-group.tf
├── network.tf
├── acr.tf
├── aks.tf
├── servicebus.tf
├── outputs.tf
└── terraform.tfvarsFor a larger enterprise project, we can later convert these resources into reusable modules.
11. Configure Azure Provider
Create:
provider.tfAdd:
terraform {
required_version = ">= 1.6.0"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
}
provider "azurerm" {
features {}
}This tells Terraform that the project uses the Azure Resource Manager provider.
12. Create Azure Resource Group
Create:
resource-group.tfresource "azurerm_resource_group" "oneview" {
name = var.resource_group_name
location = var.location
tags = {
Environment = var.environment
Application = "OneView"
ManagedBy = "Terraform"
}
}Instead of hardcoding values, we are using variables.
13. Terraform Variables
Create:
variables.tfvariable "resource_group_name" {
description = "Azure Resource Group name"
type = string
}
variable "location" {
description = "Azure region"
type = string
default = "East US"
}
variable "environment" {
description = "Deployment environment"
type = string
default = "dev"
}
variable "aks_node_count" {
description = "Number of AKS nodes"
type = number
default = 2
}Now create:
terraform.tfvarsresource_group_name = "rg-oneview-dev"
location = "East US"
environment = "dev"
aks_node_count = 214. Terraform Init
Navigate to the project directory:
cd oneview-infrastructureRun:
terraform initTerraform downloads the required provider and initializes the working directory.
Typical flow:
Terraform Project
|
v
terraform init
|
v
Download Providers
|
v
Initialized15. Terraform Validate
Before creating infrastructure, validate the configuration:
terraform validateThis checks the Terraform configuration for syntax and configuration errors.
16. Terraform Format
Terraform provides a formatting command:
terraform fmtThis automatically formats Terraform files according to Terraform's standard formatting rules.
17. Terraform Plan
Now execute:
terraform planTerraform calculates what changes are required.
For example:
Plan: 1 to add, 0 to change, 0 to destroy.The important point is:
terraform plan previews changes.
It is normally used before applying infrastructure changes.
18. Terraform Apply
To create the infrastructure:
terraform applyTerraform displays the planned changes and asks for confirmation.
Enter:
yesTerraform then creates the resources.
You can also use:
terraform apply -auto-approveHowever, automatic approval should be used carefully, especially for production environments.
19. Creating Azure Virtual Network
Now let's create networking.
Create:
network.tfresource "azurerm_virtual_network" "oneview" {
name = "vnet-oneview"
location = azurerm_resource_group.oneview.location
resource_group_name = azurerm_resource_group.oneview.name
address_space = ["10.10.0.0/16"]
tags = {
Environment = var.environment
Application = "OneView"
ManagedBy = "Terraform"
}
}Create an AKS subnet:
resource "azurerm_subnet" "aks" {
name = "snet-aks"
resource_group_name = azurerm_resource_group.oneview.name
virtual_network_name = azurerm_virtual_network.oneview.name
address_prefixes = ["10.10.1.0/24"]
}20. Creating Azure Container Registry
.NET microservices can be packaged as Docker containers.
Those container images can be stored in Azure Container Registry.
Create:
acr.tfresource "azurerm_container_registry" "oneview" {
name = "acroneviewdev123"
resource_group_name = azurerm_resource_group.oneview.name
location = azurerm_resource_group.oneview.location
sku = "Standard"
admin_enabled = false
tags = {
Environment = var.environment
Application = "OneView"
ManagedBy = "Terraform"
}
}The application deployment flow becomes:
.NET Source Code
|
v
Docker Build
|
v
Container Image
|
v
Azure Container Registry
|
v
AKS21. Creating Azure Kubernetes Service
Now let's create AKS.
Create:
aks.tfExample:
resource "azurerm_kubernetes_cluster" "oneview" {
name = "aks-oneview-dev"
location = azurerm_resource_group.oneview.location
resource_group_name = azurerm_resource_group.oneview.name
dns_prefix = "oneview-dev"
default_node_pool {
name = "system"
node_count = var.aks_node_count
vm_size = "Standard_D2s_v5"
}
identity {
type = "SystemAssigned"
}
tags = {
Environment = var.environment
Application = "OneView"
ManagedBy = "Terraform"
}
}Terraform now understands that AKS belongs to the resource group.
22. Terraform Dependency Management
Terraform automatically identifies many dependencies by analyzing resource references.
For example:
resource_group_name = azurerm_resource_group.oneview.nameTerraform understands:
Resource Group
|
v
AKSTherefore, Terraform creates the Resource Group before AKS.
This is called an implicit dependency.
23. Explicit Dependencies
Sometimes Terraform cannot determine a dependency automatically.
In those cases, we can use:
depends_on = [
azurerm_resource_group.oneview
]Example:
resource "some_resource" "example" {
# configuration
depends_on = [
azurerm_resource_group.oneview
]
}It is generally preferable to rely on implicit dependencies whenever possible.
24. Connect AKS with ACR
AKS needs permission to pull container images from ACR.
We can assign the AcrPull role to the AKS kubelet identity.
Example:
resource "azurerm_role_assignment" "aks_acr" {
principal_id = azurerm_kubernetes_cluster.oneview
.kubelet_identity[0]
.object_id
role_definition_name = "AcrPull"
scope = azurerm_container_registry.oneview.id
skip_service_principal_aad_check = true
}The relationship is:
Azure Container Registry
|
| AcrPull
v
AKS
|
v
Kubernetes
|
v
.NET Pods25. Azure Service Bus with Terraform
In a microservices architecture, Azure Service Bus can be used for asynchronous communication.
Create:
servicebus.tfExample:
resource "azurerm_servicebus_namespace" "oneview" {
name = "sb-oneview-dev"
location = azurerm_resource_group.oneview.location
resource_group_name = azurerm_resource_group.oneview.name
sku = "Standard"
tags = {
Environment = var.environment
Application = "OneView"
ManagedBy = "Terraform"
}
}Create a topic:
resource "azurerm_servicebus_topic" "forecast_events" {
name = "forecast-events"
namespace_id = azurerm_servicebus_namespace.oneview.id
}Create a subscription:
resource "azurerm_servicebus_subscription" "workforce" {
name = "workforce-subscription"
topic_id = azurerm_servicebus_topic.forecast_events.id
max_delivery_count = 10
}The communication flow becomes:
Forecast Service
|
| ForecastCreated
v
forecast-events
|
v
workforce-subscription
|
v
Workforce Service26. Terraform Outputs
Create:
outputs.tfoutput "resource_group_name" {
value = azurerm_resource_group.oneview.name
}
output "aks_cluster_name" {
value = azurerm_kubernetes_cluster.oneview.name
}
output "acr_login_server" {
value = azurerm_container_registry.oneview.login_server
}After applying the configuration:
terraform outputTerraform can display the output values.
27. Terraform State
One of the most important concepts in Terraform is state.
Terraform maintains information about infrastructure it manages.
The local state file is commonly:
terraform.tfstateConceptually:
Terraform Configuration
|
v
Desired State
|
|
Terraform State
|
v
Actual AzureTerraform uses state to understand relationships between configuration and infrastructure.
28. Why Remote State Is Important
In a team environment, storing state only on an individual developer's machine is usually not appropriate.
Imagine:
Developer A
|
Developer B
|
Developer C
|
Azure DevOps
|
v
Shared Terraform StateFor Azure, an Azure Storage Account can be used as a remote backend.
Example:
terraform {
backend "azurerm" {
resource_group_name = "rg-terraform-state"
storage_account_name = "tfstateoneview"
container_name = "tfstate"
key = "oneview-dev.tfstate"
}
}The backend infrastructure should generally be bootstrapped separately before configuring the project to use it.
29. Terraform State Locking
Consider this situation:
Developer A --------+
|
Developer B --------+----> Terraform State
|
CI/CD Pipeline -----+If multiple operations modify the same state concurrently, problems can occur.
Remote backends can provide state locking or concurrency controls, depending on the backend.
Therefore, enterprise Terraform implementations should carefully design:
Remote state
State isolation
Locking
Access control
Backup
Recovery
30. Terraform Modules
As Terraform projects become larger, we should avoid putting hundreds or thousands of lines into a single file.
Terraform supports reusable modules.
Example:
terraform/
│
├── modules/
│ ├── network/
│ ├── aks/
│ ├── acr/
│ ├── sql/
│ ├── servicebus/
│ ├── keyvault/
│ └── apim/
│
└── environments/
├── dev/
├── qa/
├── uat/
└── prod/A module can encapsulate a reusable infrastructure component.
31. Example Terraform Module
Suppose we have an AKS module:
modules/
└── aks/
├── main.tf
├── variables.tf
└── outputs.tfThe root configuration can call it:
module "aks" {
source = "./modules/aks"
resource_group_name = azurerm_resource_group.oneview.name
location = var.location
node_count = var.aks_node_count
}The same module can then be reused by different environments.
32. Multiple Environments
A real enterprise application normally has:
DEV
QA
UAT
PRODWe can structure Terraform as:
environments/
│
├── dev/
│ ├── main.tf
│ └── terraform.tfvars
│
├── qa/
│ ├── main.tf
│ └── terraform.tfvars
│
├── uat/
│ ├── main.tf
│ └── terraform.tfvars
│
└── prod/
├── main.tf
└── terraform.tfvarsFor example:
Development
environment = "dev"
aks_node_count = 2Production
environment = "prod"
aks_node_count = 5The infrastructure module can remain reusable while environment-specific values are separated.
33. Terraform Data Sources
A Terraform resource creates or manages infrastructure.
A data source reads information about existing infrastructure.
For example:
data "azurerm_resource_group" "shared" {
name = "rg-shared-services"
}We can then access:
data.azurerm_resource_group.shared.locationThis is particularly useful when an enterprise already has shared infrastructure.
For example:
Existing Shared Infrastructure
|
+------+------+
| |
v v
Shared VNet Key Vault
|
v
Application TerraformTerraform doesn't necessarily need to create every resource itself.
34. Terraform Drift
Drift occurs when infrastructure changes outside Terraform.
Suppose Terraform defines:
AKS Node Count = 3But someone manually changes Azure:
AKS Node Count = 5Now:
Desired State = 3
Actual State = 5This is infrastructure drift.
Running:
terraform plancan reveal differences Terraform detects between the configuration/state and the infrastructure.
35. Terraform Import
Suppose an Azure resource already exists:
Azure Portal
|
v
Existing ResourceBut Terraform doesn't currently manage it.
Terraform supports importing existing resources into Terraform state.
Conceptually:
Existing Azure Resource
|
v
Terraform Import
|
v
Terraform StateAfter import, you should ensure the Terraform configuration accurately represents the resource.
Modern Terraform also supports declarative import blocks for import workflows.
36. Terraform Lifecycle
Terraform provides lifecycle controls.
For example:
lifecycle {
prevent_destroy = true
}This can be useful for resources where accidental destruction would be especially undesirable.
Another lifecycle option is:
lifecycle {
ignore_changes = [
tags
]
}Lifecycle rules should be used carefully because they can change Terraform's normal reconciliation behavior.
37. Terraform with Docker
Terraform and Docker solve different problems.
Docker
Docker packages applications into containers.
.NET Application
|
v
Docker Build
|
v
Container ImageTerraform
Terraform provisions infrastructure.
Terraform
|
+--> AKS
+--> ACR
+--> VNet
+--> SQL
+--> Service BusTogether:
.NET Application
|
v
Docker Image
|
v
ACR
|
v
AKS
^
|
Terraform38. Terraform with Kubernetes
Terraform and Kubernetes YAML also have different responsibilities.
Terraform can provision:
Azure
|
+--> VNet
+--> AKS
+--> ACR
+--> SQL
+--> Service BusKubernetes can manage:
AKS
|
+--> Deployment
+--> Service
+--> Ingress
+--> ConfigMap
+--> Secret
+--> HPATherefore:
Terraform
|
v
Infrastructure
|
v
AKS
|
v
Kubernetes
|
v
.NET MicroservicesTerraform can also manage Kubernetes resources, but organizations often separate infrastructure provisioning from application deployment for operational clarity.
39. Terraform with Azure DevOps
Terraform becomes especially powerful when integrated with CI/CD.
A typical pipeline looks like:
Developer
|
v
Git Commit
|
v
Azure DevOps
|
+--> terraform fmt
|
+--> terraform validate
|
+--> terraform plan
|
v
Approval
|
v
terraform apply
|
v
Azure Infrastructure40. Example Azure DevOps Terraform Pipeline
A simplified example:
trigger:
- main
pool:
vmImage: ubuntu-latest
steps:
- task: TerraformInstaller@1
inputs:
terraformVersion: 'latest'
- script: |
terraform init
displayName: 'Terraform Init'
- script: |
terraform fmt -check
displayName: 'Terraform Format Check'
- script: |
terraform validate
displayName: 'Terraform Validate'
- script: |
terraform plan
displayName: 'Terraform Plan'
- script: |
terraform apply -auto-approve
displayName: 'Terraform Apply'A production pipeline should additionally consider:
Azure service connections
Secure authentication
Remote state
Plan artifacts
Approval gates
Environment protection
Separate plan/apply stages
Secret management
Policy checks
41. Terraform and Security
Security is extremely important when managing infrastructure.
Never hardcode sensitive credentials:
password = "MyPassword123"Instead, use mechanisms such as:
Azure Key Vault
Managed Identity
Workload Identity
Azure DevOps secret variables
Secure pipeline variables
Environment variables
For example:
Terraform
|
v
Azure Identity
|
v
Key Vault
|
v
Secrets42. Sensitive Variables
Terraform supports sensitive variables.
Example:
variable "database_password" {
type = string
sensitive = true
}This helps prevent the value from being displayed in normal Terraform output.
However, marking a value as sensitive does not automatically remove it from Terraform state. Therefore, state itself must be securely stored and access-controlled.
43. Terraform Workspaces
Terraform supports workspaces.
For example:
terraform workspace new devterraform workspace new qaterraform workspace new prodSelect a workspace:
terraform workspace select devWorkspaces can be useful in certain scenarios, but for larger enterprise environments, separate environment directories and isolated remote states can sometimes provide clearer isolation.
44. Important Terraform Commands
| Command | Description |
|---|---|
terraform init | Initializes Terraform |
terraform fmt | Formats Terraform files |
terraform validate | Validates configuration |
terraform plan | Shows proposed changes |
terraform apply | Creates/updates infrastructure |
terraform destroy | Destroys managed infrastructure |
terraform output | Displays outputs |
terraform show | Displays state/plan information |
terraform state list | Lists resources in state |
terraform state show | Shows a resource from state |
terraform providers | Displays configured providers |
terraform workspace list | Lists workspaces |
45. Terraform Destroy
Terraform can also remove infrastructure that it manages.
terraform destroyTerraform shows the resources it intends to destroy.
For example:
Plan: 0 to add, 0 to change, 10 to destroy.After confirmation, Terraform removes the managed resources.
This command should be used with extreme care in production.
46. Terraform vs ARM Templates vs Bicep
For Azure architects, this is an important interview topic.
| Feature | Terraform | ARM Templates | Bicep |
|---|---|---|---|
| Provider | HashiCorp | Microsoft | Microsoft |
| Azure | Yes | Yes | Yes |
| AWS | Yes | No | No |
| GCP | Yes | No | No |
| Multi-cloud | Strong | No | No |
| Syntax | HCL | JSON | Bicep |
| Modules | Yes | Yes | Yes |
| Azure Native | No | Yes | Yes |
| CI/CD | Yes | Yes | Yes |
Bicep is an Azure-native Infrastructure as Code language.
Terraform is particularly attractive when an organization wants a common IaC approach across multiple providers or already has a mature Terraform ecosystem.
47. Terraform vs Ansible
Terraform and Ansible are also frequently compared.
Terraform
Primarily focuses on infrastructure provisioning.
Terraform
|
+--> Network
+--> VM
+--> AKS
+--> Database
+--> StorageAnsible
Primarily focuses on configuration and automation.
Ansible
|
+--> Install packages
+--> Configure servers
+--> Deploy configuration
+--> Execute operational tasksSimplified:
Terraform
|
v
Provision Infrastructure
Ansible
|
v
Configure / Automate Systems48. Terraform vs Docker vs Kubernetes
These three technologies solve different problems.
Terraform
|
v
Infrastructure Provisioning
Docker
|
v
Application Containerization
Kubernetes
|
v
Container OrchestrationFor a .NET microservices platform:
Terraform
|
+--> Azure VNet
+--> AKS
+--> ACR
+--> SQL
+--> Service Bus
|
v
Docker
|
v
.NET Container
|
v
ACR
|
v
Kubernetes / AKS
|
v
Running Microservices49. Complete OneView Terraform Architecture
Let's put everything together.
Internet
|
v
Application Gateway
|
v
Azure API Management
|
v
AKS
|
+-----------------+-----------------+
| | |
v v v
Forecast API Workforce API Capacity API
| | |
+-----------------+-----------------+
|
v
Azure Service Bus
|
v
Hiring Service
|
v
Azure SQL
Supporting Azure Services
-------------------------
+-----------------------------+
| Azure Container Registry |
| Azure Key Vault |
| Application Insights |
| Azure Monitor |
| Managed Identity |
| Virtual Network |
+-----------------------------+
^
|
Terraform
|
v
Infrastructure as Code50. End-to-End Terraform Deployment Flow
A complete enterprise deployment can look like:
Developer
|
v
Git Repository
|
v
Azure DevOps
|
+------------+------------+
| |
v v
Terraform Application
Code Code
| |
v v
terraform validate Docker Build
| |
v v
terraform plan ACR
| |
v v
Approval AKS
|
v
terraform apply
|
v
Azure Infrastructure
|
+------+------+------+
| | | |
v v v v
VNet AKS SQL Service Bus51. Enterprise Terraform Repository Structure
A production-style Terraform repository can look like:
terraform-infrastructure/
│
├── modules/
│ │
│ ├── network/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ │
│ ├── aks/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── outputs.tf
│ │
│ ├── acr/
│ ├── sql/
│ ├── servicebus/
│ ├── keyvault/
│ ├── apim/
│ └── monitoring/
│
├── environments/
│ │
│ ├── dev/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ └── terraform.tfvars
│ │
│ ├── qa/
│ │
│ ├── uat/
│ │
│ └── prod/
│
└── pipelines/
├── terraform-plan.yml
└── terraform-apply.ymlThis structure provides:
Reusable Modules
+
Environment Isolation
+
CI/CD Automation
+
Version Control52. Terraform Best Practices
1. Use Remote State
Use an appropriate remote backend instead of relying on local state for team-managed infrastructure.
2. Use Modules
Create reusable modules for common infrastructure components.
3. Never Hardcode Secrets
Use Key Vault, managed identities, and secure CI/CD mechanisms.
4. Use Git
Store Terraform code in source control.
5. Review Terraform Plans
Use:
terraform planbefore applying important infrastructure changes.
6. Use Environment Isolation
Separate development and production state appropriately.
7. Use Naming Standards
For example:
rg-oneview-dev
rg-oneview-qa
rg-oneview-uat
rg-oneview-prod8. Use Resource Tags
tags = {
Application = "OneView"
Environment = "Production"
Owner = "PlatformTeam"
ManagedBy = "Terraform"
}9. Implement CI/CD
Terraform should be integrated with your organization's DevOps process.
10. Protect Production
Production infrastructure should have:
Approval processes
Restricted permissions
Remote state
Secure credentials
Policy validation
Monitoring
Backup/recovery processes
53. Terraform in a .NET Solution Architect's Architecture
From a Solution Architect perspective, Terraform is not responsible for writing the .NET application.
Instead, it manages the infrastructure required to run the application.
For example:
.NET Application
|
v
Docker Image
|
v
ACR
|
v
AKS
|
+-----------------+----------------+
| | |
v v v
Forecast Workforce Capacity
Service Service Service
| | |
+-----------------+----------------+
|
v
Service Bus
|
v
Hiring Service
|
v
Azure SQL
Terraform manages:
-------------------
VNet
AKS
ACR
SQL
Service Bus
Key Vault
APIM
Application Gateway
Monitoring
IdentityThis separation is important.
Application code describes what the application does.
Terraform describes what infrastructure the application needs.
54. Real-World Scenario
Suppose a company wants to create a new production environment for OneView.
Without Terraform:
Engineer
|
+--> Create Resource Group
+--> Create VNet
+--> Create Subnets
+--> Create ACR
+--> Create AKS
+--> Create SQL
+--> Create Service Bus
+--> Create Key Vault
+--> Configure APIM
+--> Configure Monitoring
+--> Configure PermissionsWith Terraform:
Terraform Repository
|
v
terraform plan
|
v
Approval
|
v
terraform apply
|
v
Azure InfrastructureThe infrastructure definition becomes repeatable, reviewable, and version controlled.
55. Terraform Workflow — Summary
The standard Terraform workflow is:
Write Terraform Code
|
v
terraform init
|
v
terraform fmt
|
v
terraform validate
|
v
terraform plan
|
v
Review
|
v
terraform apply
|
v
Azure Resources
|
v
Monitor / Maintain
|
v
Code Changes
|
v
terraform plan56. Important Terraform Concepts for Interviews
If you are preparing for a .NET Solution Architect, Azure Architect, or DevOps interview, the following Terraform topics are particularly important:
Terraform Fundamentals
What is Terraform?
What is Infrastructure as Code?
What is HCL?
What is a provider?
What is a resource?
What is a data source?
What is a variable?
What is an output?
State Management
What is Terraform state?
Why is state required?
What is remote state?
What is state locking?
What is state drift?
How do you secure Terraform state?
Modules
What is a Terraform module?
Why use modules?
How do you create reusable modules?
How do you pass variables into modules?
How do modules expose outputs?
Enterprise
Terraform with Azure DevOps
Terraform with AKS
Terraform with ACR
Terraform with Azure SQL
Terraform with Service Bus
Terraform with Key Vault
Terraform with API Management
Terraform with Application Gateway
Terraform with Managed Identity
Terraform with Azure Monitor
57. Key Takeaways
Terraform provides a consistent way to manage cloud infrastructure through code.
The most important concepts are:
Terraform
|
+--> Infrastructure as Code
|
+--> Providers
|
+--> Resources
|
+--> Variables
|
+--> Data Sources
|
+--> State
|
+--> Remote Backend
|
+--> Modules
|
+--> Outputs
|
+--> Plan
|
+--> Apply
|
+--> DestroyFor a modern .NET microservices application:
Terraform
|
+--> Azure Infrastructure
|
+--> VNet
+--> AKS
+--> ACR
+--> Azure SQL
+--> Service Bus
+--> Key Vault
+--> APIM
+--> Application Gateway
+--> MonitoringThe application itself can then be built using:
.NET
|
v
Docker
|
v
ACR
|
v
AKSTherefore, Terraform plays an important role in creating a repeatable and automated cloud foundation for modern .NET applications.
Conclusion
Terraform is much more than a tool for creating Azure resources.
In an enterprise environment, Terraform can become an important part of the overall Cloud Infrastructure and DevOps strategy.
A typical modern architecture can combine:
.NET
+
Docker
+
Kubernetes / AKS
+
Azure
+
Terraform
+
Azure DevOpswhere:
.NET develops the business applications
Docker packages applications into containers
AKS orchestrates containers
Azure provides cloud infrastructure and managed services
Terraform provisions and manages infrastructure as code
Azure DevOps automates the CI/CD lifecycle
The result is a repeatable, automated, version-controlled infrastructure platform that can support development through production environments.
Terraform + Azure + .NET + Kubernetes + DevOps is therefore a powerful combination for building and operating modern enterprise applications.
