"My First Terraform Workflow on Azure:

A hands-on walkthrough of provisioning and tearing down my first Azure resource using Terraform as part of a learning scenario for Hagital Cloud Solutions.
What is Terraform?
Terraform is an Infrastructure as Code (IaC) tool that automates the provisioning and management of cloud resources. Instead of clicking through a portal to create resources by hand, you describe the infrastructure you want in code, and Terraform figures out how to make the real world match that description.
Because the infrastructure lives in code, it's:
• Consistent:- the same configuration produces the same environment every time.
• Repeatable:- spin up (or tear down) an entire environment on demand.
• Version-controlled:- infrastructure changes go through the same review process as application code, via Git.
This works across cloud platforms AWS, Google Cloud, Microsoft Azure, and many more which is a big part of why it's become the standard tool for IaC. For this walkthrough, I used it against Microsoft Azure, and the goal was intentionally small: create one Resource Group, verify it, then clean it up.
How Terraform Works
Terraform follows a simple, repeatable workflow:

1. Write:-Create configuration files (.tf files) that describe the desired infrastructure.
2. Initialize:- Run terraform init to download the required provider plugins (in this case, the Azure provider).
3. Format & Validate:- Run terraform fmt to keep the code style consistent, and terraform validate to catch configuration errors before touching any real infrastructure.
4. Plan:- Run terraform plan to preview exactly what Terraform will create, change, or destroy — nothing happens to real resources at this stage.
5. Apply:- Run terraform apply to actually provision (or update) the infrastructure. Once you're done with the environment, there's a sixth step that's just as important:
6. terraform destroy, which tears everything back down. That last step is easy to forget, and it's exactly how unused cloud resources quietly rack up a bill. The Scenario: Hagital Cloud Solutions For this exercise, I used a simple scenario: Hagital Cloud Solutions needs a single Azure Resource Group named hagital-rg to serve as a container for future resources. The task was to go through the complete Terraform lifecycle write, init, fmt, validate, plan, apply, verify, and destroy and document each step. The Configuration I split the config into a couple of small files rather than one giant main.tf, mostly to keep provider setup separate from the actual resource definition.

main.tf — the actual resource:
Step 1 Authenticate
Before Terraform can talk to Azure, the Azure CLI needs to be logged in:
az login
az account show # confirms the right subscription is active

Step 2 Initialize
terraform init

This downloads the hashicorp/azurerm provider plugin and sets up the local .terraform working directory. This is also the step where a typo in the provider source (I had harshicorp/azurerm at one point an easy typo to make) will fail loudly, since Terraform treats provider names literally with no fuzzy matching.
Step 3 Format and Validate
terraform fmt
terraform validate

fmt rewrites the main.tf files into Terraform's canonical style consistent indentation and spacing so the code stays readable no matter who wrote it. validate then checks that the configuration is internally consistent (correct syntax, valid argument names, and so on) without reaching out to Azure at all.
A clean run looks like:
Success! The configuration is valid.
Step 4 Plan
terraform plan

This is Terraform's "dry run" it compares the code against the current state of the real infrastructure and prints exactly what it intends to do, without doing it yet:
Plan: 1 to add, 0 to change, 0 to destroy.
Getting into the habit of reading the plan output carefully before applying is probably the single most useful habit from this whole exercise it's the difference between infrastructure changes being predictable versus a surprise.
Step 5 Apply

terraform apply
After confirming with yes, Terraform provisions the resource group:
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Step 6 Verify in the Azure Portal
Jumping into portal.azure.com → Resource groups, hagital-rg shows up in the region I specified that is central US confirmation that Terraform's state and the real Azure environment actually match.

Step 7 Destroy
Once the resource had served its purpose (verifying the workflow), it made no sense to leave it running:
terraform destroy

Terraform shows the same kind of preview as plan, but this time for deletion, and asks for explicit confirmation before doing anything:
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure...
Enter a value: yes

Destroy complete! Resources: 1 destroyed.

What I Learned
Working through this end-to-end, even for something as simple as deploying a single Azure resource group, taught me a few valuable lessons.
First, I realized that the Terraform workflow itself is just as important as the infrastructure you're deploying. Commands like terraform init, fmt, validate, plan, and apply each serve a purpose, helping you catch different types of issues before any changes are made to your cloud environment.
I also learned that not every error is caused by Terraform. For example, authentication errors such as "could not acquire access token" often point to issues with Azure CLI authentication or network connectivity rather than problems in the Terraform configuration.
Another takeaway was how useful terraform plan is. Seeing a preview of the changes before they are applied gave me confidence that Terraform would do exactly what I expected, making deployments feel much less risky.
Finally, I discovered that cleaning up resources is just as important as creating them. Using terraform destroy ensures that temporary or practice environments are removed when they're no longer needed, helping to avoid unnecessary cloud costs.