Writing HCL Code

In this lesson we’ll write real Terraform configuration using HCL (HashiCorp Configuration Language). Up to now we covered what Terraform is and how it works conceptually. Now we’ll move into the practical part: writing the code that describes your infrastructure. If you’re new to Terraform, don’t worry — we’ll build examples step by step and explain every line. Once you grasp the basic pattern below, you’ll be able to read and author most Terraform configurations. Core pattern for Terraform configurations

Tell Terraform which cloud or platform to talk to (provider block).
Define the resources you want to create (resource blocks).
Provide details about each resource (arguments inside resource blocks).

Basic provider + resource example

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "my-workshop-rg"
  location = "East US"
}

This single file contains everything Terraform needs to create a resource group in Azure:

The provider block tells Terraform how to communicate with Azure.
The resource block describes the resource group and its required arguments (name and location).

For the AzureRM provider the features {} block is required. It enables provider-default capabilities even when left empty.

Terraform’s three-command workflow After writing HCL, Terraform typically follows this workflow:

Command	Purpose	Typical usage
`terraform init`	Download provider plugins and initialize the working directory	Run once when starting a new project or changing providers
`terraform plan`	Show the execution plan without applying changes	Confirm what will change before applying
`terraform apply`	Create or update resources to reach desired state	Apply the planned changes

Other helpful commands: terraform validate to check syntax and terraform fmt to format files. The code describes desired infrastructure; Terraform commands perform the actual changes. Provider block explained The provider tells Terraform how to communicate with an external system (here, Azure Resource Manager).

provider "azurerm" {
  features {}
  # subscription_id = var.subscription_id   # optional: can be provided here or via environment variables
}

provider "azurerm" selects the AzureRM provider plugin.
features {} is required by the AzureRM provider even when left empty.
You can set subscription_id directly, or supply it via environment variables (for example, ARM_SUBSCRIPTION_ID) or variables for cleaner separation of secrets and configuration.

Resource block and arguments A resource block declares a resource Terraform should manage. The general form: resource “<PROVIDER_RESOURCE_TYPE>” “<LOCAL_NAME>” { arguments… }

<PROVIDER_RESOURCE_TYPE> — provider-specific resource type (e.g., azurerm_storage_account).
<LOCAL_NAME> — logical name used inside Terraform for referencing this resource (not seen by Azure).
Inside the block: key-value arguments describe how to create or configure the resource.

Example: storage account with hard-coded values

resource "azurerm_storage_account" "storage" {
  name                     = "workshopstorage185784"
  resource_group_name      = "my-workshop-rg"
  location                 = "East US"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

We use hard-coded values at first to make each argument obvious. Later you’ll replace these with variables and references for reusability. Required vs optional arguments Always consult the Terraform Registry documentation for each resource to determine required and optional arguments. Examples:

Resource group: name and location are required.
Storage account: name, resource_group_name, location, account_tier, and account_replication_type are required. Many other settings (network rules, tags, etc.) are optional.

Minimal resource group example

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "West Europe"
}

Example: storage account referencing a resource group

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_storage_account" "example" {
  name                     = "examplestorageacct"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = azurerm_resource_group.example.location
  account_tier             = "Standard"
  account_replication_type = "GRS"

  tags = {
    environment = "staging"
  }
}

Using Visual Studio Code for Terraform Before you start:

Ensure Terraform is installed and available: terraform -version.
Ensure you are logged into Azure CLI and pointing at a subscription: az account show.
Consider installing the HashiCorp Terraform extension for VS Code for syntax highlighting and IntelliSense: https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform

Example az account show output (truncated)

{
  "environmentName": "AzureCloud",
  "homeTenantId": "1e0fa212-37dc-45f5-bb0f-b60687cac64b",
  "id": "1b228746-75fd-46ed-8a6b-6a9066d6d3a3",
  "isDefault": true,
  "name": "PenTest Lab 2",
  "state": "Enabled",
  "tenantId": "1e0fa212-37dc-45f5-bb0f-b60687cac64b",
  "user": { /* ... */ }
}

