Skip to main content
In this lesson we start authoring Terraform configuration files and examine the core building blocks of HCL (HashiCorp Configuration Language). HCL is a declarative language designed to describe the desired state of your infrastructure rather than a sequence of imperative steps. Terraform configuration files use the .tf extension. Terraform automatically loads and evaluates all .tf files in a single directory as one configuration. File names are for organization only and do not control execution order. This lets you split large projects into logical files (for example, network.tf, storage.tf, main.tf) while Terraform evaluates them together.
Terraform treats all .tf files in a directory as a single configuration. Use multiple files to organize resources logically (for example, network.tf, storage.tf, main.tf) without affecting evaluation order.

​
Resource block: core structure

A Terraform resource block declares an infrastructure object that Terraform will create and manage. The general pattern is: resource + provider-specific resource type + local name + arguments Example: creating an Azure Resource Group
Breakdown:
  • resource — block type that declares a managed infrastructure object.
  • azurerm_resource_group — provider-specific resource type (here: AzureRM provider).
  • "example" — local name (local identifier) used within Terraform to reference this resource.
  • The block body contains arguments that describe desired state:
    • name — the actual resource name in Azure.
    • location — the Azure region for the resource.
Every Terraform resource follows this same pattern. Once you understand it, reading and writing Terraform is predictable across providers.

​
Example: Azure Storage Account

The resource type and arguments will vary by provider and resource. For example, creating an Azure Storage Account:
Notes on the storage account example:
  • azurerm_storage_account is provided by the AzureRM provider.
  • account_tier and account_replication_type are service-specific settings.
  • resource_group_name shows how one resource is placed inside another logical resource (the storage account is created inside the resource group named my-rg).
Terraform supports explicit references between resources so it can infer dependencies and determine the correct creation order. Reference and dependency management are covered in more detail in later lessons.
Avoid hardcoding sensitive values (credentials, secrets, or provider tokens) directly in .tf files. Use variables, terraform.tfvars, or secret management solutions (for example, HashiCorp Vault or cloud-native secret stores) to keep secrets out of source control.

​
Quick reference: resource block components

​
Provider responsibility

Terraform itself is provider-agnostic: it does not contain built-in knowledge about Azure, AWS, GCP, or other systems. Providers implement the platform-specific logic:
  • Authenticate with APIs for the target platform.
  • Expose supported resource types and their arguments.
  • Validate configuration fields.
  • Translate HCL into platform API calls.
In our examples, the AzureRM provider translates HCL resource blocks into Azure API calls. Each cloud or platform has its own provider and set of resource types. Examples include:
The image compares cloud resource icons for three providers: Azure, AWS, and Google Cloud, each with distinctive service icons.
Because providers handle platform-specific details, Terraform provides a consistent authoring workflow across clouds and services. You write HCL resource blocks and provider configurations; the provider translates them to API calls.

​
Next steps and references

Now that you understand how a Terraform resource block maps to provider resource types and arguments, the next topics to explore are:
  • How to configure and authenticate providers (provider blocks).
  • Using variables and outputs.
  • Managing references and implicit/explicit dependencies.
  • Organizing large configurations into modules.
Useful references:

Watch Video