For much of my career, infrastructure administration has involved portals, scripts, documentation, and planned implementation work. Each approach has value, but each can also leave the deployed environment disconnected from the documentation that originally described it.
A portal change, troubleshooting adjustment, or one-off resource creation may solve an immediate problem, but months later it can be difficult to know whether the environment still matches the documented design.
Infrastructure as Code, commonly shortened to IaC, offers a different model. Instead of treating infrastructure as something that exists primarily inside an administrative portal, IaC describes that infrastructure through configuration files.
My earlier exposure to Infrastructure as Code came through an Azure Well-Architected Framework effort tied to an Azure Virtual Desktop specialization audit. The tooling there was Bicep and PowerShell, not Terraform, so I understood the value of repeatable infrastructure without having prior hands-on Terraform experience.
What Is Infrastructure as Code?
Infrastructure as Code is the practice of defining and managing infrastructure through machine-readable configuration rather than relying entirely on manual portal activity. It can describe resource groups, networks, storage, compute, identity, security settings, DNS records, SaaS configurations, and resources across multiple providers.
HashiCorp describes IaC as a way to build, change, and manage infrastructure safely and repeatedly through versionable, reusable configuration files. Terraform uses human-readable, declarative configuration to describe the intended infrastructure and manage its lifecycle.
With a procedural approach, I describe each administrative step. With a declarative approach, I describe the desired result: the resource group, storage account, container, and associated configuration should exist.
Terraform then evaluates the configuration, compares it with the infrastructure it is already tracking, and determines which actions are required to move the environment toward the declared state.
Why Infrastructure as Code Matters
Repeatability
A configuration can be applied consistently across development, test, and production. Environment-specific values may differ, but the deployment pattern remains repeatable.
Version control
Because infrastructure is represented by text-based files, teams can review proposed changes, track history, and understand how a configuration evolved.
Review before deployment
Terraform planning creates a review point before infrastructure is modified by showing the actions Terraform expects to perform.
Reduced configuration drift
Manual changes can cause an environment to diverge from its intended configuration. Terraform can compare configuration, state, and real infrastructure to identify changes needed to reach the desired result.
Reusability
Common patterns can be packaged as reusable Terraform modules, supporting standards and reducing repeated manual effort.
IaC does not replace diagrams, procedures, decision records, or recovery documentation, but it brings the infrastructure definition much closer to the infrastructure itself.
What Is Terraform?
Terraform is HashiCorp’s Infrastructure as Code tool. It can build, change, version, and manage infrastructure through configuration files and a command-line workflow. I am currently focused on Azure, but Terraform itself is not limited to Azure.
Terraform uses plugins called providers to communicate with cloud platforms, SaaS services, and other APIs. For my current learning, the most important provider is AzureRM, which manages many Azure Resource Manager resources.
This provider-based architecture is one of Terraform’s most interesting characteristics. A practitioner can learn a common configuration language and workflow, then use providers to manage resources across different platforms.
The Terraform Configuration File
Terraform configuration files normally use the .tf extension. A common starting filename is main.tf, but Terraform evaluates all configuration files in the working directory as a collection.
Provider block
The provider block configures the provider Terraform will use, such as AzureRM for Azure, and establishes an authenticated context with appropriate access.
Resource block
A resource block describes an infrastructure object Terraform should manage, such as an Azure resource group, storage account, or storage container.
Variables and outputs
Variables separate reusable values such as names, locations, and environment identifiers from resource definitions. Outputs expose useful information after deployment.
The Basic Terraform Workflow
My initial training has focused on four of the most recognizable Terraform commands:
terraform initterraform planterraform applyterraform destroy
terraform init
I think of terraform init as preparing the workspace and gathering the components Terraform needs before it can evaluate or deploy the configuration.
terraform plan
The planning stage previews the changes Terraform expects to make, including whether resources will be created, changed, replaced, or destroyed. This review point is one of the workflow’s biggest strengths.
A plan can also be saved to a file by using the -out option:
terraform plan -out=main.tfplanThe name main.tfplan is operator-selected, not required. The key distinction is that .tf files contain configuration, while a saved plan represents a specific proposed execution.
terraform apply
In a learning environment, Terraform can generate a plan during apply and request approval. More controlled workflows can create a saved plan and then apply that exact plan.
terraform apply main.tfplanSeparating plan generation from plan execution can make the process easier to review and can help ensure that the evaluated plan is the one being applied.
terraform destroy
The destroy command is useful in labs where temporary resources should be removed after testing, but it must be treated carefully.
Authentication, App Registrations, and RBAC
In Azure, Terraform requires an identity with sufficient permissions for the resource operations described in the configuration. My training has included configuring an application registration and assigning Role-Based Access Control permissions.
Terraform should not receive broad permissions simply because it is automation. Deployment identities should be scoped to required actions, and credentials must be protected and kept out of configuration files and source-control repositories.
Understanding Terraform State
State is one of the most important Terraform concepts and one of the easiest to misunderstand when getting started.
Terraform stores information about the infrastructure associated with a workspace and uses state to map declared resources to real objects. Before an operation, Terraform refreshes its view of the environment and determines which changes are required.
By default, Terraform CLI stores state locally in terraform.tfstate with a backup file. HashiCorp recommends appropriate remote state for collaboration and warns against ordinary version control because state may contain sensitive information and requires protections such as secure access and state locking.
The .tf configuration is not a complete rollback mechanism by itself. Reverting configuration may cause Terraform to propose earlier settings, but the result depends on provider behavior, current resources, stored state, and the nature of the change.
State is a critical operational asset. It should not be casually edited, deleted, exposed, or treated as a disposable cache. HashiCorp recommends Terraform CLI state commands rather than direct JSON edits.
What I Have Built So Far
So far, I have used Terraform while learning how to create:
- Azure resource groups
- Azure storage accounts and containers
- Blog-related files
- Provider and authentication configuration
- Resource blocks and saved plans
- App registration and RBAC access
Connecting Terraform to Architecture and Governance
My earlier IaC exposure through Bicep and PowerShell helped me understand repeatable infrastructure, automation, and architecture governance. Terraform now gives me a new implementation model for those familiar concepts.
Infrastructure as Code can support broader architecture and governance objectives by encouraging:
- Standardized deployment patterns
- Repeatable configurations
- Peer review and version history
- Controlled change processes
- Reusable architectural components
- Greater visibility into intended infrastructure
Terraform does not automatically produce a well-architected, secure, or compliant environment. It consistently deploys what the configuration instructs, including mistakes.
Infrastructure as Code Is Still Engineering
Infrastructure as Code introduces engineering practices into infrastructure management:
- Source control and change review
- Dependency and version management
- Testing and reusable components
- Release workflows and state management
- Security scanning and recovery planning
My Next Steps
Areas I expect to explore further include:
- Variables, outputs, and reusable modules
- Remote state and state locking
- Provider version constraints
- Multiple environments and importing existing resources
- Drift detection and secret management
- Code review, pipelines, and pre-deployment policy checks
Final Thoughts
My first exposure to Infrastructure as Code showed me how Bicep and PowerShell could support an Azure architecture project. This new training is helping me understand Terraform specifically, including its workflow, provider model, state management, and planning process.
I am still learning, but these early exercises matter. Creating a resource group, storage account, container, or file through Terraform is not only a lab task. It is an introduction to a different way of thinking about infrastructure.