Project layout tips:

Create a folder for your code, e.g., first-code.
Start with a main.tf file. For larger projects split code into multiple .tf files and modules.

Practical walkthrough: create a resource group Create a main.tf file with the following:

provider "azurerm" {
  features {}
  subscription_id = "1b228746-75fd-46ed-8a6b-6a9066d6d3a3"
}

resource "azurerm_resource_group" "rg" {
  name     = "kodekloud-tf-rg"
  location = "eastus"
}

Save the file before running Terraform commands — many editors show unsaved changes with an indicator (a dot). Initialize the working directory

terraform init

Sample terraform init output (truncated)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

Notes:

terraform init downloads provider binaries into the local .terraform directory.
The provider binary downloaded depends on your OS/architecture (e.g., darwin_arm64, windows_amd64).

Plan the deployment

terraform plan

terraform plan converts your HCL into an execution plan and shows what will be added, changed, or destroyed — without making changes. Apply the changes

terraform apply

Example interactive terraform apply output (truncated)

Terraform will perform the following actions:

  # azurerm_resource_group.rg will be created
  + resource "azurerm_resource_group" "rg" {
      + id       = (known after apply)
      + location = "eastus"
      + name     = "kodekloud-tf-rg"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Enter a value: yes

azurerm_resource_group.rg: Creating...
azurerm_resource_group.rg: Creation complete after 28s
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

State file and best practices Terraform stores the mapping of your configuration to real cloud resources in a state file (default: terraform.tfstate in the working directory). This file is how Terraform tracks resources it manages.

The state file may contain sensitive information (IDs, attributes, secrets). Do not commit terraform.tfstate to version control. For teams, use a remote backend (for example, Azure Storage, S3, or Terraform Cloud) to store state securely and enable state locking.

Important behavior: drift between Terraform and cloud changes If you modify resources directly in the cloud (for example, adding tags in the Azure Portal), Terraform will detect those differences the next time you run terraform plan or terraform apply. If the portal change is not reflected in your HCL, Terraform will attempt to reconcile the real state to match your code — which may overwrite or remove the manual change. Example: adding a tag via Azure Portal You can add a tag to the resource group in the portal. The Portal shows the edit UI:

A screenshot of the Microsoft Azure portal showing the Resource Manager > Resource groups page with a list of resource groups. The right side has an "Edit tags" panel open for the resource group named kodekloud-tf-rg.

If you then run terraform plan, Terraform will show changes required to make the resource match the configuration in your HCL (for example, it may propose to remove or change that tag). This behavior demonstrates Terraform’s desired-state model: Terraform will always aim to make the real infrastructure match the declared code. Wrap-up You now know the basic HCL pattern (provider → resource → arguments) and the essential Terraform workflow (init, plan, apply). Next topics to continue learning:

Variables and outputs (parameterize your configurations)
State backends and locking (secure, shareable state)
Modules (reusable infrastructure components)
Best practices for project structure and secrets management

References

Terraform Registry — Azure Provider: https://registry.terraform.io/providers/hashicorp/azurerm/latest
HashiCorp Terraform extension for VS Code: https://marketplace.visualstudio.com/items?itemName=HashiCorp.terraform
Azure CLI documentation: https://docs.microsoft.com/cli/azure/overview

Introduction

Infrastructure as Code Fundamentals

Terraform Cloud

Setting up environment

Azure Context for Terraform

HashiCorp Configuration Language

Terraform Providers

Variables

Outputs and Dependencies

Iteration and Logic

Advanced Constructs

Terraform State Fundamentals

Remote State

Terraform Workspaces

Terraform CLI

Lifecycle Meta-Arguments

Data Sources

Provisioners

Debugging Terraform

Terraform Modules

Azure DevOps Integration

Azure Pipelines for Terraform

Watch Video